Let an AI Agent Deploy to Production Without Breaking It

"Deploy it" is the riskiest sentence you type to an agent

An agent that can run shell commands can ship your app. It can also ship a half-finished change, touch the wrong database, or deploy twice because the first run looked slow.

Telling it "be careful" in a prompt is a request, not a control. A safer setup makes the risky commands refuse to run until something the agent can't fake is in place.

This post walks through what BoringPush enforces, and where the limits are.

What you get

Your agent can ship, but only on purpose. A bad release is put right without you doing anything. And your live database is somewhere the agent can't reach.

You stay in charge of the moments that matter, and the agent handles the typing.

The command asks first

bp deploy won't run by accident. Here's what it does in each situation:

You just type bp deploy and answer the question. An agent has to say --yes, on purpose. You can allow that in one place, such as your agent's instructions, and nowhere else.

What to tell the agent

Put something like this in your agent's instructions:

Deploying:
- Run `npm run lint` and `npm test` first. Stop if either fails.
- Deploy with `bp deploy --yes`.
- A non-zero exit means do NOT retry. Report the output and wait for me.
- A zero exit is not proof. Read the output for "unhealthy" or
  "Rolled back", then `curl` the live site and tell me what you see.
- Never touch the production database.

The last three lines matter more than the first two. An agent that retries a failed deploy in a loop is the failure you're guarding against.

Reading the result

With --json, quick commands like status and doctor return a short JSON result: whether it worked, the exit code, and a hint. A real deploy is different. It streams its progress live, and the exit code is the verdict.

So for deploys, read the output and check the exit code. Don't wait for a JSON object that doesn't arrive.

And don't lean on a zero exit alone, either. The server can undo a bad release by itself, so the safest habit is to read the output and look at the live site. I'd test that on a staging server before relying on it.

After the agent says yes

Every deploy runs the same safety steps, as covered in Free Vercel Alternative: Host Next.js on a $6 VPS:

1. A code check. A problem stops the run before anything leaves your machine.
2. A local build, then the new version goes live with the old one kept close.
3. A health check. If the new version never answers, the old one is put back and the deploy is reported as failed.

If something slips through anyway, bp rollback --yes puts the previous version back without a rebuild. It also needs --yes from an agent, so undoing is as deliberate as shipping.

The part an agent can't touch: your live database

Deploying is one risk. Data is the other.

BoringPush keeps agents away from your live data. Agents look at your database through a read-only window, so a bad query can't turn into a delete. Changes to the live database need a person typing the command in a real terminal, with a key that's never given to agents.

That's the difference between "the agent promised" and "the agent can't." It follows the lesson in the PocketOS write-up: obedience is not a control.

Know this first

• --yes is a switch, not a judgment. Once an agent passes it, the deploy runs. The gate stops accidents, not a deliberate misuse of the flag.
• Unsaved changes get saved. A deploy commits any uncommitted files first, so tell the agent to commit its own work with a real message.
• Undo needs the default deploy route. bp rollback works for default deploys. On the Docker route, the previous version is kept for the same reason; see Free Kamal Alternative.
• A passing health check isn't a passing product. It proves your site answers. It can't prove checkout works, so run your own smoke test.

Why BoringPush is the way to do this

Most setups ask you to trust the agent. BoringPush doesn't ask: shipping needs a deliberate "yes", a bad release is undone, and your live data is out of reach.

That's what lets you hand the keyboard to an agent and still sleep. It was built for agents from the start, not patched for them later.

FAQ

What does --yes actually do?

It skips the confirmation question, nothing else. Without it, bp deploy and bp rollback refuse in automated sessions with exit code 2, and ask once on a human terminal.

Can the agent deploy by pushing to git instead?

If your server has the git-push hook installed, a push can also deploy, and that route has its own health check and undo. The consent question only covers deploys made through bp, so decide which route agents are allowed to use. See git push production deploy.

How do I know the deploy worked?

Read the output for "unhealthy" or "Rolled back", then load the live site yourself, or have the agent curl a page you care about. A green result is a good sign, not a promise.

Should the agent run database changes before deploying?

Only against a test copy. Changes to the live database need a human at a real terminal, plus a key the agent doesn't have.

Does this work for Cursor and other agents, not just Claude Code?

The rule lives in the command, so any tool that runs shell commands meets it. It doesn't depend on which agent is typing.

Keep reading

• Approve Deploy From iPhone at Dinner in 60 Seconds — human-in-the-loop deploys
• An Agent Deleted Production. Every Rule Said Don't. It Did It Anyway — why prompts aren't controls
• Free GitHub Actions Alternative: Deploy Without CI Minutes — deploying from your own machine

Get BoringPush →