Where to Host an AI-Built Website: What Moves and What Stays

What web hosting is, in simple words

Your website is a set of files: pages, pictures and the code that makes buttons work. Hosting is a computer that stays switched on and connected to the internet, keeps those files and sends them to anyone who types your address. The company that runs that computer is your host.

Three words get mixed up here. Hosting is where the site lives. Deployment is the act of putting a new version there; our guide to what deployment means covers it. Your domain is the address people type, such as yourbusiness.co.za, and DNS is the system that points that address at your host. You can redeploy, change host or change domain without touching the other two.

When you click Publish in an AI website builder, the builder deploys your site to its own hosting and gives it an address. So if your site is live, it's already hosted. The real question is whether it should stay there.

A simple site and an app are hosted differently

A site that only shows pages, such as a menu, a portfolio or a brochure, is a set of files that doesn't change until you publish again. Almost any host can serve it, because all the host does is send files.

An app is different. As soon as visitors can sign in, save a form, upload a photo or pay, your project has a backend: a database and code that runs on a server, out of the visitor's sight. Most AI website builders set that backend up for you, often on a separate service. This matters here because the backend is the part that doesn't move when the pages do.

Can your project leave the builder?

Usually the pages can. Most AI website builders let you take the code out, either as a one-time export or through Git sync to a GitHub repository, and another host can then serve those pages. The backend behind them is a separate matter, covered in the next section, and some builders document no way for it to leave at all.

Builders offer one or both of these:

• An export. You download the code, often as a ZIP file. It's a snapshot: every change you make in the builder afterwards means downloading and uploading again.
• Git sync. The builder connects to a repository on GitHub and keeps it up to date. Changes you make in the builder land in the repository, and a host that deploys from GitHub can pick them up without you downloading anything. Our guide to what Git is explains repositories.

Some builders offer export only on paid plans, and the routes differ: a download, GitHub, or both. Check your builder's own documentation for what yours offers today; the idea stays the same even when the buttons move.

What you get out is source code, not a finished site. It usually needs a build step: one command that prepares it for a host. For some projects that produces plain files any host can serve. Others, including new projects on some builders, also run code on the server to produce their pages, so they need a host that can run that code. Your AI can tell you which kind yours is.

What moves and what stays behind

Taking the code out gives you the pages and the instructions your pages use to talk to the backend. It doesn't give you the backend itself: the database, user accounts, uploaded files, server functions and secret keys all stay where they are. This is the part people usually discover only after the move.

Lovable's own self-hosting documentation makes a related point about its standard backend: even moving the database doesn't move sign-in, file storage, live updates (data that refreshes on screen without reloading) or server functions. Each needs its own step.

Some builders run the backend on their own in-house system and document no way to run it anywhere else. Code you take out of those builders keeps calling back to the builder for its data, so what you host elsewhere is the front of the app, not the whole thing. That's a fine setup if you know it. It's a nasty surprise if you thought you'd left.

Is it worth moving?

Often it isn't. A builder's own hosting renews security certificates, applies updates and redeploys your site for you, and publishing a change takes one click. Moving hands all of that to you, and your backend usually stays with the builder anyway. Move only for a clear reason that holds up, and check yours against the lists below.

Reasons that usually hold up:

• You need something the builder's hosting can't do, such as a server setting or a feature your project depends on.
• You already run other sites with one host and want everything in one place.

Reasons that usually don't:

• "It'll be cheaper." Maybe, but if the backend stays on the builder, you may still need the builder's plan for it. Compare the whole bill, not only the hosting line.
• "POPIA says I must host in South Africa." It doesn't, and moving the pages doesn't move the data anyway (see the next section).
• "I want my code out of the builder." Git sync gives you a copy in your own GitHub account without moving the hosting at all.
• "My own domain needs my own hosting." Most builders let you connect your own domain to their hosting.

What you take on if you move: redeploying after every change (unless your host deploys from GitHub), adding your secret keys again, making sure your security certificate renews, and fixing things yourself when an update breaks the site.

Where your users' data actually lives

Hosting your pages on a server in South Africa helps them load quickly for South African visitors. It says nothing about where your users' names, emails and orders are stored. Those live in the backend, in whatever region that backend was set up in, often overseas. If your business collects personal information from its users, POPIA applies, and the question to answer is where the backend stores it and on what basis it may be sent there. Our guide to whether Supabase, a common AI website builder backend, is POPIA compliant covers what to check.

What to look for when choosing a host

This page doesn't rank hosts or quote prices. Prices change and depend on the plan. Check these instead, then read the host's current pricing page:

• Files only, or code that runs? A simple site needs only file hosting. If your project runs code on the server to build its pages, or has server code of its own that isn't on the builder's backend, the host must be able to run it.
• How your site gets there. Deploying from GitHub is easier over time than uploading files by hand.
• A free security certificate that renews itself, so the padlock in the browser doesn't lapse.
• Single-page app support. Many AI-built sites are single-page apps: the browser loads one file and swaps pages in itself, so a page that opens fine from the menu can show "not found" when someone opens its address directly. Our guide to blank screens and missing pages after deploying explains the setting that fixes it.
• A place for your keys. Somewhere to store your secret keys and settings (environment variables), or a clear way to add them at build time.
• Where the servers are, and who answers when it breaks. A server in South Africa is closer to South African visitors, and support in your time zone helps.
• On the pricing page: the renewal price, not only the first-year price; whether it bills in rand or dollars; and what happens if your traffic grows.

What usually breaks after a move

• The page loads blank, and the browser's error console mentions keys or addresses. The secret keys and settings weren't added on the new host, or were added after the build. Our guide to environment variables that stop working after deploy explains why.
• Sign-in stops working. The backend's sign-in settings still allow only the old address. Add the new one.
• Pages show "not found" when opened directly. The single-page app setting above is missing.
• Even the home page shows "not found" or a list of files. The source folder was uploaded instead of the built files, or the files sit one folder too deep.

Test the new site before you point your domain at it: sign in, save something, upload something, and open a few pages directly by their address.

The prompt to give your AI

Paste this into your AI website builder's chat, or give it to your AI coding agent, before you move anything. It asks the AI to describe your project, not to change it.

I'm not a coder. I'm thinking about hosting this project somewhere
other than where it runs now. Don't change any code. Look at the
project and tell me, in plain English:

1. Is it a simple site that only needs its files served, or does it
   have server code that has to run somewhere?
2. Every outside service it depends on (database, sign-in, file
   storage, server functions, payments, email), and where each one
   runs today.
3. Every secret key and setting (environment variable) it needs,
   by name only, and whether each one is used in code that runs in
   the visitor's browser. Don't show me the values.
4. Which of those would move if I hosted only the code somewhere
   else, and which would stay where they are.
5. What would break or need changing if the site's address changed,
   for example sign-in redirect addresses.
6. How to get the code out of this builder (export or GitHub), and
   the command that builds it into files a host can serve.

If you're not sure about any answer, say so instead of guessing.

What to check in the AI's answer

• It named a place for every service. "The database is handled automatically" isn't an answer. Ask where it runs.
• It didn't say the database or users move with the code. If it did, ask it to explain how, step by step, and compare that with your builder's documentation.
• It listed secret keys by name, with no values, and none of them sit in code that runs in the browser. If one does, sort that out before anything else; our guide to why an API key can't go in frontend code explains why.
• It mentioned sign-in redirect addresses, if your project has sign-in.
• The export route it described exists. Look for it in your builder. An AI will sometimes describe a button that isn't there.

If the answer shows that most of your project lives in the builder's backend, that usually settles it: keep the hosting where it is, connect your own domain, and turn on Git sync so you have a copy of the code.