Coding Agent Cloud How it works Pricing For agencies About us Contact Careers Blog Login Start your coding agent

Guide

How to Deploy an AI App (Without Touching a Server)

You built something real with Lovable, Bolt, v0 or Cursor. The preview works. Now what? This guide walks through the five paths from AI builder output to a production deployment that real users can rely on, with honest tradeoffs for non-technical founders.

What "deploy" actually means for an AI-built app

Hitting the publish button in Lovable or Bolt is not deployment. It is a hosted preview on shared infrastructure that is fine for demos, expensive for production, and impossible to scale or customise. Real deployment means four things in parallel: a server (or container) running your app, a custom domain with SSL, environment variables for your secrets, and monitoring so you find out when things break before your users do.

The five paths from AI builder to production

  1. Builder native hosting. Stay on Lovable Cloud, Bolt's hosting, or Replit. Fastest path, zero technical knowledge, but you pay premium for little flexibility and lock yourself in.
  2. Vercel or Netlify. Free tier, one click GitHub integration. Great for frontend only apps. Hits a wall on persistent backend processes, queues, or heavy database operations.
  3. Railway, Render or Fly.io. Better for full stack. Run real backend processes. Slightly more DevOps knowledge required. Egress and bandwidth fees add up at scale.
  4. Your own VPS or cloud. Hetzner, GKE, EKS. Maximum control, lowest cost at scale, but you sign up for the entire DevOps stack: CI/CD, monitoring, backups, security patches.
  5. Managed deployment service. Someone else owns the DevOps. Ployed for example: an engineer reviews every release, you keep building in a canvas editor, your time stays on the product.

Which one fits you? If your app has five users and you already pay for Lovable Pro, stay on builder native. Real launch with paying customers? Path 4 or 5. Path 2 and 3 are the middle ground for those comfortable with a bit of config.

What breaks when you DIY

Three things that consistently go wrong for vibecoders walking the deployment path alone, based on what we see at Ployed:

Secrets in the bundle

Lovable and Bolt routinely place API keys in frontend code. Fine in development, dangerous in production. Anyone visiting your site can pull your OpenAI, Stripe, or Supabase keys from the bundle. The fix is moving everything to environment variables, but it requires touching every file that uses them.

Missing Row Level Security

Apps using Supabase or Firebase regularly forget to enable RLS. The result: every logged in user can read or mutate every other user's data. This shows up in headlines. The tools try to warn you, but in practice people click through.

No rollback path

If your live deployment crashes, how do you get back to the version that worked? Vercel and Railway give you that. Builder native hosting often does not. A bare VPS without CI/CD does not. You discover this exactly when you cannot afford to.

The minimum production checklist

  • Custom domain with valid SSL (no app.lovable.dev/yourname)
  • All secrets in environment variables, not in code
  • Database with automatic backups, not monthly manual ones
  • Error monitoring (Sentry or equivalent) so you know before users do
  • A rollback path: back to the previous working release in under five minutes
  • Security check against the OWASP Top 10, or at minimum a critical pair of human eyes
  • Privacy policy and cookie banner if you operate in the EU

Why human in the loop still matters

Vibe coding has matured fast in the last two years. Lovable, Bolt and Cursor produce code that visibly works. But "visibly works" is not "ready for production". A human reading the codebase catches what no AI catches: subtle auth holes, faulty assumptions about data shape, dependencies with known CVEs, code that only works in development by accident.

That is why Ployed runs a human in the loop deployment workflow: you build as much as you want with AI, when you want to ship an engineer reviews the code and runs the deploy. No week long wait, no agency invoice, just a safety net for the moment things actually have to work.

When to consider a managed service

  1. You lose a day a week to deployment, infra issues, or debugging why production behaves differently from local.
  2. You have paying customers and cannot afford an hour of downtime.
  3. You want to ship features but are afraid of breaking what already works.

At that point a managed deployment service starts paying for itself. Read more about managed deployment for AI apps or about why human in the loop matters.

Frequently asked questions

How long does deployment take the first time?

From scratch with no DevOps experience: a day to a weekend. With experience: a few hours. With a managed service: minutes from your end.

Can I keep building in Lovable after deploying to my own infra?

Lovable's GitHub sync supports two way edits if you set it up. Or use a tool like Ployed's canvas editor that gives you the chat experience without leaving your production codebase.

Do I need a developer to deploy?

For builder native: no. For Vercel: a learning afternoon. For real production with custom backend: either learning or a service that does it for you.

Ready to ship your app?

Ployed handles deployment, security and monitoring. A real engineer reviews every release. You keep building in the canvas editor.

Start your project