What Does Deployment Mean? A Plain-English Explanation

The one-sentence version: preview is private, deployed is public

While you're working inside Lovable, Base44 or Bolt.new, you're looking at a preview, a live view of your project that exists for you, the person building it. Nobody else can reach it by default. Deployment is the specific action that changes that: it takes the current state of your project, builds it, and puts the result somewhere with a real, public address, at which point anyone who has that address, or your domain once it's pointed there, can actually load your site.

This distinction matters the first time something behaves differently in the two places. Preview and deployed aren't always running under identical conditions, which is exactly why "it works when I look at it" and "it works for a real visitor" aren't automatically the same claim.

What actually happens when you click Publish

Two things happen, in order, whether or not the platform shows you either step directly. First, a build runs: your project's actual source files get compiled, bundled and optimised into the exact static files (and, if your project has one, backend functions) a browser and server will actually use. Second, those built files get pushed somewhere with a real public address, on infrastructure the platform manages for you, or your own hosting if you've exported and deployed independently. The build step is the one most worth knowing about, since it's also the step most likely to fail on its own, separately from whether your project's underlying logic is correct.

Why "worked in preview, broke once deployed" is almost always one of two things

This exact phrase usually narrows to two likely causes worth checking in order. The first, and most common: an environment variable that existed in your builder's preview session simply wasn't carried over to the deployed environment, covered in full in our guide to what an environment variable is. The second: a setting on the host doesn't match your build, such as the folder it publishes or the path your pages load their files from, covered in our guide to fixing a blank screen after deploying. Checking both before assuming your actual code is broken saves real debugging time.

Deploying to a builder's own subdomain vs. your own domain

Every deploy needs an address, and the simplest one is whatever subdomain your builder gives you by default. That's a complete, real deployment, fine to use as-is. Moving to your own .co.za domain doesn't create a second deployment, it's a DNS change layered on top of the one that already exists, pointing a domain you own at infrastructure your builder already deployed to. Our guide to connecting your own domain covers this exact step: the address changing, not the deploy mechanism underneath it.

Not every deploy looks the same

AI website builders usually deploy to their own managed hosting with one click, no separate hosting decision required. A genuinely different path exists too: exporting your project and hosting it yourself, which our guide to where to host an AI-built website weighs up, including what moves and what stays behind. Same underlying concept, a build followed by a public address, different amounts of infrastructure you're responsible for.