Get in Touch About the Generators and the Validator

One inbox, read by a human. No ticket numbers, no chatbot in front of it.

What to Include in a Bug Report

Email [email protected] with enough detail to reproduce the problem.

For a generated file that does not work

For a validator finding you disagree with

Send the file, the finding, and why you think it is wrong. Some findings are opinions with a reason attached (root users, container_name, latest tags); if the reason does not apply to your case, say so and it may become a note instead of a warning. If a Compose key or a Dockerfile instruction is flagged as unknown and it is real, include a link to the documentation and it gets added.

For everything else

Corrections to the guide, a preset worth adding, or something written here that is out of date all go to the same address. Requests for hosted builds, saved projects or help with a specific production outage will get a friendly no; the about page explains the boundaries. There is no form on this page on purpose: a form needs spam protection, and spam protection means loading a third-party script on a site that otherwise loads none.

Replies usually go out within a few days. If your message includes a file for debugging, it gets read and then deleted, not kept as data. The privacy policy has the rest.