Lovable/Bolt/Replit Export to Real Production: Domains, Databases, and Secrets

Tools like Lovable, Bolt, and Replit are genuinely good at getting you from an idea to a working preview. 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 an honest map of where the DIY path ends.

First, understand what the export actually 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. That is the good news: 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.

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_...

There is an important distinction here that trips up founders: keys that must stay secret go in the backend. Values the browser genuinely 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), 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 honestly ends

Everything above is doable in an afternoon if the export is clean and you are comfortable copying values between dashboards. Being honest about where it stops being a copy-paste exercise:

• 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 quietly.
• 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" 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 — not to grind for six hours, but to get a second set of hands.

None of this means your exported app isn't ready to be a real product. It means the last mile is infrastructure, not 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 exactly the kind of hand-off we do. Either way, you now know what the steps are and what "done" looks like.