How to Deploy Your AI-Built App So It Actually Stays Running
Clicking 'Deploy' on Replit is not deployment. Here's what real deployment looks like — environment separation, automated backups, CI/CD pipelines, and hosting that doesn't fall asleep.
The 'Deploy' button on Replit or Vercel makes deployment feel trivially easy. For production apps handling real users and real money, you need proper hosting, backups, environment separation, and deployment pipelines.
I've seen vibe-coded apps serving paying customers from Replit's free tier. No backups. No environment separation. No uptime SLA. The server sleeps after 15 minutes of inactivity, meaning paying customers hit a 30-second loading spinner while it wakes up.
The founder didn't know this was a problem. The Deploy button made it feel done. It wasn't.
Deployment isn't pressing a button. It's the infrastructure that keeps your app running reliably when real users depend on it — at 3am, during traffic spikes, after a bad code push, and when things go wrong. Here are the five layers of production deployment, what each one does, and how to set them up.
Layer 1: Hosting With SLAs
The first decision is where your app runs. For AI-built apps, the three realistic options are Vercel, Railway, and traditional cloud providers (AWS, GCP, or DigitalOcean). Here's when to use each.
Vercel is my default for most builds. It deploys automatically from Git, scales automatically under load, provides preview deployments for every pull request, and includes rollback with one click. The free tier is generous enough for pre-revenue apps. The Pro tier (£20/month) adds team features, higher limits, and priority support. For apps built with Next.js, React, or any frontend framework, Vercel is the fastest path to production-grade hosting.
Railway is the best option for apps that need a traditional server — long-running processes, WebSocket connections, background jobs, or custom server configurations. It offers Git-based deployments, automatic SSL, and straightforward pricing. Think of it as a more developer-friendly Heroku.
Traditional cloud (AWS, GCP, DigitalOcean) makes sense for complex applications that need specific infrastructure: custom networking, managed Kubernetes, or compliance with data residency requirements. For most vibe-coded apps, this is overkill — the DevOps overhead isn't justified until you have significant traffic or specific infrastructure needs.
What to avoid: Replit's deployments for production apps (no SLA, instances sleep after inactivity), free Heroku dynos (the same sleeping problem), and any hosting that doesn't include SSL by default.
The key metric: your hosting should guarantee uptime (99.9% or better), include automatic SSL, and provide a clear path for scaling when traffic grows.
Layer 2: Environment Separation
You need at minimum two environments: development and production. Ideally three: development, staging, and production.
Development is your local setup — where you build and test. It has its own database (never share a database between environments), its own API keys (Stripe test keys, not live keys), and its own configuration.
Staging mirrors production exactly — same hosting provider, same database engine, same environment variables (but pointing to test services). This is where you verify that a change works in a production-like environment before real users see it. Vercel's preview deployments serve as lightweight staging for many apps.
Production is what real users access. It has its own everything — database, API keys, secrets, domain, SSL certificate. Changes only reach production through a tested deployment pipeline, never through direct edits.
Why this matters: Without environment separation, a bug in development breaks production. A database migration test corrupts real user data. A Stripe test charge goes through on a real customer's card. I've seen all three happen to vibe-coded apps running everything in a single environment.
How to set it up: With Vercel + Supabase, you create two Supabase projects (development and production) and configure Vercel's environment variables per-environment. Each deployment context (preview, development, production) uses the correct database, API keys, and configuration automatically.
Layer 3: Database Backups
If your database goes down and you don't have backups, your product is dead. Not figuratively — literally. All your user data, all your application state, all your payment records — gone.
Automated backups should run daily at minimum, hourly for apps with frequently changing data. The backups should be stored separately from the database itself — if the server hosting the database fails, the backups are still accessible.
Tested recovery means you've actually restored from a backup and verified the data is complete and correct. Untested backups are the production equivalent of an umbrella with holes — you won't discover the problem until it's raining.
Point-in-time recovery (PITR) lets you restore the database to any specific moment. This is essential for recovering from bad migrations, accidental data deletion, or corruption. PITR is more expensive than daily snapshots but dramatically more useful.
With Supabase: The free tier includes weekly backups. The Pro tier (£25/month) includes daily backups and point-in-time recovery. For any app handling real user data or payments, the Pro tier is non-negotiable — £25/month for reliable backups is the best investment you can make.
Without Supabase: Set up automated backups using pg_dump (PostgreSQL) on a cron schedule, stored in S3 or equivalent object storage. Test restoration monthly.
Layer 4: CI/CD Pipelines
CI/CD (Continuous Integration / Continuous Deployment) means every code change is automatically tested and deployed through a consistent process. No manual steps, no "I'll just push to production directly."
Why it matters: Manual deployments are error-prone. You forget to run tests. You deploy from a branch that isn't up to date. You skip the build step because you're in a hurry. Each manual deployment is a chance for human error to reach production.
The minimal pipeline:
Push code to Git → Automated tests run → If tests pass, code deploys to staging → Manual review on staging → Promote to production.
With Vercel, the pipeline is almost free. Push to a branch → Vercel builds a preview deployment. Merge to main → Vercel deploys to production. Tests run via GitHub Actions. The entire setup takes 30 minutes.
GitHub Actions is the standard for CI. A simple workflow file runs your test suite on every push. If tests fail, the deployment is blocked. This single check catches the majority of "I broke production" incidents.
What to test automatically: At minimum, run your API endpoint tests and database migration tests. If you have them, include integration tests for critical flows (signup, payment, core features). Even a minimal test suite that just verifies the app builds and the database connects catches 80% of deployment failures.
Layer 5: Rollback Procedures
When a deployment breaks production — and it will — you need to be able to revert to the previous working version in under 5 minutes.
Vercel rollback: One click in the dashboard. Vercel keeps every deployment immutable — you can revert to any previous deployment instantly. This is one of the strongest reasons to use Vercel for production hosting.
Database rollback: If the broken deployment included a database migration, you need to roll back the migration before rolling back the code. This is why migration reversibility (item 25 in the production-ready checklist) is critical. Every migration should have a corresponding down migration.
The rollback procedure: Identify the issue → revert the Vercel deployment → if database changes were involved, run the down migration → verify the app works → investigate and fix the issue in development → redeploy through the normal pipeline.
Document this procedure. Know who can execute it. Practice it before you need it. At 2am when production is down and users are complaining is not the time to learn how rollbacks work.
The Production Deployment Stack
Here's the exact stack I deploy across most builds.
Frontend hosting: Vercel. Automatic deployments from Git, preview environments for every branch, one-click rollback, global CDN, automatic SSL. Free tier for development, Pro (£20/month) for production.
Database: Supabase (PostgreSQL). Managed database with connection pooling, row-level security, automated backups, and point-in-time recovery on the Pro tier (£25/month).
CI/CD: GitHub Actions. Run tests on every push, block deployments when tests fail, automate database migrations.
Monitoring: Sentry for error tracking (free tier sufficient), UptimeRobot for uptime monitoring (free for up to 50 monitors), Vercel Analytics for performance (included in Pro).
DNS and SSL: Cloudflare. Free tier includes DNS, SSL, and basic DDoS protection. Configure your custom domain to point to Vercel through Cloudflare.
Total monthly cost for production infrastructure: approximately £50-75/month. That's the cost of reliable production hosting, automated backups, error tracking, and uptime monitoring. For any app that generates revenue, this is a rounding error.
The Deployment Checklist
Before you consider your app deployed, verify these items.
Environment variables are configured per-environment (dev, staging, production). No secrets in code or Git history. SSL is active and HTTP redirects to HTTPS. Database backups are running and tested. Uptime monitoring is configured with alerting. Error tracking is capturing unhandled exceptions. Custom domain is configured with proper DNS. CI/CD pipeline runs tests before deployment. Rollback procedure is documented and tested. Health check endpoint exists for monitoring.
This takes 2-3 hours to set up. It saves weeks of firefighting.
Frequently Asked Questions
Is Replit ever OK for production?
Replit's paid deployments (Reserved VMs) can work for low-traffic internal tools. For any customer-facing app, especially one that handles payments or sensitive data, Replit's hosting lacks the reliability, security, and infrastructure features you need. Migrate to Vercel or Railway before launching to real users.
How much does production hosting cost?
The stack above costs £50-75/month. Many apps can run on free tiers during early development: Vercel's free tier handles significant traffic, Supabase's free tier works for development and early users. Upgrade to paid tiers before launching to paying customers — the cost is trivial compared to the risk of running production on free infrastructure.
Do I need a DevOps engineer?
No. The stack described above requires minimal DevOps knowledge. Vercel, Supabase, and GitHub Actions are designed for developers (and AI-assisted developers) who don't want to manage infrastructure. The initial setup takes a few hours, and ongoing maintenance is largely automated.
What about Docker and Kubernetes?
For most AI-built apps, Docker and Kubernetes are overkill. They add complexity without proportional benefit for apps with fewer than 10,000 daily active users. If your app eventually needs custom infrastructure, Docker makes sense — but start with managed platforms and migrate when you actually hit their limits.
How do I migrate from Replit to Vercel?
Export your code to a GitHub repository (Replit has a Git integration). Create a Vercel project connected to that repository. Configure environment variables. Set up your custom domain. Test the deployment on Vercel's preview URL. Switch DNS to point to Vercel. The actual migration typically takes 2-4 hours for a standard web application.
---