Vibe-coded app to production: from Lovable, Replit or Bolt to AWS.
Taking a vibe-coded app to production is mostly security work, not hosting work: the database rules, the keys in the browser bundle and the backups. Lovable, Replit and Bolt get an app in front of users in an afternoon; real customers, payments and personal data are a different job. Below: what each tool actually generates and hosts today, when it's fine to stay, a 14-point security checklist, the public incidents behind it, a step-by-step path to AWS, and what each option costs, with the maths shown.
Facts checked: 31 Oct 2026, against vendor pricing pages, docs and the incident reports linked below. AWS prices checked: 31 Oct 2026, us-east-1, on-demand list prices
How do you take a vibe-coded app to production?
Secure it where it is first, and move it only when there's a reason. Most of the risk in a vibe-coded app isn't the host. It's the database rules, the keys in the browser bundle and the missing backups. Those problems move with you to AWS unless you fix them, and they can all be fixed without moving. So the order is:
- Run the vibe-coded app security checklist in section 05 on the app as it is today. That is a day or two of work, not a migration.
- Decide whether to stay. For a prototype, an internal tool or an app with no personal data, staying on Lovable, Replit or Bolt is usually the right call.
- Move to AWS when a reason appears: an enterprise customer's security questionnaire, SOC 2, a hosting bill that's growing faster than usage, AWS Activate credits you can't spend on the builder, or a team of engineers who now own the code.
The move itself is ordinary engineering: export the repo, make it build outside the tool, containerise it, add CI, then choose whether the database stays on Supabase or moves to RDS. Sections 06 to 08 cover that, and section 09 prices it.
Sources: Lovable FAQ, Lovable Cloud, Lovable GitHub sync, Replit databases, Replit Deployments, Replit Git pane, Bolt Cloud launch, Bolt database, Bolt publishing, Netlify on Bolt.
What do Lovable, Replit and Bolt actually build and host?
Lovable writes a TanStack Start or React + Vite app on Lovable Cloud, which uses Supabase's open-source foundation; Replit runs the app on Replit Deployments with managed PostgreSQL; Bolt builds web apps that it hosts on Netlify. The three tools look alike from the chat box, but underneath they produce different apps, and that decides how hard the move is later.
| Lovable | Replit | Bolt | |
|---|---|---|---|
| Frontend it writes | New apps (since 13 May 2026; 22 June for Enterprise): TanStack Start, rendered on the server. Older apps: React + Vite, rendered in the browser. | Whatever stack the Agent picks for the app. | JavaScript web apps that build to static files (Netlify's guide deploys the dist/ folder). |
| Database | PostgreSQL, through Lovable Cloud (which uses Supabase's open-source foundation) or your own Supabase project. | Managed PostgreSQL, with separate development and production databases. | Bolt Cloud's managed database, or Supabase if you pick it at project setup on Pro or Teams. |
| Auth, storage, functions | Lovable Cloud: login, file storage, edge functions, secrets, scheduled jobs. | In the app's own code, next to Replit's database and deployments. | Bolt Cloud: auth, functions and file storage (in private beta at the August 2025 launch). |
| Hosting | Lovable hosting; publishing to lovable.app is free on all plans. | Replit Deployments: Autoscale, Reserved VM, Static, Scheduled. | Bolt hosting on bolt.host, which runs on Netlify, or a Netlify account of your own. |
| Getting the code out | Git sync on any plan creates a new GitHub, GitLab or Bitbucket repo (it can't attach an existing one). ZIP download on paid plans. | Connect GitHub from the Git pane and push the project. | Export the project, or connect a GitHub repo. |
| Getting the data out | Separate database export. It excludes stored files, Edge Function code and secrets. | Standard Postgres tools against the database. | Export row data from the Tables view. No supported path from a Bolt database to Supabase. |
Two details matter. A new Lovable app is no longer a static site: TanStack Start runs server-side rendering and API routes, so it needs a Node server, not just an S3 bucket. Older React + Vite Lovable apps are static and can sit on a CDN. Check which one you have before pricing anything.
On Bolt, Netlify's guide says a project published to Bolt hosting can't later move to Netlify; you start a fresh copy. If you want your own Netlify account, choose it before the first publish.
Sources: Lovable plans, Lovable credits, Replit pricing, Replit deployment pricing, Replit August 2026 price change, Replit usage billing, Bolt pricing, Supabase pricing.
How much do Lovable hosting, Replit deployments and Bolt cost?
Lovable Pro and Bolt Pro are $25 a month each, with hosting included; Lovable's backend and hosting draw on Cloud credits. Replit is a $20 or $100 plan plus usage: a Reserved VM from $15 a month, and a production database billed for every hour it's awake.
| Item | Price | What it buys |
|---|---|---|
| Lovable Pro | $25 /month | 100 credits, custom domains, no "Edit with Lovable" badge. |
| Lovable Business | $50 /month | 100 credits, SSO, Security center. Workspace data excluded from training by default. |
| Lovable Cloud (hosting, database, backend) | credits | A monthly grant of 20 Cloud credits on Free, Pro and Business, then your credit balance. Lovable lists the cost drivers (database server and storage, network, compute, realtime) but no per-unit rates. |
| Replit Core / Pro | $20 / $100 /month | The plan you build on. Core includes 100 GiB of outbound data a month. |
| Replit Reserved VM, shared 0.5 vCPU, 2 GB | $15 /month | An always-on server. Dedicated 1 vCPU, 4 GB is $35; 2 vCPU, 8 GB is $50. |
| Replit Autoscale | $0.60 /M compute units + $0.40 /M requests | Plus a small monthly base fee. Scales to zero between requests. |
| Replit production database | $0.16 /compute hour + $0.35 /GiB-month | Active while it gets requests and for 5 minutes after the last one. Storage price cut from $1.50 on 1 August 2026. |
| Replit outbound data | $0.05 /GiB | Beyond your plan's allowance. |
| Bolt Pro | $25 /month | 10M tokens, hosting, custom domain, no Bolt branding, up to 1M web requests a month. |
| Bolt Teams | $30 /member /month | Pro features per member. |
| Supabase Pro (if you run your own) | from $25 /month | $10 of compute credit (one Micro instance), 8 GB disk, daily backups kept 7 days, 100,000 monthly active users. |
On Lovable, $25 buys 100 credits on Pro, so a credit is worth about $0.25 there, and the 20-credit Cloud grant covers roughly $5 of hosting and backend a month. Business credits are valued at $0.50, so fewer are deducted for the same usage. Lovable calls these monthly grants "a temporary offering and subject to change", and its docs say the current chat pricing applies only through 31 October 2026, the day we checked, so check the plans page again before you budget. One production detail: when the workspace runs out of credits, Lovable says apps on its built-in backend pause. Turn on auto top-up, or watch the balance.
Replit is the one where the database line surprises people. The compute is billed by the hour the database is awake, and a production app with traffic all day keeps it awake.
| Illustrative: one Replit app on a Reserved VM | Arithmetic | $ /month |
|---|---|---|
| Reserved VM, shared 0.5 vCPU, 2 GB | list price | 15.00 |
| Database, quiet app: active 6 hours a day | 180 h × $0.16 | 28.80 |
| Database, busy app: active all month | 730 h × $0.16 | 116.80 |
| Database storage, 2 GiB | 2 × $0.35 | 0.70 |
| Hosting, quiet app | plus the $20 or $100 plan | 44.50 |
| Hosting, busy app | plus the $20 or $100 plan | 132.50 |
Usage figures are made up for the example; the rates are Replit's, checked 31 Oct 2026. Replit's deployment pricing page lists a $2 Autoscale base fee and its August 2026 billing note says $1, so we left Autoscale out. For comparison, a db.t4g.micro PostgreSQL instance on RDS lists at $11.68 for the whole month (section 09).
When is it fine to stay on Lovable, Replit or Bolt?
Stay while the app is a prototype, an internal tool or a small product with the checklist below done. Move when a customer, an auditor, the bill or your AWS credits give you a reason.
| If this is you | Our advice |
|---|---|
| A demo, prototype or landing page, no sign-ups yet | Stay. Spend the time on the product. |
| An internal tool for your own team, behind login | Stay, after the checklist. Business-plan SSO helps here. |
| Real users, personal data or payments, small team | Stay for now, but run the full checklist this week and turn on backups. |
| An enterprise prospect sent a security questionnaire, or SOC 2 is on the roadmap | Move, or at least move the database and backend into accounts you control. SOC 2 on AWS for startups lists what the auditor will test. |
| The builder bill grows faster than your usage | Price the AWS version with section 09 before deciding. |
| You have AWS Activate credits and engineers now own the code | Move. Credits can pay for AWS; they can't pay for Lovable, Replit or Bolt. See how AWS Activate credits work. |
Staying is not the risky option. Staying with RLS off is. A Lovable or Bolt app with correct policies, no secrets in the browser and tested backups is in better shape than a careless copy of the same code on AWS.
Sources: Supabase RLS, Supabase API keys, Supabase Security Advisor lints, Lovable security, Lovable on build-time variables, AWS WAF pricing.
How to secure a vibe-coded app: the 14-point security checklist.
Turn on RLS with policies that limit every row to its owner, keep secret keys out of the browser, let only the server write payment and role fields, and keep backups you have actually restored. All of it comes before any decision about hosting. Each line below is a check you can run yourself, and the order roughly follows how much damage the gap does. Most of these apps talk to Supabase straight from the browser, so the database rules are the security model. There's often no server in between to catch a mistake.
| Check | How to test it | The fix |
|---|---|---|
| 1. No secret keys in the frontend | Build the app and search the output (dist/ or the browser's sources tab) for service_role, secret and your payment provider's live key prefix. | Supabase's docs say a secret or service-role key bypasses RLS and must never be in a browser, a shipped app or source control. Move the call into an edge function or server route, then rotate the key. |
2. Nothing secret in a VITE_ variable | List every VITE_ variable in .env and the build settings. | Lovable's docs say VITE_ variables are embedded at build time, which means they ship to every visitor. Only the Supabase URL and publishable key belong there. |
| 3. RLS on every table | Run Supabase's Security Advisor. Lint 0013_rls_disabled_in_public means a table anyone can read and write. | Enable RLS on every table in an exposed schema, then write a policy per table. With RLS on and no policy, the API returns nothing, which is the safe failure. |
| 4. Policies that actually restrict | Sign up as two test users. As user B, call /rest/v1/<table> with the publishable key and B's token, and try to read or change A's rows. | Watch for lint 0024_permissive_rls_policy (USING (true)) and 0015_rls_references_user_metadata, which trusts a field users can edit. Scope rows to auth.uid(). |
| 5. Storage buckets | Look for lint 0025_public_bucket_allows_listing; try listing a bucket while signed out. | Private buckets for user uploads, signed URLs for downloads. |
| 6. Payments and roles set by the server only | Can a signed-in user update their own plan, role or payment_status column? | Write those columns only from a Stripe webhook or server function. Block them in the update policy. |
| 7. Server functions check the user | Read every edge function and server route. Does it verify the session, or trust a user_id in the request body? | Derive the user from the verified token, then check ownership before every read or write. |
| 8. Auth settings | Check email confirmation, password reset, OAuth redirect URLs and lint 0012_auth_allow_anonymous_sign_ins. | Redirect URLs limited to your domains. Anonymous sign-ins off unless the product needs them, and then excluded in policies. |
| 9. Rate limits | Script 200 sign-up or AI-prompt requests in a minute and see what happens. | Limit sign-up, login and anything that calls a paid AI API. On AWS, a WAF rate-based rule costs $1 a month plus the $5 web ACL and $0.60 per million requests. |
| 10. Backups you have restored | Which plan is the database on? When did anyone last restore it? | Supabase Free has no backups; Pro keeps daily backups for 7 days. Restore one into a scratch project and time it. More in the disaster recovery plan guide. |
| 11. Dev and production separated | Can the AI agent, or a laptop, write to the production database? | Separate databases and keys per environment. The agent works against development only. |
| 12. Dependency CVEs | npm audit on the exported repo; turn on Dependabot alerts in GitHub. | Patch criticals within days, not months. Our DevSecOps page has deadlines by severity. |
| 13. Keys that were ever pasted | Search the chat history and the Git history for keys. | Rotate anything that was ever in chat, a commit or a screenshot. Lovable now warns when you paste a key into chat. |
| 14. Accounts owned by the company | Whose personal email owns the Lovable, Supabase, GitHub, Stripe and domain accounts? | Company-owned, with MFA, and at least two admins. |
Lovable's own tools help with several of these. Its Quick scan runs on every publish and checks database access rules, dependencies and MCP server exposure; the Deep scan, which you start by hand, reviews the code for access control, injection, leaked secrets, payments and authentication issues. Lovable is also clear about where the line is: its docs say "You are responsible for ensuring that your app meets the security requirements" and that the tools "cannot guarantee complete security". Treat a clean scan as the start of the review, not the end.
The publishable (anon) key in your frontend is not the problem on its own. Supabase designed it to be public: it only reaches what RLS allows. The problem is when RLS allows everything.
If you'd rather have an engineer run this list against your app, our fixed-price AWS readiness review covers these checks along with the AWS side.
Sources: Matt Palmer on CVE-2025-48757, Escape research, The Register, Apr 2026, The Register, Jul 2025, Wiz on Base44.
Have vibe-coded apps been breached? The public record.
Yes. The documented cases include Lovable apps exposing tables because RLS was off, scans finding secret keys in frontend bundles, a reported case of Replit's agent deleting a production database, and an auth bypass in the Base44 platform. Below are only documented cases, each figure from the source linked beside it. Where the vendor disputes a claim, we say so.
| When | What happened | The lesson |
|---|---|---|
| Mar to May 2025, Lovable | Researchers scanned 1,645 projects from Lovable's showcase site and found 303 exposed endpoints across 170 of them (10.3%), including user, transaction and subscription tables and some third-party API keys. Published as CVE-2025-48757 on 29 May 2025. The researchers say the cause was missing RLS, not the public anon key, and that Lovable publicly denied the issue at the time. | Checks 3 and 4. The scan only looked at homepages, so it's a lower bound. |
| Same research, the Linkable site | The researchers inserted a record and set "payment_status": "paid" to get past Stripe. | Check 6: never let the client write payment state. |
| Jul 2025, Replit | SaaStr's founder reported that Replit's agent deleted his production database during a code freeze. Replit's CEO called it "Unacceptable and should never be possible" and announced automatic separation of development and production databases. | Check 11, and backups you control (check 10). |
| Jul 2025, Base44 | Wiz found that anyone with an app's public app_id could register and verify an account on a private Base44 app, getting past SSO. Fixed within a day of the report; Wix, which owns Base44, found no evidence of past abuse. | Check 8: the platform's auth layer can have bugs too. Keep your own authorisation checks on data. |
| Oct 2025, several platforms | Escape passively scanned more than 5,600 public apps, mostly Lovable, plus Create.xyz, Base44, Vibe Studio and Bolt.new. It reported more than 2,000 vulnerabilities, 400+ exposed secrets and 175 cases of exposed personal data, and found service keys in frontend bundles. | Checks 1 to 3. Escape calls its figures a lower bound. |
| Apr 2026, Lovable | A researcher said a free account could reach other users' project source code, database credentials and AI chats on projects created before November 2025. Lovable first said it did not suffer a data breach and that access to public projects was intended, then apologised and said it had accidentally re-enabled chat access on public projects in February, and reverted that. The Register reported the claims without saying it had verified them. | Check 13: rotate credentials that ever lived in project code or chat. |
None of these needed a clever attacker. They needed someone to look. That's also why moving to AWS doesn't fix them by itself: the same missing policy is just as open on RDS behind a Supabase-style API.
How should you deploy an AI-generated app to AWS?
In one of three shapes: move only the frontend and keep Supabase, move everything to ECS Fargate and RDS, or stay on the builder and harden it. The first is the quickest; the second suits enterprise customers, SOC 2 and spending Activate credits.
| Option | What moves | Good for | Watch out for |
|---|---|---|---|
| A. Frontend on AWS, keep Supabase | The web app goes to CloudFront and S3 (static React + Vite) or a container on Fargate (TanStack Start). The database, auth and storage stay on your own Supabase Pro project. | The quickest move. Your domain, CI and logs are yours; users keep their logins. | Supabase is still a second vendor in your security review. Lovable's managed OAuth, connectors and AI features only work on its built-in backend. |
| B. Everything on AWS | Frontend and backend on ECS Fargate, Postgres on RDS, files on S3, auth replaced or self-hosted. | Enterprise customers, SOC 2, private networking, spending Activate credits. | Auth is the hard part. Self-running Supabase Auth keeps users' passwords; Cognito can import their bcrypt hashes but changes the sign-in flow. Either way, expect everyone to sign in again once. Our Supabase to AWS page covers the database and auth move. |
| C. Stay on the builder, harden it | Nothing. You fix sections 05 and 10 in place. | Prototypes, internal tools, small user bases. | You keep the builder's limits and its pricing changes. |
For the compute, we'd use ECS on Fargate, not Kubernetes; ECS vs EKS for startups has the reasoning. ECS Express Mode is the shortest path for a single web app: give it a container image and two IAM roles, and it creates the Fargate service, an HTTPS load balancer, a certificate, autoscaling, a log group and a deployment alarm. Up to 25 Express services in one VPC can share a load balancer.
Sources: Lovable on hosting elsewhere, Lovable export, GitHub OIDC with AWS, Secrets Manager pricing, RDS backups.
How to deploy a Lovable, Replit or Bolt app to AWS, in eight steps.
Export the code to a repository you own, make it build outside the tool, put it in a container or on CloudFront, add CI, decide where the database lives, move the secrets, add monitoring and tested backups, then cut over DNS. The same order works for all three tools.
1. Get the code into a repository you own.
On Lovable, Git sync creates a new repository in your GitHub, GitLab or Bitbucket organisation and keeps syncing both ways on one branch. Put it in the company's organisation, not a founder's personal account. On Bolt, connect GitHub or export the project; on Replit, push the project to a new GitHub repository. From here on, the repository is the source of truth.
2. Make it build outside the tool.
Clone it and run npm ci then npm run build on Node 22, which Lovable recommends. Older Lovable apps output to dist/. Collect every environment variable the build needs. If the build only works inside the builder, you've found your first task.
3. Containerise it, or put it on a CDN.
- TanStack Start (new Lovable apps): Lovable's docs say to build with
NITRO_PRESET=node-server npm run buildand runnode .output/server/index.mjs, which listens on port 3000. Wrap that in a small Dockerfile on anode:22image and push it to ECR. - React + Vite (older Lovable apps, most Bolt apps): upload
dist/to a private S3 bucket behind CloudFront, with a custom error response that returnsindex.htmlwith status 200 for unknown routes. Don't use S3's website error page, which returns 404. - Replit apps with their own server: the same container route as TanStack Start, with the start command from the repl's run configuration.
4. Add CI before the first deploy.
A GitHub Actions workflow that runs the build, npm audit and tests, builds the image and deploys on merge to main. Authenticate to AWS with OIDC through aws-actions/configure-aws-credentials, which GitHub describes as reaching AWS "without needing to store the AWS credentials as long-lived GitHub secrets". If Actions minutes are a worry, see GitHub Actions pricing.
5. Decide where the database lives.
Keep Supabase (option A) by moving to a Supabase project in your own organisation on the Pro plan. From Lovable Cloud that is not one click: Lovable's docs list the steps: apply the migration files to a new Supabase project, restore the database export with pg_restore, upload the storage files, add the function secrets and deploy the Edge Functions. Or move Postgres to RDS (option B); the Supabase-specific parts, auth schema, storage and RLS-based API, are what make that a project, and the Supabase to AWS guide walks through it.
6. Move secrets out of the code.
Secrets stored in Lovable aren't exported, so list them from the app and recreate each one. On AWS, put them in SSM Parameter Store or Secrets Manager ($0.40 per secret a month plus $0.05 per 10,000 API calls) and let the ECS task definition inject them as environment variables. Rotate every key while you're at it; the old ones lived in a third-party tool and maybe in chat.
7. Add monitoring and backups you've tested.
Send container logs to CloudWatch with a retention period set, and add alarms on 5xx errors, task restarts and database storage. For application errors, add an error tracker such as Sentry (priced for a small team). Before you add Datadog on top, read how Datadog pricing adds up. On RDS, turn on automated backups with retention you chose on purpose and deletion protection, then restore a backup into a scratch instance and time it. AWS gives you free backup storage equal to your provisioned database storage. The production readiness checklist has the full list.
8. Cut over, and recreate what the builder did quietly.
Lower the DNS TTL a couple of days before, point the domain at CloudFront or the load balancer, and keep the old deployment untouched for a week as your way back; our Heroku to AWS migration guide has the same DNS and rollback steps in more detail. Then work through what Lovable's docs say doesn't come with you: scheduled jobs, managed OAuth and token refresh, connectors and AI features, which need your own provider accounts. Signed-in users will have to sign in again; Lovable's docs say passwords come across with the database export, so nobody has to reset one. Your lovable.app or bolt.host address keeps serving the last version you published there, so unpublish it once you're done.
On-demand list prices, us-east-1, checked 31 Oct 2026, 730 hours a month. Excludes data transfer out, DNS and tax.
Sources: Fargate, RDS for PostgreSQL, ELB, VPC (public IPv4), CloudFront, WAF, Secrets Manager, CloudWatch, ECR, Supabase.
How much does a vibe-coded app cost to run on AWS?
In these two illustrative bills: $25.00 a month with the frontend on CloudFront and Supabase kept, and $76.80 at launch, rising to $136.54 for paying customers, with everything on Fargate and RDS. Usage is made up for the example; every unit price is a list price we checked on the date above.
App 1, illustrative: an older React + Vite Lovable app, frontend on AWS, Supabase kept.
| Line item | Arithmetic | $ /month |
|---|---|---|
| CloudFront flat-rate Free plan | 1M requests and 100 GB included, with WAF and DDoS protection | 0.00 |
| S3 for the built site, under 5 GB | covered by the plan's 5 GB S3 storage credit | 0.00 |
| Supabase Pro, your own organisation | $25, Micro compute covered by the $10 credit | 25.00 |
| Total | 25.00 |
Past 1M requests or 100 GB a month, the CloudFront Pro plan is $15 for 10M requests and 50 TB. Flat-rate plans aren't open to accounts still on the AWS Free Tier; there, pay-as-you-go CloudFront includes 1 TB and 10M requests a month free. This shape costs about what Lovable Pro does, but now the domain, the CDN, the backups and the database belong to you.
App 2, illustrative: a TanStack Start or Replit app, all on AWS (option B).
| Line item | Arithmetic | $ /month |
|---|---|---|
| Fargate, 1 task, 0.5 vCPU, 1 GB, x86 | 0.5 × 730 × $0.04048 + 1 × 730 × $0.004445 | 18.02 |
| Public IPv4 on the task | 730 × $0.005 | 3.65 |
| Application Load Balancer, hourly | 730 × $0.0225 | 16.43 |
| ALB, 1 LCU average | 730 × $0.008 | 5.84 |
| ALB public IPv4, 2 AZs | 2 × $3.65 | 7.30 |
| RDS PostgreSQL db.t4g.micro, Single-AZ | 730 × $0.016 | 11.68 |
| RDS storage, 20 GB gp3 | 20 × $0.115 | 2.30 |
| RDS backups, 7 days | inside the free allowance (100% of DB storage) | 0.00 |
| AWS WAF, 1 web ACL, 2 rules, 1M requests | $5 + 2 × $1 + $0.60 | 7.60 |
| Secrets Manager, 4 secrets | 4 × $0.40 | 1.60 |
| CloudWatch Logs, 3 GB ingested, 6 GB stored | 3 × $0.50 + 6 × $0.03 | 1.68 |
| CloudWatch alarms, 5 standard | 5 × $0.10 | 0.50 |
| ECR, 2 GB of images | 2 × $0.10 | 0.20 |
| Total, launch shape | 76.80 | |
| Add a second task for availability | $18.02 + $3.65 | + 21.67 |
| Move to db.t4g.small Multi-AZ | 730 × $0.065 − $11.68 | + 35.77 |
| Multi-AZ storage, 20 GB | 20 × $0.23 − $2.30 | + 2.30 |
| Total, paying-customers shape | 136.54 |
Tasks in public subnets with their own IPs avoid a NAT gateway, which is how this stays under $80. Once the database and tasks go into private subnets, add a NAT gateway; the AWS cost guide prices that shape. Running the same tasks on ARM (Graviton) lists at $0.03238 per vCPU-hour and $0.00356 per GB-hour, about 20% less, if your image builds for it.
Against the Replit example in section 03, the busy app's database alone ($116.80) costs about 86% of this whole paying-customers setup. Against Lovable or Bolt Pro at $25, AWS costs more in cash until you have credits to spend. The bigger cost is people: someone has to own the Terraform, the upgrades and the alarms, whether that's a hire or a fractional DevOps engineer.
Can you keep vibe coding in production?
Yes, as long as every change reaches production through a pull request and CI, and the agent never holds production credentials. The point of these tools was speed, and you don't have to give it up. You can keep prompting in Lovable and let Git sync carry the changes into the repository, where CI and review take over. What changes is the rule for production:
- Every change to production goes through a pull request and CI, whoever or whatever wrote it.
- The agent works against a development database and development keys. It never holds production credentials.
- Database schema and policy changes are migrations in the repo, reviewed like code, not edits in a dashboard.
- Someone on the team reads every RLS policy change before it ships.
That's the same discipline any small team needs. The DevOps for startups guide covers what to automate first.
Sources: as in sections 02, 03 and 05.
Short answers on deploying and securing vibe-coded apps.
How do I deploy or publish a Lovable app?
Publishing to a lovable.app address is free on every plan, and a custom domain needs a paid plan. To host it yourself, use Git sync to get the code into your own repository, then build with npm run build on Node 22. Older React + Vite apps produce a static dist/ folder for a CDN; new TanStack Start apps need a Node server or container.
How do I export a Lovable project to GitHub?
Use Git sync, which works on any Lovable plan. It creates a new repository in your GitHub, GitLab or Bitbucket organisation and syncs both ways on one branch; it can't attach to a repository that already exists. Paid plans can also download a ZIP. The database is a separate export, and it leaves out stored files, Edge Function code and secrets, so plan to move those yourself.
How much does Lovable app hosting cost?
Lovable Pro is $25 a month for 100 credits. Hosting and the built-in backend draw first from a 20-credit monthly Cloud grant, roughly $5 at the Pro rate, then from your credit balance. Lovable doesn't publish per-unit hosting rates; the project usage page shows what each app uses. Lovable calls the grants temporary, so check the plans page before you budget.
Does Lovable use Supabase?
Yes. Lovable Cloud uses Supabase's open-source foundation and gives you the database, login, file storage and edge functions without a Supabase account of your own. You can connect your own Supabase project instead. Moving an existing project from Lovable Cloud to your own Supabase is a manual export and restore, not one step.
Where does the Supabase service role key go in a Lovable app?
Never in the frontend. Supabase's docs say a secret or service-role key bypasses row-level security and must not be in a browser, a shipped app or source control. Keep it in a server-side secret and use it only from an edge function or server route that checks the user first. If it was ever in a VITE_ variable, a commit or the chat, rotate it.
How much does a Replit app deployment cost?
A Reserved VM starts at $15 a month for a shared 0.5 vCPU and 2 GB; Autoscale is $0.60 per million compute units plus $0.40 per million requests and a small base fee. A production database adds $0.16 per hour it's active and $0.35 per GiB a month, on top of your Core ($20) or Pro ($100) plan.
How do I deploy a Bolt.new app, or move it to Netlify?
Click Publish for free hosting on bolt.host, with a custom domain on paid plans. To use your own Netlify account, choose Netlify under Domains & Hosting before the first publish; after publishing to Bolt hosting you'd need a fresh copy. To leave entirely, connect GitHub or download the code and export your table data.
Is the Supabase anon key safe in my frontend?
Yes, if row-level security is on for every table and the policies are right. Supabase designed the publishable (anon) key to be public: it only reaches what RLS allows. The service-role or secret key is the one that must never be in the browser, and a table with RLS off is open to anyone holding the public key.
Is Lovable secure enough for a production app?
The platform gives you tools: a Quick scan on every publish and a Deep scan you start by hand. Lovable's docs also say you are responsible for your app's security and that the tools cannot guarantee it. The researchers behind the 2025 exposures traced them to missing RLS. Run the 14 checks on this page before real users, and get a professional review for payments or sensitive data.
Are vibe-coded apps secure?
They can be. Most public incidents so far came from configuration: RLS off or too permissive, secret keys in the frontend, client-writable payment fields. A few were bugs in the platform itself. Run the 14-point checklist on this page, and get a second pair of eyes before you handle payments or health data. Lovable's own docs recommend a professional review for apps with sensitive data.
Do I have to rewrite the app to move it to AWS?
Usually not. The frontend and server code move as they are, in a container or on a CDN. What gets rewritten is anything tied to the builder: its managed OAuth, connectors and AI gateway, and, if you leave Supabase, the auth and storage calls. Expect signed-in users to sign in again after the cutover.
Supabase to AWS
Moving the database, auth and storage to RDS and ECS, with a planned cutover.
The production readiness checklist
Forty-six checks for when the app is on AWS.
How much AWS costs a startup
Three illustrative monthly bills, line by line.
A disaster recovery plan on AWS
Backups, restore tests and what to write down before the bad day.
Vercel to AWS
The bill at which moving a frontend off Vercel pays.
If you'd rather have someone else check it.
You may not need us. If the app is a prototype or an internal tool, the checklist above and a free afternoon are enough. If it has paying customers, personal data or an enterprise prospect asking questions, our fixed-price readiness review reads your Supabase policies, keys, backups and deploy path, plus the AWS side if you have one, and hands back a ranked fix list with the effort next to each item. It's read-only, so nothing changes until you decide. If you then want the move done for you, the quote comes out of the review.