From preview to production: domain, env vars and backups

In the Lovable, Bolt or Replit preview, everything looks great. Sending that link to real customers is a different story. You need your own domain, test data that doesn't mix with real data, backups, and some way to find out if the app goes down at 3 a.m.

This guide walks through that step, from "works on my screen" to "works for everyone", without assuming you're a developer.

1. Decide where your app will live

Many vibe-coding tools have their own publish button, and that can be enough to start. If you want more control, or your project already lives on GitHub, the usual options are:

• Vercel: popular for Next.js and React projects. Every push to GitHub creates a new deployment.
• Netlify: similar, and very convenient for sites and single-page apps (React with Vite).
• Render: useful when you also need an always-on server, scheduled jobs or your own backend.
• Cloudflare Pages: another solid choice for static sites and frontend apps.

For most AI-generated apps (a React frontend with Supabase or Firebase behind it), any of these works well. What matters is that deployments come from your repository, so you always know which version is live.

A classic gotcha: with a single-page app, opening a route like /dashboard directly, or refreshing on it, returns a 404. The fix is a rule that sends every route to index.html. On Netlify that's a _redirects file containing /* /index.html 200; on Vercel it's a rewrites rule in vercel.json.

2. Connect your custom domain

1. Buy the domain from a registrar (or use one you already own).
2. In your hosting dashboard, add the domain to the project. It will show you exactly which DNS records to create.
3. In your domain's DNS settings, create those records exactly as shown. Typically that's an A or ALIAS record for the root domain (yourapp.com) and a CNAME for www.
4. Wait for propagation. It's usually minutes, though it can take hours.
5. Confirm the HTTPS certificate was issued (the padlock in the browser). Vercel, Netlify and Render handle this automatically once DNS is right.

Pick one main address (yourapp.com or www.yourapp.com) and redirect the other one to it.

If you use email on that domain, be careful not to delete the MX or email-related TXT records while you're editing DNS.

3. Environment variables, per environment

Environment variables hold the settings that change depending on where the app runs: your Supabase project URL, public keys, the site URL, and so on.

• Keep testing and production apart. Ideally you have one database project for testing and another for production, so an experiment can't wipe real data.
• Set them in your hosting dashboard. Vercel, for example, lets you set different values for Production, Preview and Development.
• Redeploy after changing them. In Vite and Next.js apps, public variables are baked in at build time. Changing a value in the dashboard won't affect what's live until you trigger a new deployment.
• Nothing secret in public variables. Anything prefixed VITE_ or NEXT_PUBLIC_ reaches the browser. Secret keys belong on the server only.

And the classic domain-switch bug: login stops working or redirects to localhost. In Supabase, update the Site URL and add your domain under Redirect URLs in the Auth settings. If you offer Google or another sign-in provider, check the authorized URLs there as well.

4. Database backups

Your code is on GitHub. Your data isn't. Before you have real users:

1. Check which automatic backups your plan includes and how many days they're kept.
2. Schedule your own periodic copy (for example with supabase db dump or pg_dump) and keep it outside the provider.
3. Back up user-uploaded files too: with many services, Storage isn't part of the database backup.
4. Test a full restore into a separate project, so you know how long it takes and that it actually works.
5. Before any big database change (especially one the AI is making), take a manual backup first.

5. Monitoring and alerts

You shouldn't learn that your app is down from an annoyed customer.

• Uptime monitoring: services like UptimeRobot or Better Stack check your site every few minutes and alert you by email or message when it stops responding.
• Error tracking: tools like Sentry capture the errors your users hit in the browser, with the technical detail you need to fix them.
• Usage and spending alerts: turn on notifications in your database, hosting and AI providers so you hear about limits before you hit them.

6. Emails that actually arrive

If your app sends confirmation or password-reset emails, make sure they land in the inbox and not in spam. Supabase's built-in email service has low limits and is meant for testing; for production the recommendation is to set up your own SMTP (through a transactional email provider) and authenticate your domain with SPF, DKIM and DMARC.

7. Before you share the link

Run through this list in a private/incognito window:

1. The app loads on your domain over HTTPS, and www redirects correctly.
2. Refreshing any inner page doesn't return a 404.
3. You can sign up with a brand-new email, confirm it and log in.
4. Password reset works and the link points to your domain.
5. It looks right on a phone.
6. No test data or placeholder text is visible.
7. Page title, favicon and the social share preview are set.
8. You have a recent backup and uptime monitoring is on.
9. You've gone through the security checklist before launch.

Want help getting to production?

Domains, DNS, environment variables and backups are exactly where many AI-built apps get stuck. At Devonauts we walk through it with you: we get your app live, backed up and monitored, and we explain each piece so you can keep building. See how our AI app rescue works or tell us where you are.