HOSTING
How to host your Lovable app outside Lovable
You can host the generated application outside Lovable. Choose the host based on the project’s actual framework and runtime needs. Exporting the code, moving the frontend, and replacing backend services are separate steps; you do not need to do all of them at once.
Want help with your move? Tell us what you need ↗
Choose how much you want to move
Self-hosting here means running your generated application elsewhere. It does not mean installing the Lovable editor on your server. Start with the requirement that is driving the change: your own deployment pipeline, a different host, or direct backend management.
| Option | What changes | What to establish |
|---|---|---|
| Frontend only | The application is deployed to another host. | Which backend and runtime services it continues to call. |
| Backend only | Records and services move to your own project. | How the app will connect to the destination. |
| Complete move | Hosting and remaining runtime dependencies are replaced. | Who will operate every component after the switch. |
Identify the framework from the repository
Open package.json and the build configuration. Lovable’s current guide distinguishes TanStack Start projects, which include @tanstack/react-start, from older React/Vite projects. Use the actual files rather than a creation date to choose instructions.
A server application needs a compatible server runtime. Uploading only its static assets will not run server functions or server-side rendering. A static application can use a static host, but still needs its backend connections and routing configured.
| Build type | Host requirement |
|---|---|
| Static application output | Static file hosting with routing appropriate to the app. |
| TanStack Start or other server output | A supported deployment adapter and a host that runs the server. |
| Unclear or customized project | Inspect scripts, dependencies, and server code before choosing. |
Prepare a repeatable deployment
Keep the source and dependency lockfile in a repository you control. Document the install and build commands, output, runtime version, and configuration names. Make the first deployment a separate test environment so it cannot interrupt the current site.
Record which settings are embedded during the build and which are read by a running server. Changing a runtime setting cannot repair a value already compiled into browser code; rebuild when necessary. Never solve a missing server secret by placing it in a public frontend variable.
A deployment should be repeatable by someone other than the person who first configured it. Keep a record of the known working revision and the steps to restore it.
Know what you will operate
Plan for deployment failures, domain configuration, logs, availability checks, and ongoing dependency updates. Assign responsibility for each part. A managed destination can reduce server administration, but the application’s configuration and behavior still need an owner.
Avoid choosing a self-managed database simply because the frontend can be exported. Compare the operational work with your actual requirement. A managed Supabase project may address a need for direct account control without introducing database-server maintenance.
Check before switching the domain
A homepage loading at a temporary URL is only the first check. Exercise the application as a user would and include the paths that leave the site and return, such as sign-in redirects or payment callbacks.
- Open a deep link directly and refresh it.
- Sign in, sign out, and test account recovery.
- Read and change representative test records with the correct permissions.
- Upload and retrieve files, including private files.
- Verify backend calls, server functions, and required integrations.
- Check configuration at the final hostname and over HTTPS.
- Keep a tested rollback path and decide how new data will be handled.
Can you continue building in Lovable?
Git sync supports ongoing development between Lovable and the connected repository. Coordinate the active branch and deployment branch so a change reaches the environment you intend. A downloaded ZIP alone does not establish that ongoing workflow.
If multiple people edit the app, agree on how changes are reviewed and reconciled. Verify sync status before assuming your external deployment contains the latest Lovable changes.
Can you cancel your Lovable subscription?
Source ownership and running-service dependencies are separate questions. Before changing a subscription, identify everything the deployed app still needs from Lovable, including its backend and runtime features. Follow the current ownership guidance and billing terms for the services you retain.
A successful local build is not proof that the app is independent. Test the external deployment and review its network calls and integrations before making billing or removal decisions.
Official sources
Product instructions were checked against these documents on 2026-10-15. This is documentation research, not a claim of testing on your app.