How to Put Your Lovable, Bolt or Cursor App on Your Own Domain and Hosting

Disclosure: some links on this page are affiliate links. If you buy through them we may earn a commission at no extra cost to you.

You built an app with an AI tool. It works. You share the link, and it looks like myproject.lovable.app. That address belongs to the platform, not to you.

Here is the short answer. To put your app on your own domain and hosting, you need five things: a domain name you own, your code in a GitHub repository, a host that matches how your app is built, DNS records that point the domain to that host, and an SSL certificate. For most apps made with Lovable, Bolt, Cursor or Claude, the whole job takes an afternoon.

This guide walks you through each step in plain language. No coding background needed.

Why a platform address is not enough

A platform address like yourapp.lovable.app or a similar preview link is a rental. It works as long as the platform, your plan and your project all stay in place.

Three things can go wrong:

• Your subscription ends. Some features, or the whole project, may stop being available on a paused or cancelled plan. Check the platform’s current terms for details.
• The platform changes. Tools in this space change fast. Features move between plans, domains get reconfigured, products get renamed or shut down.
• Customers do not trust it. A link on someone else’s subdomain looks like a test project. A link on yourbrand.com looks like a business.

There is also a practical problem. Your email, your search ranking and your social profiles all attach to the web address you use. If that address changes later, you lose all of it. Picking your own domain on day one avoids that.

So the goal is simple: own the name, own the code, own the hosting. Then any AI tool becomes just a way to write the code, not a place you depend on.

The quick option: a Lovable custom domain or a Bolt custom domain

Before moving anything, know that there is a shortcut. Lovable lets you connect a custom domain to a published project. Bolt does the same through its publishing options, and it has connected to hosts like Netlify for deployment. Menu names and plan requirements change, so open the platform’s own help pages and check what your current plan allows.

This route is the fastest way to get yourbrand.com showing your app. You buy the domain, add the DNS records the platform gives you, and wait for it to verify.

It has one weakness. Your app still lives on the platform’s servers. If you stop paying or the product changes, the domain points to nothing.

If that risk is acceptable for a first version, use the shortcut. If you want real ownership, follow the full steps below. They also work as a second phase: start with the shortcut, then move later.

Step 1: Buy a domain name you control

A domain is the name people type, like yourbrand.com. You rent it from a registrar, usually per year.

Tips that save trouble later:

1. Buy it in your own account. Not through an agency, a freelancer or a platform reseller. The account that holds the domain controls it.
2. Choose .com if you can. Other endings work, but .com is what most people try first. Keep the name short, easy to say aloud and free of hyphens.
3. Turn on auto-renew. An expired domain is a common way people lose a working site.
4. Turn on domain lock and two-step login. Both are standard options at registrars.
5. Check the renewal price. Many registrars show a low first-year price and a higher renewal price. Check the current price on the provider’s page before you pay.

Good places to buy include Namecheap, Cloudflare Registrar, Porkbun and GoDaddy. If you want one simple option, Domain.com sells domains with a straightforward dashboard for managing DNS records. Hosting companies such as Hostinger and Bluehost also sell domains, and buying both in one place can be convenient. Keeping them separate gives you more freedom to move later. Either choice is fine.

Step 2: Export your app from Lovable (or Bolt, Cursor, Claude) to GitHub

Your code needs a safe home that is not the AI tool. GitHub is the standard choice, and a free account is enough to start.

Lovable. Lovable can connect to a GitHub account and sync your project to a repository. This is the usual way to export an app from Lovable. Look for the GitHub option in the project settings, authorise it, and create the repository. After that, changes you make in Lovable are pushed to GitHub.

Bolt. Bolt projects can be downloaded as a file, and the platform also offers ways to connect a repository. Check its current options in the app.

Cursor and Claude. These tools write code on your own computer, so your project is already a folder of files. Create a GitHub repository and push the folder to it. If you have never used Git, GitHub Desktop is a friendly app for this. You can also ask the AI to give you the exact commands.

Once the code is on GitHub, check three things:

• The repository contains the real project files, including a package.json file for most web apps.
• There is no secret key in the code. Passwords, API keys and tokens should never sit in the repository. Look for files named .env and make sure they are not committed.
• You can see the commit history. That is your backup.

Make the repository private if the app is a business project. You can still deploy from a private repository.

Step 3: Find out what kind of app you built

This step explains why so many people get stuck. The right hosting depends on what your app is made of, and AI tools do not always tell you.

There are two main types.

A static front end. The app is built into plain files (HTML, CSS, JavaScript) that run in the visitor’s browser. Many apps from Lovable and Bolt are built this way, usually with React and a build tool, and they talk to a separate database service for data. These are easy to host anywhere.

An app with a server. Some code must run on a server, not in the browser. A Next.js project with server-side features, API routes or a Node.js backend is in this group. These need a host that can run Node.js.

How to tell the difference:

• Open package.json and look at the scripts section. If you see "build" and the project uses Vite or a similar tool, it is probably a static front end.
• If you see next listed as a dependency, it is a Next.js app. Some Next.js apps can be exported as static files, others need a server.
• If there is a server folder, an api folder or Express listed, you have a backend.

When in doubt, paste your package.json into an AI assistant and ask: “Is this a static site or does it need a Node.js server? What command builds it?” You will get a useful answer in seconds.

Step 4: Pick hosting that matches your app

Here is the part where the choice matters. Use this table as a starting point.

Your situation	Good fit	Notes
Static front end, small project, want one bill for domain and site	Shared hosting such as Hostinger or Bluehost	Upload the build folder. Simple, but you do the upload yourself.
Static front end, want automatic deploys from GitHub	Vercel, Netlify or Cloudflare Pages	Connect the repository and each push updates the site.
Next.js app with server features	Vercel, or a host with Node.js support	Check that your plan runs Node.js apps.
Node.js or Express backend plus front end	Render, Railway, Fly.io, or a VPS	Needs a server process that stays running.
WordPress site next to your app	Managed WordPress hosting	See our Kinsta vs Bluehost comparison.
You want full control and can follow server guides	A VPS from a provider such as Hostinger, DigitalOcean or Hetzner	More power, more responsibility.

A few honest points about shared hosting. A basic shared plan is built around PHP and WordPress. It does not run a Node.js app by default. That is why people say “my app works locally but not deployed” after uploading the wrong files to the wrong kind of plan. If your app is a static build, shared hosting works well. If it needs Node.js, check that the specific plan supports it, or choose a different type of host.

If you want a low-cost home for a static app plus a domain and email under one roof, Hostinger is a common pick for beginners, and its control panel is easy to follow. Bluehost is another long-standing option, especially if WordPress is also part of your plan. Plans and features differ, so read the plan page and check the current price on the provider’s page before you commit.

If you want a deploy from GitHub with no manual uploads, a platform like Vercel or Netlify is usually the easier path for front-end apps. Both have free tiers at the time of writing, but limits change, so check their pages.

Step 5: Plan your database and your secrets

Many AI-built apps store data in a separate service. Lovable projects commonly use Supabase, and Bolt projects often do too. Your data does not live on your web host. It lives in that service.

That is good news. Moving your front end does not move your data. But there are things to handle:

• Environment variables. Your app reads settings like the database address and API keys from variables, not from the code. When you deploy, you must add these variables again in your new host’s dashboard. Forgetting this is a common cause of a blank page after deployment.
• Public keys versus secret keys. A database service usually gives you a public key, safe for the browser, and a secret key that must stay on a server. Never put the secret key in front-end code.
• Allowed URLs. Login systems often need a list of approved addresses. Add https://yourbrand.com to that list, or sign-in will fail on your new domain.
• Backups. Check how your database service handles backups on your plan. Do not assume it does.

Keep a simple note listing every service your app uses and which account owns it. Put those accounts under your own email, not a freelancer’s.

Step 6: Deploy the site and connect the domain (DNS)

Now you connect the pieces.

Deploy first. The method depends on the host:

• Vercel, Netlify, Cloudflare Pages: choose “import from GitHub”, pick the repository, confirm the build command and output folder, add your environment variables, and deploy. You get a temporary address on the host’s own domain. Test the app there.
• Shared hosting with a static app: run the build command on your computer (often npm run build), then upload the contents of the output folder (often dist or build) to the site’s public folder through the file manager. Add a rule so page refreshes on sub-pages do not show a “not found” error. Single-page apps usually need this, and your host’s help pages explain how.
• Node.js hosting or a VPS: follow the host’s guide to run a Node app. This is where you may want help from the AI or a developer.

Then connect the domain. DNS is the address book of the internet. You tell it that yourbrand.com points to your host. Your host will give you one of two things:

1. Nameservers. You copy two or more nameserver addresses into your registrar’s settings. The host then manages all DNS records.
2. Records. You add specific records at your registrar. The most common are an A record (points the bare domain to an IP address) and a CNAME record (points www to a host name).

Follow your host’s exact values. Do not guess them.

Changes can take from a few minutes to a day to spread. If the site does not load right away, wait before changing anything. Changing records repeatedly makes it harder to know what is going on.

Also decide whether www.yourbrand.com or yourbrand.com is your main address, and redirect the other to it. Two live versions of the same site confuse search engines.

Step 7: Turn on SSL (the padlock)

SSL (HTTPS) encrypts traffic between your visitors and your site. Browsers warn people away from sites without it, and login forms must have it.

Most modern hosts issue free certificates automatically once your DNS points to them. Look for an “SSL” or “HTTPS” section in the dashboard and enable it if it is not on already. Certificates usually renew by themselves.

After it is on:

• Open your site with https:// and confirm the padlock appears.
• Make sure http:// redirects to https://.
• Watch for “mixed content” warnings, where the page loads some images or scripts over http://. Replace those links with https://.

Step 8: Set up professional email

A domain without email is half the value. [email protected] builds trust in a way that a free Gmail address does not.

Options:

• Email from your hosting plan. Many hosts include mailboxes, or sell them cheaply. This is the simplest start.
• A dedicated email service. Google Workspace, Microsoft 365 and Zoho Mail are common choices. They cost more but are built for reliable mail.

Whichever you pick, add the MX records the provider gives you at your DNS. Then add the anti-spam records the provider recommends, usually called SPF, DKIM and DMARC. Without them, your messages may land in spam. Send a test message to a Gmail address and a Microsoft address and check both inboxes.

One warning: if you move DNS to a new host, copy the existing MX records first. Overwriting them is a classic way to lose incoming mail.

Step 9: Verify everything before you announce it

Do not trust “it loads on my laptop.” Run this checklist:

• [ ] https://yourbrand.com loads your app with the padlock.
• [ ] www and the bare domain both end on the same address.
• [ ] Open the site on your phone, on mobile data, not your home Wi-Fi.
• [ ] Try the full user path: sign up, log in, submit a form, reset a password.
• [ ] Open a deep link such as yourbrand.com/pricing in a new tab. It must not show an error.
• [ ] Send and receive a message at your new email address.
• [ ] Open your browser’s developer console (right-click, Inspect, Console) and look for red errors.
• [ ] Confirm that you can log in to the registrar, the host, GitHub and the database service with your own email.
• [ ] Set a calendar reminder for domain renewal.

If anything fails, the next section covers the usual causes.

Pitfalls: why an app works locally but not deployed

“App works locally but not deployed” is one of the most common complaints from people building with AI. The causes are boring and fixable.

Missing environment variables. The app runs on your machine because a local .env file exists. The host does not have it. Add each variable in the host’s dashboard.

Wrong build settings. The host needs to know the build command and the output folder. A Vite app builds into dist. Other tools use build or .next. A wrong folder gives a blank page or a 404 error.

Shared hosting without Node.js. You uploaded a project that needs a server to a plan that only serves files. The fix is to export a static build or to move to a host that runs Node.js.

Page refresh gives “not found”. Single-page apps handle routes in the browser. The server must send every route to index.html. Add a rewrite or redirect rule in your host’s settings.

Absolute paths to localhost. The code still calls http://localhost:3000 somewhere. Search the project for “localhost” and replace it with an environment variable.

Case-sensitive file names. Your laptop may ignore the difference between Logo.png and logo.png. Many servers do not. Match the names exactly.

Node version mismatch. The host runs a different Node.js version than your computer. Set the version in the host’s settings or in package.json.

Login fails on the new domain. The authentication service does not know your new address. Add it to the allowed URLs list.

Old DNS cache. You fixed the records but your device still shows the old result. Test from another network, or wait.

Forgotten ownership. The domain sits in a freelancer’s account, or the GitHub repository belongs to a person who left. Transfer both to accounts you control now, not during an emergency.

A good habit: when something breaks, copy the exact error message from the host’s deploy log and give it to your AI assistant with the sentence “I am deploying this app to [host name]. Here is the error.” Specific errors get specific answers.

Which route should you choose?

Keep it simple:

• Just want your name on the app today? Use the Lovable custom domain or Bolt custom domain option, and plan the move later.
• Static app, small budget? Buy a domain, push to GitHub, deploy to a static host or to shared hosting, and set up email. A plan from Hostinger or Bluehost can cover the site, the domain and the mailboxes in one place. Confirm what each plan includes first.
• Next.js or Node.js app? Pick a host that clearly says it runs Node.js, or use a platform built for those frameworks.
• Customers will pay you through the app? Use a host with good uptime records, keep backups, and ask a developer to review the setup once.

You do not have to get it perfect. Your first version can live on a static host with a domain and a simple email address. You can move to something stronger when real users arrive.

FAQ

How do I publish a Lovable app on my own domain?

Connect a custom domain in the project’s publish settings, then add the DNS records Lovable shows you at your registrar. For full ownership, sync the project to GitHub and deploy it on your own host, then point your domain there. Check Lovable’s help pages for current steps and plan requirements.

Can I export my app from Lovable and leave the platform?

Yes, in general. Lovable can sync a project to GitHub, which gives you the code. You then build and deploy it elsewhere. Your database may sit in a separate service, such as Supabase, so also check who owns that account and how to keep it connected after the move.

Can I host a Next.js app on shared hosting?

Usually not by default. Shared hosting built for PHP does not run a Node.js server. If your Next.js app can be exported as static files, it can work. If it needs server features, choose a host that supports Node.js, such as Vercel or a VPS, or confirm your plan supports Node.js apps.

Do I need a developer to move my AI-built app to my own hosting?

Not always. A static app is often something a careful beginner can deploy by following the host’s guide. You may want a developer for apps with a backend, payments, user data or complex login. A one-time review is cheaper than fixing a broken launch.

What happens to my app if I cancel my Lovable or Bolt plan?

It depends on the platform’s terms and your plan, so read them before you cancel. The safe approach is to keep your code in GitHub, your domain at your own registrar and your hosting under your own account. Then a cancelled plan does not take your site offline.

Do I need professional email on my own domain?

You do not need it to launch, but you should set it up soon. Emails from your own domain look more trustworthy, and customers are more likely to reply to them. Your host may include mailboxes, or you can use a dedicated email service. Add the SPF, DKIM and DMARC records so your messages reach the inbox.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do I publish a Lovable app on my own domain?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Connect a custom domain in the project’s publish settings, then add the DNS records Lovable shows you at your registrar. For full ownership, sync the project to GitHub and deploy it on your own host, then point your domain there. Check Lovable’s help pages for current steps and plan requirements.”
}
},
{
“@type”: “Question”,
“name”: “Can I export my app from Lovable and leave the platform?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Yes, in general. Lovable can sync a project to GitHub, which gives you the code. You then build and deploy it elsewhere. Your database may sit in a separate service, such as Supabase, so also check who owns that account and how to keep it connected after the move.”
}
},
{
“@type”: “Question”,
“name”: “Can I host a Next.js app on shared hosting?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Usually not by default. Shared hosting built for PHP does not run a Node.js server. If your Next.js app can be exported as static files, it can work. If it needs server features, choose a host that supports Node.js, such as Vercel or a VPS, or confirm your plan supports Node.js apps.”
}
},
{
“@type”: “Question”,
“name”: “Do I need a developer to move my AI-built app to my own hosting?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Not always. A static app is often something a careful beginner can deploy by following the host’s guide. You may want a developer for apps with a backend, payments, user data or complex login. A one-time review is cheaper than fixing a broken launch.”
}
},
{
“@type”: “Question”,
“name”: “What happens to my app if I cancel my Lovable or Bolt plan?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It depends on the platform’s terms and your plan, so read them before you cancel. The safe approach is to keep your code in GitHub, your domain at your own registrar and your hosting under your own account. Then a cancelled plan does not take your site offline.”
}
},
{
“@type”: “Question”,
“name”: “Do I need professional email on my own domain?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “You do not need it to launch, but you should set it up soon. Emails from your own domain look more trustworthy, and customers are more likely to reply to them. Your host may include mailboxes, or you can use a dedicated email service. Add the SPF, DKIM and DMARC records so your messages reach the inbox.”
}
}
]
}

Conclusion: own the name, own the code

AI tools make it easy to build an app. They do not make you the owner of the address it lives on. Owning your domain, your GitHub repository and your hosting account turns a fragile demo into something you control.

The steps are short: buy the domain, sync the code to GitHub, match your app to the right host, set up the database variables, connect DNS, turn on SSL, add email, and run the checklist. None of it needs you to become a developer.

Start with the one step that costs the least and protects the most: secure your name today with Domain.com, then come back to this guide for the rest.