How to Deploy a Vibe Coded App Safely

To deploy a vibe coded app, put the code in Git, choose a host that matches what the app is, set secrets in the host instead of the code, publish to a real domain, and test the live address, not only the preview. A static site can go live free on Cloudflare Pages with one command. Facts checked 31 October 2026.

What you will have at the end

• A repository that holds the code you are deploying
• A host chosen for the type of app you built
• Secrets stored in the host, not in files
• A live address on your own domain
• A test routine for the live site and a rollback plan

If you have not built anything yet, start with the vibe coding tutorial, which ends with a free deploy. This guide covers the fuller picture for something real users will see. For what to check before you invite them, pair it with secure a vibe coded app.

Step 1: Know what you built

The right host depends on what the app does. Ask the agent, if you are not sure: "Is this a static site, a front end with an API, or a server application?"

Vibe coding builders such as Lovable, Bolt and Replit publish the app for you with a click. That is the shortest route, and it ties you to their hosting and billing. If you want your own hosting, you need the code in a repository first.

Step 2: Put the code in Git

Do this before anything else. A repository is your backup, your history and your exit.

• If you built in an editor or terminal agent, you already have files. Run git init, commit, and push to a private repository on a Git host.
• If you built in a platform, look for Git sync or export. Lovable's docs say a project's codebase can sync to GitHub, GitLab or Bitbucket and that you keep ownership of it. For others, check the export options. Bolt's help center says you can download a zipped folder of your project files from the project title menu, and Replit's docs describe a Git pane with one-click GitHub sync.

Then add a .gitignore before you commit, so secrets and local files stay out.

.env
.env.*
node_modules/
.DS_Store
dist/

Ask the agent to scan the repository for keys and passwords before the first push. Anything already committed counts as exposed, because history keeps it, so rotate that key rather than hoping nobody saw it.

Step 3: Pick a host and build locally first

Run the app on your own machine before you publish it. Ask the agent how to start it and what the build command is. A build that fails locally will fail on a host, and the error is easier to read on your screen.

For a plain static site, the build step may be nothing at all. For a framework app, expect a build command such as npm run build and an output folder. Write both down, since hosts ask for them.

Step 4: Deploy a static site free on Cloudflare Pages

This route is a good fit for landing pages, portfolios and front ends. Per Cloudflare's docs, Pages supports Direct Upload from the command line with Wrangler. You need npm.

npx wrangler pages project create

Follow the prompts to name the project. Then upload a folder.

npx wrangler pages deploy public

Replace public with the folder that holds your built files. Wrangler prints a preview address when it finishes. The free plan limits that matter here, per Cloudflare's docs, are 500 builds a month, 20,000 files per site and 25 MiB per file. A small site is far below all three.

Cloudflare keeps earlier deployments of a Pages project, so a bad release is not permanent. Its dashboard lists them and its docs cover rolling back to a previous one. That is your safety net, so find it before you need it.

Hosts differ in their steps, and their limits and plans change. Check the current docs for the one you pick. Other options such as Netlify, Vercel and GitHub Pages offer similar flows, and our hosting pages cover where AI workloads themselves run.

Step 5: Set secrets in the host

An app that calls an API needs a key. That key must never sit in the code or the repository. Hosts provide a place for environment variables, usually in the project settings. Put each secret there, and have the code read it from the environment.

A front end that runs in the browser cannot hold a secret at all, because anyone can read what the browser receives. If your app needs a private key to call a paid API, put that call behind a server or serverless function, and keep the key there. This is the most common mistake in vibe coded apps, and an agent will happily put a key in front-end code if you do not forbid it. Add a line to your instructions file: "Never put secret keys in front-end code."

Step 6: Connect a real domain

A preview address is for testing. A custom domain is for customers.

1. Buy or choose a domain at a registrar.
2. In the host, add the custom domain to the project.
3. Add the DNS records the host shows you, or move DNS to the host if it offers that.
4. Wait for the certificate. Hosts usually issue a secure certificate on their own.
5. Visit the address with https:// and check for warnings.

Builders usually offer a custom domain on paid plans. Check which plan before you promise a launch date. If DNS is new to you, ask the agent to explain each record, but make the changes yourself in the registrar, since a wrong record can take a site offline.

Step 7: Test the live address

The preview worked. That is not enough. Production differs: a different address, different environment variables and often a different database. Click through the live site with fresh eyes.

1. Open the live address in a private window. That removes cached files and old sessions.
2. Run the main journey. Sign up, sign in, do the one thing the app is for, sign out.
3. Try a second account. Confirm it cannot see the first account's data.
4. Submit every form. Check that the data arrives where you expect, including email.
5. Test on a phone. Layout and keyboard behavior often break on small screens.
6. Open the browser console. Look for red errors and for failed requests.
7. Check the secret keys. In the browser's source view, search for anything that looks like a key.

If the app uses a Supabase-style database, check access rules now. Supabase's docs state that a table in an exposed schema without row level security is readable and writable by any role with a grant on it, and recommend enabling it on every table in an exposed schema. That one setting is the difference between a private app and a public database. See the security guide for the full list.

Step 8: Plan for failure

Before you announce the app, answer four questions.

Keep the deploy to one command. A script or an npm script that builds and then runs the deploy removes the chance of deploying from the wrong folder. Ask the agent to write it, and to explain each line. Read the explanation before you trust it.

Staging before production

If real people will use the app, add a middle step. A staging copy is a second deployment with its own address, its own database and test data. You publish there first, click through it, and only then publish to the real domain.

You do not need a large setup. On a static host, a second project named myapp-staging is enough. For a backend, create a second database project with fake records. The benefit is that a mistake lands where nobody is watching. An agent changing data on staging cannot hurt a customer.

Keep the two environments apart in three ways. Use different keys for each. Use different environment variables in each host project. And never copy real customer data into staging unless you have a plan to protect it, since test environments usually have weaker controls.

What the agent should and should not do during a deploy

Agents are useful here and risky here. Let the agent write the deploy script, explain each line and check the build output. Do not let it run commands against production on its own. A deploy command is a change to what customers see, and a database command is a change to what customers own.

Give the agent a staging target and read-only access to production logs. Run the production deploy yourself, with the script the agent wrote and you reviewed. If you use a terminal agent with permission rules, deny commands that touch production, and require a person to approve them.

After launch: the first week

Launch is the start of the checking, not the end. In the first week, do four things.

1. Watch the logs and the uptime monitor daily. Errors you did not predict will appear.
2. Read every form submission and support email. Early users find what testing missed.
3. Check usage and cost. Compare to what you expected and look into any gap.
4. Keep a list of fixes and batch them. One carefully tested release beats five rushed ones.

If something breaks badly, roll back first and investigate second. A working old version is worth more than a half-fixed new one, and the host's earlier deployments exist for that moment.

Common deploy problems

Costs to expect

A static site can cost nothing on a free plan. An app with a database, sign-in and storage has usage-based parts, so costs grow with traffic. Builders add credits for further changes. Set a budget alert if the host offers one, and check usage after the first week. A surprise bill usually comes from a loop or a bot, so look at traffic when a number looks odd.

Our take

Deploying is where vibe coded apps meet reality. The code is the easy part now. What decides whether the launch goes well is the boring list: code in Git, secrets in the host, a second account tested on the live address, and a way back.

If you are a beginner, start with a static site and Cloudflare Pages, because it is free and the rollback is built in. If your app needs a backend, take the extra hour to read the access rules, and test as a second user before you tell anyone the address.

Checklist

• Code is in a private Git repository
• .gitignore excludes .env and local files
• No secret keys in front-end code
• Secrets set in the host's environment settings
• Custom domain connected, https works
• Live address tested in a private window and on a phone
• A second account cannot see the first account's data
• Rollback steps and backups written down
• An uptime monitor emails you

Related pages

• Secure a vibe coded app
• Vibe coding tutorial
• Best vibe coding platform
• Is vibe coding bad
• Cursor and Supabase app stack