The Last Mile of Vibe Coding Is Production: What AI Builders Still Don’t Handle

You described an app and an AI wrote it. Lovable, Bolt, Cursor, v0, Replit, Claude Code, they’re genuinely good now at turning a sentence into something that runs. Then you try to put it in front of real users, and a different kind of problem starts. The building was the easy part. The last stretch, keeping the thing alive in production, is where most vibe-coded apps stall.

That gap is the whole subject of this page. Not “how do I deploy” (we have a step-by-step deploy guide for that). This is the map of everything the builder quietly left for you to figure out once the app is real, and where to fix each one.

Where the preview ends and production begins

The URL your builder gives you is a demo, not a home. It often sleeps after a few minutes, resets its data, or vanishes when your trial does. That’s fine for showing a friend. It’s not where you put paying users.

Production is a smaller word for a longer list: a place the app runs all the time, a database that keeps your data when you ship a change, a domain with a real certificate, somewhere safe for your keys, and a way to tell what happened when something breaks at 2am. The prompt got you the features. This is the plumbing under them, and it doesn’t write itself.

The things that break once real people show up

Here’s the honest map. Each one is a real wall teams hit, and each links to the fix.

• Your data doesn’t survive a redeploy. Most AI-built apps start on a local SQLite file or an in-memory store. It works beautifully until you push an update, and then the file is gone and so are your users. The fix is a managed database that lives outside the app process, so a new deploy never touches your data. Start with adding a managed database to your app, and if this already bit you, why your app works locally but not in production explains the pattern.
• Secrets leak into the browser or into Git. AI code loves to hard-code an API key or drop it in a file that ships to the client. Anyone can read it. Keys belong on the server, in environment variables, and they need rotating when they leak. See secrets management and environment variables done right.
• Your AI features need memory. A chatbot that forgets the last message, or a search that can’t find your own documents, feels broken. You need a durable store for history and context, and usually vector search for retrieval. Postgres holds the record of truth, pgvector handles embeddings, and managed Redis is the fast layer for sessions and caching.
• Long jobs can’t run inside a web request. Ingesting a document, building embeddings, sending a batch of email, none of that fits in the few seconds a request should take. It belongs in a queue with a worker running beside the app. Background jobs with BullMQ and Redis covers the shape.
• Files need somewhere real to live. PDFs, images, user uploads, they can’t sit on the app’s disk, which is temporary and disappears on redeploy. They go in object storage. Here’s how to store user uploads in object storage.
• Security is your job now. An AI app takes untrusted input and often hands it to a model with real permissions. Prompt injection, key abuse, and data leaks are live risks the moment you have users. Work through the AI app security checklist.
• The model itself is slow, expensive, or down sometimes. Provider APIs rate-limit you, cost more than you expect, and have outages. Real apps cap spend, retry sensibly, and fall back when a model is unavailable. This one is mostly discipline, not a product you buy.
• It has to stay up. A serverless preview that scales to zero pays a cold-start tax on every first request and reopens database connections constantly. A steady app is happier as an always-on process with a stable connection pool. See from prototype to production and database connection pooling.

If you read only one thing here, read the first point. The wiped-database surprise is the single most common way a vibe-coded app loses real user data.

Preview versus production, side by side

The architecture underneath

Once you see the shape, it stops being scary. A production AI app is a handful of boxes with clear jobs: a frontend, a backend that holds the keys, a managed database for the record of truth, Redis for the fast layer, object storage for files, the model API (or a private model) it calls, and logging plus backups underneath, all behind one domain with SSL.

A few opinions, because sitting on the fence helps nobody

• Most AI apps do not need Kubernetes or autoscaling to launch. A right-sized, always-on server beats a serverless maze for a steady product, and you can grow later.
• SQLite is great in development and the wrong choice in production for anything with more than one user. Move before launch, not after the data loss.
• Most production failures are configuration, not code. A missing environment variable, a hard-coded localhost, or a server bound to 127.0.0.1 instead of 0.0.0.0 accounts for a huge share of “it worked on my machine.”

Now lets understand where to go and get theThe infrastructure underneath

The preview is only one part of the story. Once the app is real, you have to decide where everything underneath it lives. The frontend might be on Vercel or Netlify. The backend might be running on Render, Railway or a cloud VM. The database could be RDS, Supabase or another managed PostgreSQL service. Files might sit in S3. Redis might be somewhere else again. Then you add a load balancer, DNS, SSL, monitoring and backups. All perfectly reasonable choices. The problem is that now one application is spread across a collection of different services, each with its own dashboard, documentation, configuration and support.

That isn’t necessarily a bad architecture. For a large team with people who know AWS inside out, assembling the pieces separately can make perfect sense. But for a small team building an AI product, the infrastructure can quickly become a second project. You don’t just have to deploy the application. You have to learn how every service connects to the others. You have to know where the database lives, where the files are stored, which service is handling traffic, where the logs are, and which provider you need to talk to when something stops working. Even a simple issue can take longer to identify because the first question becomes which part of the stack is actually responsible?

This is where platforms such as KloudBean take a different approach. Instead of making the application server, database, Redis, object storage, load balancing and the other pieces of infrastructure separate projects to manage, they bring them together under one login and one management layer. The application can still use the technologies it needs, but the infrastructure around it doesn’t have to be scattered across half a dozen platforms. That changes more than just the number of dashboards you have open. There is less to learn, fewer configurations to keep track of, and less time spent moving between providers to understand what is happening. More importantly, the application and the infrastructure underneath it are visible together. When something goes wrong, you have a much clearer starting point instead of first working out which provider owns the problem. The same applies to support: rather than sending an application issue to one provider and an infrastructure issue to another, the environment can be looked at as a whole.

You also don’t have to give up the individual building blocks to get that simplicity. A production application can still have its own server, PostgreSQL or MySQL database, Redis, S3-compatible object storage, load balancer and the other components it needs. The difference is that those pieces are managed as part of the same environment instead of being stitched together manually. And this is becoming more noticeable with AI-built applications because the application itself can now be produced so quickly. If an AI tool can get you from an idea to a working application in a day, spending the next few days opening accounts, learning different platforms, connecting services and figuring out where to troubleshoot every layer is a strange trade-off.

The infrastructure doesn’t have to be complicated just because the application is modern.

Start with what the application actually needs. Give it a persistent database. Put user files somewhere durable. Keep secrets on the server. Add Redis when you need caching or queues. Add background workers when jobs no longer belong inside a web request. Put a load balancer in front when traffic or availability requires it. Keep backups and monitoring in place from the start.

The difference is whether you have to assemble and manage every one of those pieces independently, or whether they can live together as one production environment.

That’s the part the AI builder doesn’t solve.

It can build the application. It can help write the code. It can even help you work out the deployment.

But the application still needs a proper production environment underneath it and in the AI era, making that environment easier to manage is becoming just as important as making the application easier to build. search end.

FAQ

Where should I host an app I built with Lovable, Bolt, or Cursor?

Anywhere that gives you a persistent process and a real database, not just a preview URL. You want the app running always-on, a managed database that survives deploys, a place for files, and your secrets on the server. A managed cloud like Kloudbean bundles those in one dashboard, or you can assemble them yourself across providers.

Why does my database reset every time I deploy?

Because the app is using a local file (usually SQLite) or in-memory data that lives inside the deploy. Every new build replaces that, so the data goes with it. Move to a managed database that runs outside the app, then a deploy only changes code, never your data.

Do I need serverless for an AI app?

Usually no. Serverless is great for spiky, occasional traffic, but it pays a cold-start cost on the first request and keeps reopening database connections. A steady app is simpler and often cheaper as an always-on process with one stable connection pool.

How do I keep my AI provider API keys safe in production?

Keep them on the server, never in the browser or in your Git repo. Load them from environment variables, call the model provider from your backend rather than the client, and rotate any key that may have leaked. The AI app security checklist walks through it.

What actually breaks when my AI app gets real users?

Data loss on redeploy, leaked keys, an AI feature with no memory, jobs that time out in a web request, files on a disk that disappears, and a provider bill that climbs faster than expected. Each is fixable, and each has a section above.

Do I need a vector database for AI memory?

If your app does retrieval or semantic search, yes, but you probably don’t need a separate product. Postgres with the pgvector extension handles embeddings alongside your normal data, which keeps the stack simple. See pgvector for AI apps.

How do I stop my AI API bill from exploding?

Put limits in front of the model: per-user quotas, a spend cap, authentication so strangers can’t call it, and caching for repeated prompts. Treat the provider API as a metered resource you gate, not an open pipe.

Is a preview URL enough to launch?

No. A preview is a demo. It can sleep, reset, or expire, and it rarely has your own domain, real SSL, or a durable database. Launch on something that runs continuously and keeps your data.

What does ‘production’ mean for a vibe-coded app?

It means the app runs all the time on infrastructure you control, keeps its data through deploys, holds secrets safely, has a domain and SSL, and can be watched and backed up. The prompt gives you features; production is the plumbing that makes those features safe to depend on.

Kloudbean · Build it by prompt. Run it in production.