The platform engineer a small team does not have
Generate your Dockerfile, CI and deploy config — then fix the build when it breaks.
Connect a repository. This reads what is actually in it and generates a Dockerfile, a CI pipeline and a deploy config, showing you the file it drew each conclusion from. When CI fails, it reads the log and proposes the fix as a pull request.
The agent never pushes to main. Every change is a proposal a human merges.
It shows its working
Every conclusion comes with the file behind it — python, because requirements.txt is at the root. Where something is not written down anywhere in your repository, it says so and asks, rather than picking a plausible value.
Server-first, not Kubernetes-by-default
The default output is one container and a compose file, because that is what a team of four needs to ship. Kubernetes manifests are generated only when you ask for them, and the screen tells you which you are getting.
No patch you have not seen work
Every proposed diff is run through git apply --check against your actual working copy before it is stored. A patch that does not apply is never saved, so no screen can show you one.
What it will not do
- It will not push to your default branch. This is not a setting. Pushes are allowed to devopsagent/… branches and refused everywhere else, including branches called trunk or production that a list of forbidden names would miss.
- It will not invent a version, an entrypoint or a port. If your repository does not say which Python it needs, the generated Dockerfile pins one and carries a comment admitting it was a guess.
- It will not write a CI job that passes without running anything. Where no test command could be found, the generated pipeline exits 1 and says why — a green tick that means nothing is worse than no pipeline.
- It will not claim your build is fixed. It proposes. Your CI decides.