How it works

Four steps, and the honest limit of each one.

1. Connect a repository

Paste the https address of a repository. It is cloned shallow — one commit, one branch, no tags — with a size cap enforced while the clone runs rather than checked afterwards.

SSH addresses are refused, and the message says why: an SSH clone would authenticate as this server rather than as you. If you paste a URL with a token in it, that is refused too, and you are told to rotate the token rather than having it quietly stripped.

2. It reads what is in it

The stack, the package manager, the language version, the entrypoint and the port are read out of your manifests — and every finding is shown next to the file it came from, so you can correct one that is wrong.

What is not in your repository is reported as unknown. If nothing says which Python version you need, this does not pick one and move on; it says it does not know. That matters more than it sounds: everything downstream is built from these conclusions, so a confident wrong answer here becomes a container that builds, starts, passes its health check and serves the wrong thing.

3. It generates the files

A Dockerfile, a CI workflow, and a deploy config — each with a written explanation of why it looks the way it does. A generated Dockerfile you cannot interrogate is one you should not run.

The default target is server: one container, a compose file and a deploy script. Kubernetes manifests exist and are generated only when you choose that target. Handing a four-person team a Deployment, a Service and an Ingress when they asked how to ship is not help, it is a second problem.

Where a value was a guess, the generated file says so on the line above it. You read that in a diff, which is where the person who knows the answer is looking.

4. It proposes a fix when CI fails

Paste the failing log. The agent explains the failure and cites the log lines it relied on — and those citations are checked against your actual log before you see them. A diagnosis pointing at line 412 of a 300-line log is not a weaker explanation, it is an invented one, and it would be the most convincing thing on the page.

Then, where it can, it writes a patch. Every patch is run through git apply --check against your working copy at the commit it claims, before it is stored. One that does not apply is never saved, so no screen can render it as a change you can merge.

Sometimes the honest answer is that it understood the failure and cannot write a safe patch for it. You get that answer, in those words, rather than a guess.

The agent never pushes to main. A proposal goes onto a devopsagent/… branch and a human merges it. This is an allowlist in code, not a list of branch names to avoid — a repository whose default branch is trunk is protected by it just the same.