How to deploy a vibe-coded app properly

What deploying properly means

An AI app builder's publish button gives you a URL. That is a deployment, but not yet a deployment process. Chapter 13 of From Model to Product, on packaging and deploying AI systems, calls deployment the moment where engineering is tested, and starts from one question: how do you make sure the program runs the same way everywhere? Add a second, how you undo a bad release, and you have four properties to aim for. The rest of this guide takes them in order.

• Reproducible: a fresh copy of the code on a new machine builds and runs the same app.
• Configurable: whatever differs between environments, secrets included, comes from the environment rather than the code.
• Tested: every release passes the same checks before it reaches users.
• Reversible: the previous version can be restored in minutes.

Get the code into a repository you own

Start with ownership. Lovable, Bolt and Replit can all connect a project to a GitHub repository, and many AI app builders offer a repository sync or a code download. Lovable's sync, for example, is two-way and creates the repository in the account or organisation you choose (Lovable docs). Once the code is in your repository, every change has a history and you are free to deploy it elsewhere.

Then prove it builds without the builder. Clone the repository on a clean machine or in CI, install, build and run it. A builder hides steps that must become explicit: the runtime version, the build command, the environment variables, sometimes a database migration. Write each one in the README as you find it.

This is the chapter's reproducible environment applied to a JavaScript app. Its first step is a dependency file with exact versions; for Node that means committing the lockfile, installing with npm ci and pinning the Node version. Its next step is a container that defines the whole runtime, which deploying a model with FastAPI and Docker covers for a Python service.

Separate code, configuration and secrets

Chapter 13 separates three things: code defines the logic, the model defines the learned behaviour, and configuration defines how the system runs. Kept apart, each can change without rebuilding the others. In an app that calls a language model, the model name, the prompt templates and any thresholds sit on the configuration side, and they need versions like code, because changing any of them changes what users see.

Secrets are configuration with a rule of their own. The chapter is direct: secrets such as API keys should never be hardcoded inside the container image, but provided through environment configuration at runtime. The same applies to the code and the repository: keep a local .env file out of Git, commit a .env.example that lists every variable with no values, and set the real values in your host's environment settings. Then make the app refuse to start when one is missing, so a misconfigured release fails at deploy time instead of in front of a user. Values your framework bundles into browser code are public, never secret; securing a vibe-coded app covers which keys can live where.

// Read every setting once, at startup, and stop if any is missing.
const REQUIRED = ["APP_ENV", "DATABASE_URL", "LLM_API_KEY", "LLM_MODEL"] as const;

type Config = Record<(typeof REQUIRED)[number], string>;

export function loadConfig(env: Record<string, string | undefined>): Config {
  const missing = REQUIRED.filter((name) => !env[name]);
  if (missing.length > 0) {
    throw new Error(`Missing environment variables: ${missing.join(", ")}`);
  }
  return Object.fromEntries(REQUIRED.map((name) => [name, env[name]])) as Config;
}

export const config = loadConfig(process.env);

Give development, staging and production their own everything

A builder usually gives you one environment: the one you edit is the one users see. That is fine while you are the only user. Once people depend on the app, you need at least three: development on your machine, staging that mirrors production, and production itself.

Separate means separate resources, not just separate URLs. Each environment gets its own database, its own sign-in configuration, its own model provider key with its own spending limit, and its own copy of the configuration. A test in staging then cannot delete real users' data, a leaked development key cannot spend production's budget, and a schema change can be tried before it reaches production.

Staging earns its keep when it matches production: same host, same build steps, same configuration names, test data. Where you can, promote the build that passed in staging rather than rebuilding it, so what you tested is what ships. One caution: frameworks fix browser-bundled variables at build time, so a build promoted between environments must not rely on them for anything that differs.

Who owns the database, the users and the keys?

Leaving a builder's hosting is mostly a question of what else the builder runs for you. Some, Lovable among them, provision a database, sign-in, file storage and server functions alongside the code, so the repository holds only part of the app. Lovable's documentation is explicit: the synced code includes the database migration files but not the data, and moving the PostgreSQL database alone does not move authentication, storage, realtime or Edge Functions (Lovable docs). It also notes that the built-in backend can stay where it is while the front end moves elsewhere.

That suggests the order: move one piece at a time, usually the front end first, and verify each copy before you retire the original. Whether you move or stay, answer these questions for each piece:

A pipeline that tests before it builds

Chapter 13 lists what manual deployment gets wrong: the wrong version goes out, a dependency is missing, the server does not restart cleanly, a working system is replaced by a broken one. Its answer is a pipeline that takes the same road every time: run tests, build, store the build, deploy, and stop the release if any step fails.

Many hosting platforms build and deploy each push to a chosen branch, which covers the last steps. Add the first one yourself with a CI service such as GitHub Actions, and require its checks to pass before anything merges into the branch that deploys. The chapter's pre-build checks translate directly:

• The app starts and its main routes respond.
• Configuration can be read: every required variable is present.
• The database connection works, and pending migrations apply cleanly to a copy.
• The AI path returns a valid result: the model call stubbed in unit tests, and one real call in a smoke test against staging.
• The prompt templates and model settings in the release are the versions you meant to ship.

Keep a way back

Every deployment should allow rollback, and the chapter sets four conditions for it. For risky changes such as a new model or prompt, release gradually as well; shadow, canary and A/B deployment compares the options. For an ordinary web app built with AI tools, the four conditions read like this:

• Old builds are kept. Many hosts keep previous deployments and can restore one; find out whether yours does, and try it once before you need it.
• Model and prompt versions are stored, not edited in place, so old code meets the prompts it was tested with.
• Database changes stay compatible with the previous version: add columns and tables first, and remove old ones in a later release.
• Configuration is versioned, so restoring a build also restores the settings it expects.

Should you leave the builder's hosting?

Not necessarily. Staying is reasonable while the hosting gives you a repository you own, separate environments, secrets held outside the code, logs you can read and a rollback you have tested. Bolt's help centre, for example, says that code synced to GitHub can be published with Bolt hosting, its Netlify integration or another service you choose, so the decision can wait until you have a reason.

The reasons are specific: a staging environment the builder cannot give you, background jobs or long-running work, control over where data is stored, costs that grow faster than usage, or engineers who need a standard workflow. The work above is what turns that move into a migration rather than a rewrite. Once the app is live, wherever it runs, monitoring a vibe-coded app covers how to tell whether it is still working.

Questions