The deploy went green. Two minutes later, the whole environment was a 404.

The pipeline reported success. Then every route returned 404. Not an app bug — the containers had never started. The startup chain: backup probe → migrations → API → web. The probe died on one parameter in a Postgres connection string. Before I pulled the container log, I confidently named two wrong causes.

This is DevOps when your engineering team is AI agents: one deterministic deploy command, a monorepo never used as a deploy source, and secrets no human pastes.

One human, a team of agents, sixteen applications

I run a one-person company. Most implementation is done by Claude Code agents inside SBX, a Go framework I built to govern agent work: what agents may edit, how tasks walk a machine-checked agentic SDLC, and what counts as proof of "done". By the framework's own count: roughly 110 packages, 16 applications, 6 client workspaces — including a production real-estate platform for a client in Thailand. The web stack deploys to plain VPSs through Dokploy, an open-source deployment platform with a REST API.

One constraint shapes everything: an agent executes a written procedure very well, but cannot be trusted to improvise operations. Whatever a deploy needs, it must need deterministically. This is the ops version of my operating rules for AI coding agents: trust mechanisms, not prose.

The standard playbook: CI/CD, runbooks, or an agent with a shell

Three obvious options exist, each good at what it was designed for.

  • Hosted CI/CD. A pipeline that builds and deploys on merge. Reproducible, auditable, proven — the right answer for most teams.
  • Runbooks plus human judgment. A runbook is a written, step-by-step operations procedure. It works because when a step fails oddly, a human stops and thinks.
  • An agent with shell access and a runbook — my first choice. Agents read documentation more reliably than most humans, and when nothing failed it worked.

My reasonable-but-wrong first theory: a good enough runbook substitutes for judgment. It does not. It substitutes for memory.

Where it broke: runbooks assume judgment, agents substitute improvisation

The agent-plus-runbook option failed at the first failing step. Deploys with manual steps fail differently every time: a stale lock, a slow container, a changed flag. I watched agents "fix" failing deploys by retrying with modified flags, editing generated files, and working around the error instead of reporting it. For an agent, ambiguity is an instruction to improvise — the one property you cannot allow in operations.

Classic CI/CD from the monorepo failed on exposure. The monorepo holds framework internals, governance records, and material from multiple clients. Pointing a deployment platform at it means trusting every future pipeline change to never leak any of that. Filtering at deploy time is a review problem; I wanted a construction problem.

The last clue came from my early pipeline. I deployed from an unsynced feature branch, and the deploy went green — while shipping code without my change. The sync step pushed the canonical main branch, not my checkout. Green pipeline, wrong artifact. "Green" and "correct" are independent unless you force them to coincide.

What I built: one command, a scrubbed mirror, and secrets nobody types

The whole pipeline is one command:

$ sbx deploy <project> --env production
→ bump     increment the project version
→ sync     vendor dependencies + scrub into the deploy-mirror repo, push
→ deploy   call the deployment platform's REST API (pull mirror, rebuild, restart)
→ tag      tag the release in git

The key decision is the mirror: the monorepo is never a deploy source. Each project has a dedicated external mirror repo holding only what its deployment needs — vendored, scrubbed by construction, pushed by the pipeline. Dokploy pulls the mirror and nothing else. A mirror cannot leak what never enters it; there is no "remember to exclude" step for an agent to forget.

Secrets never touch a keyboard. The pipeline authenticates as a machine against the vault (1Password service accounts behind a mockable Go interface) and injects values into containers at start. Rotation means changing the vault item and restarting the container — no image rebuild, no copy-paste, no secret in the mirror or the monorepo.

Server bootstrap is moving the same way: executable, self-verifying steps instead of a wiki page that trusts the reader. It is younger than the deploy pipeline. Infra config — Dockerfiles, compose files — is generated from declarative YAML; agents are mechanically blocked from editing generated outputs and must fix the generator.

The honest cost: real engineering time — a hand-written Dokploy API client, a scrub-and-vendor step, generator discipline — and new, sharper failure modes. The outage in the opening was one. I had wired the pre-deploy backup probe as a fail-loud root dependency: if the backup cannot run, nothing deploys. (Fail-loud: a failing step stops everything. Fail-open: it reports and the rest continues.) Right instinct for data safety, wrong scope of damage. The probe's connection string carried a search_path parameter — the Go Postgres driver accepts it, libpq-based tools reject it. The probe failed; migrations, API, and web stayed down with it. One advisory check took out an environment. I named two wrong causes before reading the container's log — the diagnostic discipline I demand from agents, skipped under pressure.

I will not invent a recovery-time number; I did not measure one. What I can say: in my case, one deploy is now one command, and its output is the audit trail. Both incidents produced a mechanical fix. The probe's connection string is now normalized. Deploying from anything but a synced canonical main is a named, documented failure mode — its mechanical guard is still on my list.

Agentic DevOps: when your deploy operator has no judgment

"Agentic DevOps" usually means AI agents running operations. The real shape is wider: any system where the deploy operator carries no judgment. AI agents are only the loud new case; the same shape covers a junior on-call engineer with a runbook at 3 a.m., and a nightly redeploy cron job. If your operator cannot improvise safely, every ambiguity in the pipeline is a waiting incident.

It fits teams adopting coding agents beyond code review, platform teams whose many small services drift apart in deploy procedure, and solo operators with no second person.

Who should skip it: with one app on a managed platform, the platform is already your deterministic pipeline; a strong ops rotation with a single deploy target is well served by runbooks plus judgment.

What's still ugly

Plenty.

  • The fail-loud versus fail-open policy is convention, not enforcement. Nothing stops me from wiring the next advisory probe as a root dependency.
  • Bootstrap checklists are executable but not fully idempotent — not yet safe to re-run blindly.
  • Post-deploy health checks are HTTP-probe level: machine-checkable, but shallow compared to "the release actually works".
  • If I started over, I would set a failure policy per dependency edge on day one, not after an outage.
  • Next: preview-first as a hard gate — every change must pass machine-verifiable checks in a preview environment before production becomes a legal target.

Takeaways

  1. When the probe took the environment down — every dependency edge needs an explicit failure policy. Fail-loud protects data; advisory checks must fail open, or they become your largest source of damage.
  2. When I named two wrong causes — read the primary log before naming a cause. Your agents inherit your diagnostic habits; so does future-you under pressure.
  3. When the green deploy shipped stale code — force "green" to mean "the artifact you intended": pin the ref the pipeline ships and verify sync first.
  4. When the agent "fixed" the deploy creatively — a manual step invites improvisation. If the operator lacks judgment, determinism is the only substitute.
  5. When I stopped filtering and started scrubbing — exclusion by construction beats exclusion by review. A mirror cannot leak what never enters it.

Where this lives

The pipeline is part of SBX, the framework behind my work at shredbx.com. Not open source today; the patterns above are portable without it.

External references

Related projects