How to Deploy a Vibe-Coded App: Step-by-Step

1. Put the generated code in a Git repository

Use the builder’s GitHub integration or export the project and create a repository. Git gives you a versioned source of truth, a reviewable diff, and a route out of the original builder. Commit the package-manager lockfile so the cloud build installs the same dependency versions you tested.

Before the first push, search for credentials and local files. A .env file belongs in .gitignore; a safe .env.example can list variable names without values. If a real secret has already entered Git history, deleting the visible line is not enough—revoke or rotate the credential.

2. Run the production build locally

Install dependencies using the project’s package manager, then run its production build. For many JavaScript projects that means npm ci followed by npm run build, but use the commands declared by the project. Run its type checker, tests, and linter when available.

npm ci
npm run build
npm run test   # when the project defines tests

AI-generated code often hides warnings behind the development server. A production build catches unresolved imports, server-only code used in the browser, invalid routes, and environment assumptions earlier and more cheaply than a cloud deployment.

3. Choose a host that matches the app’s runtime

Import the Git repository and let the host detect the framework, but review its answer. Confirm the repository root, install command, build command, output directory, runtime version, and production branch. A monorepo may need a subdirectory as its root.

Vercel documents a Git workflow that creates Preview deployments for non-production changes and a Production deployment from the configured production branch. Render asks for explicit build and start commands for a web service. Both patterns work; they solve different runtime shapes.

4. Add production environment variables without exposing secrets

Add values through the host’s environment-variable settings, not by pasting them into the repository. Keep Preview and Production separate. A preview can use a test database and sandbox payment account; production should use controlled production resources.

Prefixes such as NEXT_PUBLIC_ and VITE_ tell the framework to include a value in browser JavaScript. They do not make a secret safe. If the browser must not know it, call the third-party API from a server route or function.

5. Prepare the database, storage, and authentication

Create or select the production project, apply schema migrations, configure storage, and verify backups appropriate to your risk. Do not assume a generated table is private. Supabase’s production guidance calls for Row Level Security on exposed tables and recommends reviewing the Security Advisor before launch.

Test authorization with at least two accounts. Confirm that one user cannot read, edit, or delete another user’s data by changing a URL or request body. Test anonymous access as well. Then replace localhost in the auth site URL, redirect allowlist, OAuth provider, email links, CORS rules, and webhook endpoints.

6. Deploy a preview and test it like a stranger would

Deploy a branch or preview environment before sending production traffic. Open the URL in a private browser window and on a phone. A useful smoke test covers account creation, sign-in/out, password reset, the main create/edit/delete flow, invalid input, refresh on a nested route, file upload, email, and any payment or AI action.

Watch browser-console errors, network requests, function logs, and database logs while testing. The public build may behave differently because production optimization, server rendering, regions, cookies, or missing environment variables are not identical to the builder preview.

7. Connect the custom domain and update every origin-dependent service

Add the DNS records shown by the host and wait until the domain is verified and HTTPS is active. Pick either the apex domain or www as the primary hostname and redirect the other to it. Configure the page title, description, favicon, social image, canonical URL, robots.txt, and sitemap for the final domain.

A domain change also affects authentication callbacks, allowed origins, CORS, payment return URLs, webhooks, email links, analytics, and third-party API restrictions. Update each service before the final smoke test. DNS may take time to propagate, so do not delete the working platform URL during the change.

8. Launch with monitoring and a rollback plan

Merge or promote the exact commit tested in Preview. Immediately repeat the highest-value user journey on the production domain. Check error logs, response times, authentication, database writes, email delivery, and third-party usage. Set billing or quota alerts for services that can stop or become expensive under traffic.

Record how to restore the previous working deployment and how to reverse a database migration. Application rollback is easy when the database remains compatible; it becomes dangerous when the new release destructively changes stored data. Prefer backward-compatible migrations and remove old fields in a later release.