Lovable Export to Real Production: Domains, Databases, and Secrets

Tools like Lovable, Bolt, and Replit are good at getting you from an idea to a working preview. (This guide follows a Lovable app; the builder-specific hosting decisions for the other two are in our Bolt.new hosting guide and our Replit Deployments guide.) The wall people hit is the next step: taking that preview and turning it into a real product on your own domain, with a database that keeps data and secrets that aren't sitting in the browser. This is a practical, non-technical walk-through of how to deploy a Lovable app with a custom domain and database, and a map of where the DIY path ends.

First, understand what the export is

When you export from one of these tools you usually get a normal code repository, most often a React or Next.js frontend, sometimes with a small backend and a schema. Nothing about it is magic or locked in, so it deploys like any other web app. The catch is that the builder was running three things for you invisibly (hosting, a database, and secret storage), and the export hands all three back to you.

Lovable hosting: where your app runs today, and the three ways to host it

Before you export anything, it helps to know what Lovable is already doing for you. (Facts in this section were read from docs.lovable.dev and lovable.dev/pricing on 2026-09-24; check them before you rely on a number.)

• Lovable hosts the frontend. When you click Publish, the app goes live on Lovable's infrastructure at your-project.lovable.app. Publishing is free, and a published site stays up indefinitely; there is no expiry for inactivity. Hosting and the built-in backend consume "Run credits" as the app is used. Lovable's pricing page says that for most small or new apps this costs nothing, and that heavy traffic draws down your credit balance.
• A custom domain needs a paid plan. You point an A record at Lovable's IP (185.158.133.1), add a _lovable TXT record to prove ownership, and Lovable issues the SSL certificate itself, typically within 72 hours. You can also buy the domain inside Lovable; it is billed separately from the subscription.
• The backend is either Lovable Cloud or your own Supabase. Lovable Cloud (database, auth, storage, functions) is on by default. Connecting your own Supabase project gives you the account and the bill. The docs are explicit that there is no automatic migration between the two in either direction: you export the data and recreate the schema by hand.
• The code lives in GitHub. With the GitHub connection on, Lovable creates a repository and keeps it in two-way sync on one branch, and the docs state you can "deploy outside Lovable." Do not delete, rename or transfer that repo, because that breaks the sync.

So "how do I host a Lovable app" has three answers, and only one of them is a project:

If you are in the first column, stop here and enjoy it. The rest of this guide is the second and third columns, step by step. (If your app is in Replit rather than Lovable, the same decision is written up in our Replit Deployments cost-and-limits guide.)

Step 1: Get the code into your own repository

Push the export to a GitHub repository you own. This is the source of truth every host will deploy from, and it is where you will (carefully) manage configuration.

cd my-exported-app
git init
git add .
git commit -m "Initial import from builder export"
git remote add origin git@github.com:you/my-app.git
git push -u origin main

Before you push, open the project and search for anything that looks like a key. Builders sometimes bake API keys into the frontend. If you find one, plan to rotate it. A key shipped in frontend code is visible to anyone who opens the browser dev tools.

Step 2: Give it a real database

The preview database inside the builder is not something you can point production at. Create a managed Postgres (Neon, Supabase, and Railway all give you one in a couple of clicks) and copy its connection string. It looks like this:

postgresql://user:password@ep-cool-name.us-east-2.aws.neon.tech/appdb?sslmode=require

You will set that as the DATABASE_URL environment variable (next step), and you will need to create your tables in it by running the project's migrations. If the export includes a prisma/ or drizzle/ folder, that is what those are for:

npx prisma migrate deploy   # creates the tables in your new database

If there are no migrations, the schema only existed inside the builder. Recreating it correctly is one of the fiddly bits, and a common place people ask for help.

Step 3: Move secrets into environment variables

Anything sensitive (your database URL, third-party API keys, auth secrets) goes into your host's environment settings, not the code. Every platform has an "Environment" or "Secrets" tab. The rule of thumb: if it would be bad for a stranger to see it, it is an environment variable.

DATABASE_URL=postgresql://...
JWT_SECRET=<a long random string>
STRIPE_SECRET_KEY=sk_live_...

One distinction trips up founders: keys that must stay secret go in the backend. Values the browser needs (like a public Stripe key or a map token) are "publishable" keys and are safe in the frontend. If you are not sure which a key is, treat it as secret until you have confirmed otherwise.

Step 4: Deploy the app to a host

Connect your GitHub repo to an application host (Vercel and Netlify for frontends; Railway or Render when you also have a backend process; how those hosts differ is covered in our comparison of Heroku alternatives), set the environment variables from Step 3, and deploy. You will get a URL like my-app.vercel.app. Confirm the whole flow works on that URL (sign up, save something, reload) before you touch DNS. If it works here, the domain step is easy. If it doesn't, the domain won't fix it.

Step 5: Point your custom domain at it

Buy the domain (or use one you own), then add two kinds of DNS records at your registrar. For a subdomain like app.yourdomain.com you use a CNAME; for the bare yourdomain.com you use an A or ALIAS record, because the apex can't be a CNAME:

Type   Name   Value
CNAME  app    cname.vercel-dns.com.
ALIAS  @      76.76.21.21         # example apex target from your host

Add the domain in your host's dashboard so it knows to answer for it and provision a TLS certificate. Then wait. DNS changes can take anywhere from a few minutes to an hour. Check progress with:

dig app.yourdomain.com +short

When that returns your host's value and the padlock appears in the browser, you are live on your own domain with HTTPS.

Where DIY ends

Everything above is doable in an afternoon if the export is clean and you are comfortable copying values between dashboards. It stops being a copy-paste exercise at these points:

• No migrations in the export. Rebuilding a schema by hand, with the right columns, types, and relationships, is real work, and getting it wrong corrupts data without any error to warn you.
• A backend that needs a long-running process, background jobs, or file storage. That is more than static hosting and is where "the backend was never actually hosted"quot;the backend was never hosted"the backend was never actually hosted"quot; bugs come from.
• Auth, payments, and email that need webhooks and correct redirect URLs. Each has a production configuration the preview hid from you.
• Anything you can't debug. If a step fails with an error you don't understand, that is the signal to get a second set of hands rather than grind for six hours.

Your exported app can still become a real product. The last mile is infrastructure rather than app-building, and those are different skills. If you would rather stay focused on the product and have someone take the export straight to a live domain with a real database, that is the kind of hand-off we do. Think of it as DevOps as a service without a retainer, scoped to one export rather than an ongoing engagement.