The Vibe Father
Playbook
Deployment is the last mile that quietly sinks more side projects than any bug. The code works on your laptop, the demo is great, and then the actual "put it on the internet" step turns into a three-hour fight with environment variables, a migration that half-ran, and a server that returns a blank 500 with no clue why. AI agents are genuinely good at drafting deploy scripts and config — but the trigger, the timing, and the rollback plan have to stay yours. Here's the boring, repeatable version that gets you live without a midnight incident.
Step 1: Deploy early in the day, on purpose
The single highest-leverage decision is when. Deploy at 10am on a weekday, not 11pm on a Friday. Not because the code is different, but because if something breaks, you want to be awake, caffeinated, and able to roll back before anyone notices — not debugging half-asleep while an agent confidently suggests the wrong fix. Treat "ship at midnight" as the anti-pattern it is. The whole point of the checklist below is that you can run it in twenty calm minutes any morning.
Step 2: Pick a boring host and stick with it
You do not need Kubernetes to put a web app online. For almost everything, a $5 VPS or a managed PaaS is the right call: it's cheap, it's understood, and there are a million answers online when it misbehaves. Ask your agent to keep the deploy target simple and standard. If it starts reaching for a nine-service cloud architecture for a to-do app, pull it back. Boring infrastructure fails in boring, googleable ways — which is exactly what you want at the last mile.
Step 3: Nail the four things that actually break deploys
In practice, first-time deploys fail on the same short list. Have the agent draft each, then you review before anything runs against a real server.
- Environment variables. Every secret and config value your app reads at runtime — database URL, API keys, app secret — has to exist on the server, spelled exactly right. A missing or misnamed var is the number-one cause of the mysterious blank 500. Ask the agent to produce a checklist of every var the code reads and confirm each one is set.
- Migrations. The database schema on the server has to match what the code expects. Run migrations as an explicit, separate step you can watch — never let them fire blindly as a side effect of the app booting.
- Smoke test. A tiny script that hits the live URL and checks that the homepage loads and one real action works. This is your "did it actually deploy" proof, not a green log line.
- Rollback. The exact command to get back to the previous working version. Write it before you deploy, while you're calm, not after, while you're panicking.
Step 4: Have the agent draft, then read every line
This is where an agent earns its keep. Hand it your stack and let it write the deploy script, the env-var checklist, the smoke test, and the rollback command. Then you read all of it. The danger with deploy scripts specifically is that a hallucinated flag or a wrong path doesn't fail loudly on your laptop — it fails on the server, against real data. Agents draft; you own the trigger. Here's the prompt we use:
Write me a deploy setup for a <your stack> app going to a single
$5 VPS (Ubuntu). I want four separate, reviewable pieces:
1. A checklist of EVERY environment variable the code reads at
runtime, with a one-line description of each.
2. A deploy script that pulls the new code, installs deps, and
restarts the app. Run DB migrations as a SEPARATE explicit
step, not automatically on boot.
3. A smoke-test script that curls the live URL and fails loudly
if the homepage or one key action is broken.
4. The exact rollback command to return to the previous version.
Do not run anything. Output the scripts so I can read them
first. Flag anything destructive.Step 5: Dry-run, then trigger it yourself
Run the smoke test against your local or staging copy first so you know it passes when things are healthy — a smoke test that's green even when the app is down is useless. Then trigger the real deploy yourself and watch the output live. Don't walk away. When it finishes, run the smoke test against production. If it's green, you're done. If it's red, run the rollback command you already wrote and debug in daylight.
A gate that runs your real checks
The reason deploys go wrong is that "it looks done" and "it actually works" are different states, and agents can't tell them apart on their own. The fix is a gate: the deploy only proceeds if your real build and smoke test pass. You can wire this by hand — a script that runs the tests and refuses to continue on failure. If you'd rather not build the plumbing, The Vibe Father has an AutoVibe verification gate that runs your build and tests before it calls anything done, plus checkpoints so a bad deploy is one click to undo. Either way, the principle is the same: no green checks, no ship.
The recovery drill
Practice the rollback once before you need it. Deploy, then immediately roll back on purpose, and confirm the site returns cleanly. Now you know the escape hatch works, so the next real problem is a two-minute annoyance instead of an outage. This drill is what separates people who deploy calmly from people who dread it.
Deployment stops being scary the moment it's a checklist instead of an adventure. Draft with an agent, review every line, deploy in daylight, and keep the rollback in your pocket. From here, the natural next step is automating this whole flow so it runs the same way every time — see how to set up CI/CD with AI. For picking the right model for infra work, the best AI for DevOps breaks it down, and if you're deploying something an agent helped you build end to end, shipping your first product with AI agents covers the road up to this point.
