Where to host your app after you build it with AI

Before you pick a hosting platform, answer one question: what did you actually build?

This sounds obvious. It’s not. I have talked to founders who vibe-coded something with Lovable and could not tell me whether their app had a backend database or just made API calls to third-party services. The answer determines everything about hosting.

Four categories exist, and they have wildly different requirements:

(A) Static frontend with no database and no server-side logic. HTML, CSS, JavaScript. Solved problem. Host on Cloudflare Pages for free, forever, with unlimited bandwidth. Done.

(B) Frontend that calls third-party APIs like OpenAI, Stripe, or a headless CMS. You need serverless functions to hide API keys from the browser. Slightly more complex, still cheap.

(C) Full-stack app with a database. User accounts, stored data, authentication, business logic. This is where most vibe-coded apps land. This is where it gets expensive and complicated.

(D) App running its own AI model. GPU hosting. Different world entirely. Not covered here.

Most vibe-coded apps are (B) or (C). Almost nobody starts by figuring out which one they built.

Your AI tool already chose for you

Here is something that catches people off guard. Your AI coding tool already made hosting decisions, and you probably didn’t notice.

Lovable generates Supabase backends by default. PostgreSQL database, authentication, file storage, edge functions. It exports cleanly to GitHub and you can deploy to Vercel or Netlify. Code lock-in is low. But your data lives in Supabase, and migrating a PostgreSQL database with authentication and row-level security isn’t a weekend project.

Bolt.new deploys to Netlify primarily. GitHub export available. Relatively low lock-in. Your code is standard React or Next.js.

Replit deploys to their own cloud, backed by Google Cloud Platform. This is the highest lock-in of any major AI coding tool. Your app lives at a replit.app subdomain. US-only hosting. Cold starts of 2-3 seconds on the free tier. Moving off Replit means rebuilding your deployment pipeline from scratch.

Cursor is an editor, not a platform. It doesn’t make hosting decisions for you. But the code it generates typically targets Vercel if it is a Next.js project.

Lovable’s own documentation says their generated code is “60-70% production-ready for complex projects.” That means 30-40% still needs work. And Lovable’s CVE-2025-48757 showed that every app on the platform inherited the same Supabase row-level security misconfiguration. Your hosting platform’s defaults become your security posture.

The architecture decisions you should have made first

In building Tallyfy over 10+ years, we went through 707 database migrations and built 80+ data models. Some lessons I’d guess most people learn the hard way:

Tenant isolation at every layer. Not just in your application code. At the URL level, the middleware level, and the database level. If a single misconfigured query can leak data between customers, you will have a breach. This is exactly what happened with Lovable’s CVE. It was a platform-level isolation failure that every app inherited.

Nile, a database company focused on multi-tenant SaaS, documented three production gotchas that only emerge under real load: row-level security without FORCE lets table owners bypass policies, PgBouncer in transaction mode can leak tenant context between connections, and PostgreSQL plan caching interacts badly with tenant-scoping functions. Crunchy Data quantified the overhead: RLS adds 2-4% on indexed tenant columns. Small. Worth it.

API-first architecture. Your frontend and backend should talk through a defined API, not direct database queries from the browser. Vibe-coded apps routinely skip this and put Supabase queries directly in React components. This works until you need a mobile app, a partner integration, or to swap your frontend framework. Then you are rewriting everything.

WorkOS put it well: “Database isolation matters, but the harder problems are identity, routing, configuration, limits, and operations.”

Schema design matters from day one. Every table needs clear ownership. Which user created this? Which organization does it belong to? Foreign keys should enforce relationships at the database level, not just in application code. AI-generated code routinely skips constraints, indexes, and referential integrity. It creates tables that work for a demo but fall apart at 10,000 rows.

Separate templates from instances. If you build any kind of workflow or process tool, don’t let users edit the template while a process is running on it. Version your templates. Processes stay on version N while the template evolves to N+1. AI never generates this pattern unprompted, and it is painful to retrofit.

Decouple side effects from core logic. Notifications, webhooks, activity feeds, analytics events. These shouldn’t be inline with your business logic. AI loves to put everything in one function. The result is spaghetti that is impossible to debug or extend. Use an observer or event pattern from the start.

These are not theoretical concerns. Unkey, an API key management company, spent two years on Cloudflare Workers before rebuilding in Go. Their cache was 30ms+ at the 99th percentile when they needed 10ms. Their conclusion: “Multiple other products were needed to solve artificial problems that serverless itself created.” They saw a 6x performance improvement after migrating.

Amazon Prime Video famously moved their monitoring service from AWS Step Functions and Lambda to a monolith. 90% cost reduction. Step Functions charged per state transition, and their monitoring performed multiple transitions per second of stream.

The architecture specification you didn’t write is now your most expensive technical debt.

The real costs nobody tells you about

Free tiers are vanishing. Basically every major platform has gutted theirs in the past two years.

Railway removed their free tier in June 2023. The minimum is now $5 per month plus usage. Fly.io killed theirs in October 2024. Pay-as-you-go only. Render’s free PostgreSQL databases now expire after 30 days, down from 90. Netlify overhauled their free tier in September 2025 with credit-based plans you cannot revert from. Supabase auto-pauses free projects after 7 days of inactivity. Only Cloudflare Pages still offers genuinely unlimited free static hosting with commercial use.

Here are the real numbers for getting past the free tier:

And then there are the horror stories. ServerlessHorrors.com catalogs them. A $96,000 Vercel bill in one month from runaway functions. A $104,500 Netlify bill from a 3.44MB audio file that got downloaded 55 million times in four days. The Netlify CEO waived it after Hacker News noticed. A $47,000 AWS Lambda bill in one weekend from an infinite loop. A $100,000 Firebase bill in a single day from a DDoS attack on a WebGL game.

The pattern is consistent. Free tiers evaporate. Usage-based pricing spikes without warning. And vibe-coded apps often lack the rate limiting, caching, and spending alerts that prevent runaway costs.

The security checklist before you go live

A VibeWrench scan of 100 vibe-coded apps in March 2026 found 318 vulnerabilities, 89 of them critical. 65% of apps had issues. 70% were missing CSRF protection. 41% had exposed API keys.

Marc Grabanski, CEO of Frontend Masters, wrote about production deployment and nailed it: “Most vibe-coded apps die not from bad code but from secrets in .env files and manual deploy steps that only the builder understands.”

His advice: “Containerize from day one, even if you are a team of one.”

Convex published a practical pre-production checklist that I think is spot on: share with friends early (before you spend money on polish), find functions over 400 milliseconds (the Doherty threshold where users notice), optimize your critical path, evaluate full-stack readiness, do a cleaning pass, and then evaluate whether to stay on your current platform or move.

Before you go live with real users, check these seven things:

1. Move every secret to environment variables. No API keys in code. Not even in .env files committed to Git.
2. Add rate limiting. If someone can hit your API 10,000 times a second, someone will.
3. Enable row-level security if you use Supabase. This is off by default in most vibe-coded apps.
4. Add input validation. AI-generated code trusts all input. Users shouldn’t be able to pass SQL or JavaScript through your forms.
5. Set up error monitoring. Sentry, LogRocket, or even Cloudflare’s free analytics. You need to know when things break.
6. Configure a custom domain. A replit.app or lovable.app subdomain doesn’t inspire confidence with paying customers.
7. Set spending alerts on every platform. Vercel, AWS, Supabase, all of them. Set alerts at $10, $50, and $100. The $96,000 Vercel bill happened because nobody set a limit.

When to stay vs when to migrate

Not every app needs enterprise infrastructure. Some apps are simple enough to stay on their original platform indefinitely.

Stay where you are if: you have under 100 users, you are not generating revenue yet, you are still iterating on the product, and your monthly hosting costs are under $50. At this stage, optimizing infrastructure is yak shaving. Ship features instead.

Consider migrating if: response times are degrading, costs exceed $100 per month without proportional revenue, you need features your platform doesn’t support, or investors and enterprise customers are asking about your infrastructure.

The migration paths that I have seen work:

Replit to Vercel + Supabase: The most common escape path. Export your code, set up a Supabase project, configure Vercel deployment. Expect a weekend of work for a simple app, a week for something complex.

Lovable hosting to self-deployment: Export from GitHub, deploy the frontend to Vercel or Cloudflare Pages, keep Supabase as your backend. The database stays the same, which makes this the easiest migration.

Any platform to Cloudflare Workers: Best cost profile at scale. Free unlimited static bandwidth. Workers handle API routes. But the programming model is different from Node.js, so expect a learning curve.

The Stack Overflow podcast with Heroku’s Chief Architect put it well: “vibe coding is only the initial phase; production-readiness demands traditional engineering discipline.”

Think of hosting platforms in three categories:

One-click platforms like Replit and Lovable hosting are like renting a furnished apartment. Everything works out of the box. You sacrifice control for convenience. Fine for prototypes.

Developer-friendly PaaS like Vercel, Railway, and Render are like renting an unfurnished apartment. You bring your own setup, but the landlord handles maintenance. This is where most production apps should live.

Serious infrastructure like AWS, GCP, and Cloudflare Workers is like buying a house. Maximum control, maximum responsibility. Only worth it when the economics justify the complexity.

For the broader picture on when to use AI coding tools and when to stop, the vibe coding dos and donts covers the research and decision framework. And if you’re building a static website or blog rather than an app, this guide on Astro and Cloudflare Pages covers that simpler case.

Most vibe-coded apps should start on a one-click platform, graduate to PaaS when they hit limits, and consider infrastructure only when they have the engineering team to manage it.

Worth discussing for your situation? Reach out.