• Docs
  • Talk to an expert
Blog
Blog
BlogProductCase studiesNewsInsights
Blog

Vibe coding to production: the infrastructure your AI builder doesn't give you

AIAI AgentsAI EngineeringAgentic SDLC
06 October 2026
Share

A founder builds an app with an AI app builder over a weekend and shares the link on Monday. By Friday, the app has paying users, and someone asks a simple question: what happens if the database breaks? That question marks the line between a working app and a production app.

AI app builders such as Lovable, Bolt, Replit, and v0 now handle hosting, a database, and sign-in for a single app. What they typically do not give you is the infrastructure a growing product depends on:

  • Environments that match production, so each change can be tested safely before users see it.
  • Full control of your data, including backups, restores and database migrations.
  • Background processing, such as scheduled jobs, workers and queues.
  • Visibility into problems, through logs, metrics and alerts.
  • Team workflows, such as code review, automated tests and a change history.
  • Compliance and portability, so the app can meet customer requirements and move if needed.

Moving to production usually means exporting the code to Git and deploying it to a platform that provides these pieces. The rest of this guide explains what builders cover today, where apps tend to break, and how to close each gap.
 

What do AI app builders give you in 2026?

AI app builders give you far more than a prototype. Most now include hosting, a managed database, sign-in, and some form of Git export. The table below summarizes what the four most popular builders provide natively.

Builder

Hosting

Database and auth

Git

Environments and recovery

LovableBuilt inLovable Cloud, built on Supabase, with auth, storage, and edge functionsTwo-way GitHub syncBackups can be restored; no separate staging environment documented
BoltBuilt inBolt Cloud database with auth and file storageExport and version controlVersion history does not restore the database
ReplitBuilt inSeparate development and production PostgreSQL databasesGitHub, GitLab and BitbucketPoint-in-time restore for production; deployment previews
v0Through VercelNot built inBranches and pull requests on GitHubA Vercel preview deployment for each branch

That is real progress, and for many apps it is enough. The gaps appear when an app gains paying users, a team, or data obligations. Those gaps are where most production problems start.

Why do vibe-coded apps break in production?

Vibe-coded apps usually break for operational reasons, not because the idea or the interface is wrong. Two public incidents show the pattern.

In July 2025, an AI agent on Replit deleted a live production database during a code freeze. The database held records for more than 1,200 executives and about 1,190 companies. The data was recovered through a rollback, and Replit then separated development and production databases by default.

In May 2025, researcher Matt Palmer disclosed CVE-2025-48757. More than 170 Lovable-built apps had missing or weak row-level security rules. Anyone with the public API key could read data such as emails, phone numbers and payment status. Lovable has since added quick and deep security scans.

Wider studies point the same way. A June 2026 scan of 1,072 vibe-coded apps by Symbiotic Security found at least one security flaw in 98% of them, and a critical flaw in 16%. A CodeRabbit analysis of 470 open-source pull requests found that AI-written code had about 1.7 times more issues than human-written code. Both studies come from companies that sell code security or review tools, so treat the exact figures with some care. The direction is still consistent: AI-generated apps need the checks that production software has always needed.

What infrastructure does a production app need that builders don't provide?

A production app needs a set of capabilities around the code. Builders cover some of them for a single app. The table shows where the gaps usually sit.

Need

What builders usually provide

What production requires

Testing changesA preview, or nothingAn environment for each change, with production services and data
DataA managed database with some restore optionsScheduled backups, tested restores, reviewed migrations and access rules
Background workShort edge or serverless functionsLong-running workers, scheduled jobs and queues
VisibilityBasic logsLogs, metrics and alerts in one place
SecurityScanners for common issuesSecrets and environment configuration kept out of the code, plus human review
Team workflowGit export or syncCode review, automated tests and a deploy history
Compliance and portabilityPlatform-level certificationsRegion choice, audit evidence, and code and data you can move

Can you test a change against real data before users see it?

Most builders let you preview a change, but the preview rarely runs against production-like services and data. That hides the bugs that matter most, such as a migration that fails on real records. On Upsun Cloud, every Git branch can get a preview environment that clones production apps, services, and data in seconds. 

Who owns your database and its backups?

Builder-managed databases are convenient, but they can be hard to move. Lovable's documentation states that there is no one-click migration from Lovable Cloud to your own Supabase project, and the region cannot change after setup. A production database needs scheduled backups, a restore you have tested and migrations that someone reviews.

Where do background jobs run?

Real products send emails, process payments and sync data on a schedule. Edge functions handle short tasks well, but long-running workers and scheduled jobs need their own runtime. Upsun Cloud defines workers and cron jobs in the same configuration file as the app. 

How will you know when something breaks?

Without logs, metrics, and alerts, your users become your monitoring system. A production setup shows errors, slow requests, and resource use in one place, and alerts someone before customers notice.

What happens as you add more apps?

One vibe-coded app is easy to track. Five apps across Lovable, Replit and Vercel mean five deploy processes, five database consoles, and five sets of access rules. This sprawl slows down security reviews and audits, because the evidence lives in separate places.

Is your vibe-coded app ready for production? A checklist

An app is ready for production when it passes each of these checks. Each item stands on its own, so you can work through them in any order.

  • Every database table has access rules, and you have tested them with a second user account.
  • No API keys or passwords appear in the code or in the browser bundle.
  • Secrets and environment configuration are stored in the hosting platform, not in the repository.
  • Backups run on a schedule, and you have restored one successfully.
  • Database changes run as reviewed migrations, not as ad hoc edits.
  • Every change is tested in an environment that matches production before release.
  • Errors trigger an alert that reaches a person.
  • Background jobs run outside the web request.
  • Dependencies are scanned for known vulnerabilities.
  • The code lives in a Git repository that you own.
  • A person or a review step checks each change before it goes live.
  • You know which region stores your users' data.

How do you move a vibe-coded app to production?

Moving a vibe-coded app to production takes nine steps. Most apps do not need a rewrite.

  1. Export the code to a Git repository you own. Lovable and v0 sync with GitHub, Replit supports several Git providers, and Bolt supports export.
  2. Map what the app actually is. Many builder apps are a front end that talks straight to a hosted backend such as Supabase. Decide whether to keep that backend or move to your own database. Both are valid choices.
  3. Audit the code before you move it. Run the builder's security scan, test each access rule with a second account and remove any keys from the front end.
  4. Describe the infrastructure as code. A single configuration file can define the app, its database and its scheduled jobs. The Upsun Cloud example below is illustrative.
  5. Move secrets and environment configuration into the hosting platform's variables.
  6. Migrate the data. Export it, import it into the new database, then test a restore.
  7. Test the full app in a preview environment before any users see it.
  8. Add monitoring and alerts for errors and slow responses.
  9. Switch the domain, and keep the old deployment available for a few days as a fallback.

On Upsun Cloud, this is a single .upsun/config.yaml file that defines the app, its database, and its scheduled jobs

Where should a vibe-coded app run?

The right home depends on how much the app has grown. Staying on the builder is a sound choice for some apps.

Option

Right call when

The builder's own hostingThe app is an internal tool or an early experiment with few users
Vercel or Netlify with a hosted backendThe app is mostly front-end, and the team is comfortable running the backend separately
An application platform such as Upsun Cloud, Render, or RailwayThe app has several services, real user data, or a team shipping changes
A hyperscaler such as AWS, Azure or Google CloudThe company already has platform engineers and wants full control

Upsun Cloud fits teams that want every app, database, and environment in one place, across the cloud regions they choose. The platform holds ISO 27001, SOC 2 Type 2, PCI DSS Level 1, and HIPAA certifications. 

Can you keep building with AI after launch?

Yes. Moving to production changes where the app runs, not how fast you can build. Coding agents such as Claude Code can deploy and inspect Upsun projects through the Upsun skill and the Upsun MCP server.

For teams, Upsun Dispatch adds structure to that work. It turns an issue into a pull request when someone comments @upsun-dispatch implement, pauses at human gates for decisions, and logs every run, including its plan, approver, and cost. 

Frequently asked questions

Do I need to rewrite a vibe-coded app to put it in production?

Most vibe-coded apps do not need a rewrite. They need an audit, a Git repository, secrets and environment configuration moved out of the code, and a hosting setup with backups, monitoring, and test environments.

Is code from AI app builders secure?

Code from AI app builders is not secure by default. The most common problems are missing database access rules and API keys exposed in the browser. Builder security scans help, but a human review is still needed for apps that handle personal or payment data.

Can I keep using my AI builder after moving?

Yes, if the builder syncs with Git. You can keep editing in the builder, push changes to your repository and deploy from there.

Can a vibe-coded app handle real traffic?

Many vibe-coded apps handle real traffic without trouble. Hosting capacity is rarely the first limit. The usual limits are testing changes safely, recovering data and working as a team.

Stay updated

Subscribe to our monthly newsletter for the latest updates and news.

Deploy possibility.
Try Upsun for free.

Build with DispatchDeploy on Cloud