Lovable Self Hosting: The App Can Move, the Editor Cannot

A Lovable app leaves Lovable’s servers for a reason with a name attached. A customer’s security review asked where the data sits, a contract fixed the region, or an internal policy says company systems run inside the company network. Lovable’s own external hosting guide names those same three, and adds that most teams never hit any of them.

Lovable self hosting covers two of the three layers of a Lovable app. The frontend build and the backend with its data can both run on infrastructure you operate. The editor and AI agent cannot, and Lovable’s documentation is explicit that the platform stays a managed service outside your network.

The person who needs this usually has a deal waiting. One founder on r/lovable put the requirement plainly: “I’m in discussions with large enterprise, yet they want local servers, SOC2 and ZDR. All of which lovable cannot do.” (one row of 1,255 read on 14 August 2026). ZDR is zero data retention, a contract term saying the AI provider keeps nothing once the request is answered. Lovable publishes its certificate, a route to running the app on your own servers, training statements, opt-out paths and retention periods. It does not publish a ZDR commitment, and its current security, privacy and terms pages do not describe training in the same way.

Everything below is read from Lovable’s published documentation, FAQ and security post, not from a migration run for this page. Self-hosting is one of four ways out of Lovable, and whether to leave at all is a separate question that several common triggers answer with no. This page assumes the requirement is real and external.

The three layers of a Lovable app, and which ones you can host

A Lovable app is three separable things, and a security questionnaire does not distinguish between them. The frontend can be a React and Vite static build or a TanStack Start app with server-side rendering. The backend is a Supabase stack: PostgreSQL plus authentication, storage, realtime and edge functions. The editor is the chat window and the agent that writes the code.

Two of those three can run on infrastructure you operate. The editor cannot, and the vendor documents that directly.

Lovable’s current stack FAQ says new apps created from 13 May 2026 use TanStack Start with server-side rendering, while older apps use React and Vite. Its external hosting guide still gives a Vite-only static recipe. Treat that recipe as one branch, not a universal instruction: confirm the stack in the repository before choosing environment-variable names, build output, or a host.

The sentence that sets the third row is on Lovable’s deployment and ownership page, and it is worth reading exactly as written: the platform “cannot be self-hosted or deployed inside a customer VPC”. The middle row comes from the external hosting guide, which says the self-hosted option “is intended for strict compliance, data residency, or infrastructure control requirements” and that “You run the backend and database on infrastructure you operate”. The same page rules out the shortcut people try first: “Running only a standalone PostgreSQL database is not sufficient unless you implement equivalent authentication, storage, realtime, and edge services.”

If the only thing that has to change is where the files are served, that is a managed-platform job, and deploying a Lovable app to Vercel walks that route instead.

What your enterprise customer is actually asking for

A review that says “we need it self-hosted” is usually four separate asks wearing one phrase. They have different answers, and only one of them is a real problem.

• Data residency. Self-hosting the backend answers this, because you choose the region the database lives in. Lovable names data residency as one of the three reasons its external hosting guide exists, so the vendor and the buyer agree on what the option is for.

• A deployment inside our own network. Self-hosting answers this for the app. Lovable’s ownership page lists containers (Docker), Kubernetes clusters, and virtual machines running Nginx or Apache among the places a Lovable app runs, which covers most of what a network policy means by inside. It does not answer it for the editor, which stays outside.

• A retention or training term on the AI. This is the ask self-hosting does not fix. Lovable’s security page says customer prompts, code and workspace data are not used to train Lovable models and that provider contracts restrict training and retention. Its privacy policy, training-data page and Terms publish opt-out and retention language that does not fully align with that statement. None of those pages promises zero data retention. Ask the Trust Center for the plan-specific term in writing, and ask the same question of whichever coding tool takes over after the move.

• A compliance report. Usually satisfied already. Lovable’s security post says “As of August 13, 2025, Lovable is officially SOC 2 Type 2 compliant. We’re also SOC 2 Type 1 compliant and ISO 27001:2022 certified”, and its ownership page describes “compliance-ready infrastructure (SOC 2 Type 2 and ISO 27001 certified)”. Those cover Lovable’s systems rather than your app, and what Lovable’s SOC 2 and ISO 27001 actually cover works through the difference.

Go back to the customer and ask which of the four is the blocker before you price anything. Three have cheap answers and one has none, and the phrase in the email rarely tells you which they meant.

What running a Lovable app yourself actually hands you

Lovable is blunt about the trade on its external hosting guide: “Lovable does not monitor, operate, or debug any part of self-hosted infrastructure, and production previews are not generated for self-hosted production environments.” The same page names eight duties that become yours, and seven of the eight are these: PostgreSQL operations, backups and disaster recovery; authentication, storage and realtime availability; row-level security design and enforcement; security patches and version upgrades; performance tuning and scaling; monitoring, alerting and incident response; and compliance certification of your infrastructure.

Those duties arrive with a monthly bill, and it comes as a list of line items:

• Compute or a CDN for the frontend. Static files plus egress, cheap until the traffic is real.

• Compute for the Supabase stack. Size it for PostgreSQL, auth, storage, realtime and edge functions together, because that is several services and not one process.

• PostgreSQL storage and backups, managed or self-run. Backups are the line people leave off the estimate, and they decide whether the residency requirement bought you anything.

• Egress. Most providers bill every gigabyte your storage bucket serves, and an app with user uploads notices.

• TLS certificates and the DNS that points at them. Small money, and someone owns the renewal.

• Log and metric retention. Monitoring and alerting are yours now, and neither exists until somebody pays to keep the data.

• Recurring human time. Patching, upgrades, incident response, and compliance certification of your own infrastructure.

No monthly figure appears here because there is no honest one to give. Price the list against your provider’s published rates and compare it against one Lovable subscription. What the move itself costs as a one-off is a different question.

Lovable will write the container files for you, in three shapes: frontend only, backend only, and full stack. Two limits are documented on the same page. The agent “cannot run or test Docker builds. You must verify locally.” And it “cannot generate real secrets. Placeholders require manual replacement.” So a person generates the JWT secret with openssl rand -base64 32 and replaces JWT_SECRET, POSTGRES_PASSWORD, ANON_KEY and SERVICE_ROLE_KEY in the docker-compose file before anything starts.

Expect the destination to hold exactly what you already had. An agency in the same mining corpus went into a Lovable build planning to run the result in Kubernetes with per-customer configuration, and found after the export that the code was there and the configuration model was not. Self-hosting relocates an app. It does not give the app an architecture it never had, and the wider version of that surprise, what comes out of a builder and what quietly does not, is worth settling before the cutover.

One late trap applies to the React and Vite branch. Values prefixed with VITE_ are embedded at build time rather than runtime, so pointing that app at your new backend means a fresh build and not a settings change. Why a VITE_ value is baked into the build covers the exposure that comes with it. A TanStack Start project needs the variables and build process declared by that repository, not a copied Vite list.

Where a self-hosted Lovable app can run

Lovable publishes the destination list, and it is deliberately boring: containers (Docker), Kubernetes clusters, and virtual machines running Nginx or Apache, on AWS, GCP or Azure. The AWS row goes one level further and names a service for each of those shapes. For a confirmed React and Vite project, the current external-hosting recipe is npm run build, output in dist/, with Node 22 recommended. For a TanStack Start project, keep the server-side rendering runtime and follow the repository’s own scripts; do not assume a static dist/ upload is the deployment.

Moving a Lovable app to a standalone server is the same job with the managed pieces swapped for things you install, and anyone who wants to self host a Lovable project on one box can run both layers there under Docker.

That is the easy quarter of the work, and the whole of what an AWS how-to gives you. For a confirmed Vite build, putting the built frontend on S3 behind CloudFront is an afternoon. A TanStack Start build needs a server-capable destination instead. The backend is the other three quarters: schema, policies, data rows, storage objects, every secret value, and every user account, none of which travel by copying files. What comes across from Lovable Cloud and what you rebuild by hand owns that procedure end to end, and getting the database out owns the export file itself. If your reason for self-hosting is who operates the backend, what you own once you run the backend yourself compares running it yourself against the managed options. What is actually inside the repository Lovable syncs to GitHub is a question for the code export.

Who changes the code once the Lovable app is yours

A post on r/lovable on 11 August 2026 states the plan most self-hosters actually have: “I was thinking of moving to self-hosting and continuing to use Codex/Claude. My site has a lot of backend and connectors, how can I move everything safely?”

That plan is correct, and the third row of the table is why it is necessary. The editor stays a managed service that cannot come inside your network, so once the app lives on your infrastructure, something else has to change the code. Codex and Claude Code are tools you drive from a terminal against a repository you own, and Cursor is an editor with the same model access built into it. All three assume you can read a failing build, which is the part nobody mentions to a founder who has never needed to. Whoever owns that afterwards, you or someone you pay, is a decision to make before the cutover.

The app you now operate is the app you already had. Monitoring, alerting and incident response join your duty list at the cutover, and in the corpus behind this blog most apps had nothing to monitor with. AxonBuild ran 26 production-readiness audits in June and July 2026. Reliability scored 31 out of 100 on the 21 apps built by third parties, the lowest of the twelve pillars. Errors that users hit went unrecorded anywhere in 17 of those 21, and at least 23 of the 26 carried zero working automated tests. Taking on the pager for an app in that condition is the part of self-hosting nobody prices.

Common questions about self-hosting a Lovable app

Can you self-host Lovable?

Lovable itself cannot be self-hosted. Its documentation says the editor and AI agent are a managed service that cannot be deployed inside a customer VPC. What you can self-host is the app Lovable built for you: the frontend build and the Supabase backend behind it, which is two of the three layers.

Can I move my Lovable app to AWS?

Moving a Lovable app to AWS is documented by the vendor. Its ownership page names S3 with CloudFront for static hosting, ECS for containers, EKS for managed Kubernetes, and Amplify for application hosting, alongside GCP and Azure. Use the static option only for a confirmed React and Vite build; a TanStack Start app needs a destination that runs its server-side rendering build. The frontend is the quick part, and the backend is most of the work.

Which AWS service you pick matters far less than who owns the database operations, the backups and the recovery drill afterwards.

Can I use self-hosted Supabase with a Lovable app?

Self-hosted Supabase is the route Lovable documents. Its guide points there because self-hosted Supabase provides the authentication, storage, realtime and edge function services a Lovable app depends on, and the same page warns that a standalone PostgreSQL database is not sufficient unless you implement equivalents yourself. Your project’s SQL migration files carry the schema across.

How do I move a Lovable app to my own server?

Moving a Lovable app to your own server takes three passes, and the data and the user accounts are the slow one.

1. 01 Get the code into a repository you control.
2. 02 Stand up a Supabase stack on that server, with the secrets generated by hand rather than copied across.
3. 03 Rebuild the frontend against the new backend, then cut traffic over.

Does self-hosting stop Lovable from seeing my code?

Self-hosting changes where the app runs, not who reads the code while it is being written. Keep prompting in Lovable after the move and the editor still receives your code, because that layer never moved. Lovable publishes training, opt-out and retention statements, but the current pages do not fully align and none promises zero data retention. Get the plan-specific term in writing if that is the requirement.

Is Lovable SOC 2 compliant enough for an enterprise customer?

Lovable holds the certificates. Its security post says the company has been SOC 2 Type 2 compliant as of August 13, 2025, and is also SOC 2 Type 1 compliant and ISO 27001:2022 certified. Those describe Lovable’s own systems and not your app, so a vendor review will still ask about your access controls and your incident process.

What does self-hosting a Lovable app cost to run each month?

A self-hosted Lovable app has no single honest monthly figure, because the bill arrives as a list: frontend compute or CDN, compute for the Supabase services, PostgreSQL storage and backups, egress, certificates, log and metric retention, and human time for patching, upgrades and incident response. Price that list against your own provider.