How to Deploy a Vibe Coded App Without the Ops Blunders

Your app works. People are using it. Then you close your laptop for a long weekend and something stops: the report that refreshes every morning, or the whole thing. Someone messages you, you say something vague about a recent change, and a colleague who understands servers rebuilds it while you are away.

If that is close to home, you are not alone. Knowing how to deploy a vibe coded app is the piece almost nobody teaches, because the tools stop at “it runs”. This article covers what goes wrong between a working app and a running service: laptops standing in for servers, no environment separation, no pipeline, and no backups.

What this problem looks like

The clearest version comes from a data engineer’s account of a Friday afternoon. An internal dashboard, built with AI by a colleague, stopped updating. The builder was on vacation and blamed a recent code change. But the dashboard was a static site; its data came from a scheduled job running on the builder’s own laptop. Laptop closed, job stopped, dashboard dead. The engineer ended up taking the dashboard over and replacing it with a proper pipeline, the polite word for automated steps that run on a server nobody has to keep awake.

A second pattern comes from a dev team lead who spends much of the year getting AI-built apps ready for real users. In almost every codebase he finds backups that have never been restored, no error tracking, and secrets committed to the repository. His test for backups is worth keeping: until you have restored one, what you have is a hope, not a backup.

A third comes from a non-technical builder who assumed that because their AI platform handed over a GitHub repo, the app could run anywhere. It could not: the database and server-side functions lived inside the platform’s own cloud, so moving meant a database account, a cloud console, API credentials and environment files they had never heard of.

Underneath all three: the app was treated as finished when it ran once on one machine.

Why deployment mistakes happen when you vibe code

AI coding tools optimize for the moment you are in. Ask for a dashboard and you get one that renders on localhost. Ask for nightly refreshes and you get a cron entry (a time-based scheduler built into the operating system) or a script you run yourself. Nothing in that loop asks where this will live when you are not at the keyboard, because you never asked, and as one commenter on the Friday-dashboard thread pointed out, the models go along with whatever setup you describe rather than challenging it against operational practice.

There is also a vocabulary gap. “Deploy” sounds like a single act, but it is a set of decisions: where the code runs, where the data lives, where background jobs execute, which settings differ between laptop and live site, how a change reaches users, and what happens when a disk dies. A builder without a mental model of those parts cannot ask for them, and the AI fills the gap with whatever is simplest, usually your own machine.

Finally, when the database, auth and server functions are bundled into the platform that generated the code, the repository you download is only half an app. That is fine until you need to move.

How to deploy a vibe coded app properly

Work through this in order, in a day or two, with Claude Code, Cursor or whichever tool you use.

Step 1: Draw the map before you touch anything

Open a fresh session and ask the tool to inventory the app: every place code runs, every scheduled or background job, every external service, every configuration file, every place data is stored. In Claude Code, a prompt like “List every process, scheduled job and external dependency this app needs to function, and where each one currently runs” surfaces the laptop-hosted cron job in seconds. Everything below is about moving each item onto infrastructure that does not depend on you.

Step 2: Separate the environments

You need at least two: local (your machine) and production (where users are). Nothing in the code should know which one it is in; all differences live in environment variables, which are named settings the host injects at runtime. Ask your tool to move every hardcoded URL, key and connection string into environment variables, generate a .env.example listing the names without values, and add .env to .gitignore. If you have already committed secrets, rotate them today; the how-to is in our guide to exposed API keys.

Step 3: Give background jobs a real home

This is the fix for the closed-laptop failure. Anything scheduled runs on a hosted scheduler or a server, never a personal machine. Ask Claude Code to convert the local script into a scheduled function on your host, with the schedule defined in configuration committed to the repo. Then add a log line at the start and end of every run, and an alert if a run does not complete on time. A job that fails silently is worse than one that never existed.

Step 4: Set up a pipeline, even a tiny one

A pipeline means a change reaches production through a repeatable, automated path: push to a branch, checks run, merge to main, the host deploys. Ask your tool to write a workflow file for your git platform that installs dependencies, runs tests and builds the app on every push. No tests yet? Start with a build and a lint step. Connect the host to the main branch so deploys are never done by hand on a Friday. If you are not using git checkpoints consistently, fix that first; this article on losing code to an AI rewrite shows why.

Step 5: Back up, then prove it

Turn on automated database backups. Then, the part everyone skips, restore one into a scratch database and confirm it is intact. Record the commands in a runbook (a short document of what to do when something breaks) in the repo. Repeat the drill every few months.

Step 6: Add error tracking and a health check

Install an error-tracking service so production exceptions reach you before users leave. Add a health-check endpoint (a URL that returns success when the app and its database are reachable) and point an uptime monitor at it, so you learn about failures from a notification, not a colleague.

Step 7: Encode the rules so the AI keeps them

Put the above into your CLAUDE.md (or AGENTS.md, or the equivalent in Cursor and Lovable) as standing rules: no secrets in code, no jobs outside the hosted scheduler, all configuration via environment variables, every change through the pipeline. Ask for a review pass against those rules before merging anything infrastructure-related. That turns a one-time cleanup into lasting Claude Code deployment best practices. For the wider picture, see whether a vibe coded app is production ready.

How a Red Corner CTO would have prevented this problem

Before the first prompt, a CTO would have asked one question: where will this run when you are asleep? That question forces the deployment map into existence on day one. They would have insisted the answer be a hosting platform with a scheduler, a managed database and automatic deploys from git, chosen in week one rather than after the app existed. They would also have flagged the lock-in trade-off of all-in-one AI platforms so you chose it knowingly, not discovered it when you tried to leave.

During the build, the CTO would have caught the laptop cron job in the first code review, because that is precisely the kind of thing an experienced eye spots and a non-technical builder cannot. They would have insisted on environment variables and a .gitignore from the first commit, a pipeline that runs checks on every push, and a rule in your CLAUDE.md that the AI must not introduce any process running outside the hosted environment. They would have reviewed schedule configuration the same way they review code.

Before launch, they would have run a short pre-flight: restore a backup and time it, break configuration in staging to confirm the app fails loudly rather than silently, confirm error tracking is receiving events, and check that someone other than you can deploy and roll back using the runbook. They would have asked what happens if you are unreachable for a week, and made sure the honest answer was “nothing”.

After launch, they would have set a cadence: a periodic restore drill, a review of the deployment map as the app grows, and a look at any new background job before it ships. When something broke, they would have had you fix the pipeline so it cannot recur, not just the symptom.

None of this requires you to become an infrastructure engineer. It requires someone who has watched a laptop-hosted job fail on a Friday and knows the fix before it is needed.

Frequently asked questions

Where should I host a vibe coded app?

For most apps built with Claude Code, Cursor or Lovable, a managed platform that deploys from git and offers a hosted database, scheduled functions and environment variables is the right start; Vercel and Supabase are common choices. The vendor matters less than the properties: automatic deploys, a scheduler, backups you can restore, and a way to leave later.

Can I run a scheduled job on my computer for a vibe coded app?

Only while you are the sole user. The moment anyone else depends on the output, the job moves to a hosted scheduler or a server. A laptop sleeps, loses wifi and goes on vacation with you, and the app quietly stops while looking fine.

Do I need a staging environment for a small app?

Not on day one, but you do need production separated from your local machine, with all differences held in environment variables. Add staging once you have paying users or a second contributor.

How do I know my backups actually work?

Restore one. Load the most recent backup into a scratch database and check that the records you care about are there. If you have never done that, your backups are unverified; schedule the drill this week.

Get a CTO in your corner

Deployment is where a working app becomes a running product, and it is the part AI tools leave to you. Red Corner puts experienced CTOs alongside founders who vibe code, to catch the laptop cron job before it bites and guide you to a service that survives your vacation. Get a CTO in your corner at redcorner.io.