Vibewright

The expertise you need. The attitude you want.

The expertise you need. The attitude you want.

Works on localhost, breaks in production? A first-deploy and rollback checklist for vibe-coded apps

Your AI coding tool got the app running on your laptop in an afternoon. Then you deployed it, and the build failed, or the login looped, or the page loaded with blank data. If you build with Cursor, Claude Code, GitHub Copilot, Replit, Lovable, Bolt or v0, this is the moment most projects stall.

This guide is the checklist built into Vibewright's Vibe-Coding Tech Lead · Ship-It Deployer builds, which are live now. The goal is to make deploys boring: automated, repeatable, monitored and reversible. Every step ends with one question the Ship-It Deployer asks about any change: if this goes wrong in production, how do we undo it, and how fast?

Step 1: set up three separate environments

Use local, preview (or staging) and production. Each one gets its own environment variables and its own database.

Step 2: pick a host that fits the workload

Frontends and serverless apps (Next.js, static sites) fit hosts like Vercel and Netlify. Long-running servers, background workers and WebSockets often don't fit serverless function limits, so they tend to belong on hosts like Railway, Render or Fly.io. Managed Postgres (Supabase, Neon) covers the database. Limits change, so check your host's current docs before you commit.

Step 3: get environment variables right

Missing or misplaced environment variables are the top cause of "works locally, fails in production."

  1. List every variable name (names only, no values) in a committed .env.example file, and add .env* files with real values to .gitignore.
  2. Set the real values in your host's dashboard, separately for each environment. On Vercel, for example, each variable is assigned to Production, Preview or Development.
  3. Never put a secret in a variable the browser can see. In Next.js, anything prefixed NEXT_PUBLIC_ is shipped to the browser, so it must not hold a secret key.
  4. Redeploy after changing a variable. On Vercel, changes only apply to new deployments, not to the one already running.

If a secret was ever committed or pasted somewhere public, rotate it at the provider first, then clean up the code.

Step 4: check the usual "works locally" suspects

Before rewriting any code, run through the causes the Ship-It Deployer checks first:

Don't "fix" a failing build by turning off type-checking or build checks. That hides the next real error until your users find it.

Step 5: add a basic CI pipeline

Every pull request should run install, lint, type-check, tests and build, using GitHub Actions or your host's equivalent. Require it to pass before anything merges to main, turn on branch protection, and use preview deploys so you can click through a change before it reaches customers.

Step 6: treat database migrations as the riskiest part of a deploy

  1. Keep migrations as files under version control. Never edit the production schema by hand.
  2. Classify each one: additive (a new table or column), destructive (dropping or renaming), or data-moving.
  3. For destructive changes, take a backup first and use expand, then migrate data, then contract: add the new column, copy the data, switch the code, and only remove the old column in a later deploy.
  4. Run every migration on staging before production.

This matters for rollback too. Rolling back your app code doesn't roll back your database, so a migration the old code can't handle can leave you stuck.

Step 7: know your rollback before you need it

Find your host's rollback button while nothing is on fire. Two examples from the current docs:

Write a one-page runbook covering how to roll back the app, the database and the config, who can do it, and roughly how long it takes. Then practice it once.

Step 8: domains, HTTPS and monitoring

Launch day: the pre-release checklist

  1. CI is green.
  2. Migrations were tested on staging.
  3. Every production environment variable is present.
  4. A backup is taken if the schema changes.
  5. The rollback path is confirmed.
  6. Monitoring is open while you release.
  7. Release notes are written.

For the first two hours after launch, watch errors, response times, sign-ups and payments. Afterward, write down what broke and what you'll automate next time.

Where the Ship-It Deployer build fits

Each Ship-It Deployer build is a ready-to-paste system prompt for Claude Projects, ChatGPT Projects, Gemini, Grok, Cursor and other agent frameworks. About 80% of its attention goes to environments, CI/CD, deploys, environment variables, migrations, domains, monitoring and rollback, with debugging and security brought in where deploys need them. Say "run onboarding" and it asks about your stack and host, whether you have staging and a separate production database, how you deploy today, and any current deploy errors. It then runs workflows for a first deploy, a pre-release checklist, CI setup, migration safety review, a rollback runbook and a launch-day watch.

It won't help you hardcode secrets, and it won't run or advise irreversible commands like force-pushes, dropped tables or production migrations without your explicit approval of the exact command. It's guidance, not a certified security audit, and it never claims code works unless it was run. You review and test everything before production.

Setup guides: Claude Projects, ChatGPT Projects and Gemini Gems and skills. They use a CFO build as the example, but the steps are the same for any Vibewright build. Related: the one-page architecture plan, the pre-launch security checklist and breaking the AI bug-fix loop.

Then pick the deploy partner you want beside you at launch. The Ship-It Deployer comes in seven tones: Aggressive, Affirming, Dry (answer first, numbered steps, a "Next action" on every reply), Funny, Sarcastic, Boardroom Professional and Calm Zen. Same checklist, different voice. See how tones change an agent.

Get the Ship-It Deployer

Choose your Ship-It Deployer tone on /pricing · Or grab the free sample

← All guides