What Is Deployment? From Your Laptop to a Live URL

Deployment is the act of getting a new version of your app to the place where users open it. Hosting is that place: a computer (or someone else’s platform) that keeps your app running around the clock and answers requests from the internet.

While you build in Lovable, Bolt or Cursor, the app lives inside the builder or on localhost, an address that exists only on your machine. Close the laptop and the site is gone. Deployment solves exactly that.

What is deployment, step by step

“Let’s deploy” usually means three things.

Build. Source code is turned into something runnable: JavaScript is bundled and minified, styles are compiled, the server is packaged. The result is called a build or an artifact. If the build fails, nothing ships, which is a feature.
Delivery. The build is copied to the host. Sometimes that is uploading files, sometimes it is a container image the platform pulls itself.
Switch-over. The new version starts taking requests and the old one stops. Good platforms do this without downtime: they start the new version, check that it responds, and only then shut down the old one.

Usually this runs automatically when you push to the main branch in Git.

Where the app actually lives

There are several kinds of hosting, and the main difference is how much work they take off your plate.

Static hosting. For sites without their own server: a landing page, docs, a frontend that talks to other APIs. Fast, cheap, very little to break.

Serverless. You write functions, the platform runs them on demand and decides how many copies are needed. There is still a server; it just isn’t yours. Convenient for getting started, less so when you need long-running jobs, persistent connections or a predictable bill.

Your own server (VPS). You rent a virtual machine and install everything yourself. Full control and a clear price, but OS updates, certificates and restarts are now your job.

Managed platform. The middle ground: you hand it a repository or a container, and it builds, runs, restarts and shows you logs. For most young projects this is a sensible starting point.

The database lives separately, and deploying code doesn’t touch it, except for migrations.

What usually breaks on the first deploy

“Works on my laptop” and “works on the internet” differ in a few predictable places.

Settings. Locally, keys and URLs sit in .env; on the host they have to be set separately. Forget one and the app crashes at startup or quietly talks to the wrong service.
Addresses. The code has localhost:3000 baked in, so in production the frontend tries to call your laptop.
Versions. You run one version of Node or Python locally and the server runs another. Pin the version explicitly.
Files. User uploads are saved to disk, but on serverless and many platforms the disk is wiped on every deploy.
Database. The schema changed locally, but nobody ran the migration on the production database.

Rollback: the most underrated button

Sooner or later you will ship a version that breaks login or payments. The question is not whether, but how many minutes it lasts.

A rollback means returning to the previous working version without fixing anything in code. Patching live production in a hurry is a bad idea; the better move is to restore what worked yesterday and debug calmly.

For a rollback to be possible:

every version should be a separate build, not a set of edits made directly on the server;
the platform should keep at least a few previous versions;
database migrations should be backward compatible, so the old code can still run against the new schema.

Try a rollback once in advance, on a quiet day. If you don’t know which button to press now, you won’t during an outage.

How to tell your deployment is in good shape

A good sign is that you can answer these in under a minute:

which version is in production right now, and which commit it was built from;
how to ship a new version with one command or one push;
how to go back to the previous one;
where to look at logs if something goes wrong after a release.

If any answer is “I’d have to ask the AI”, that is a reason to spend an evening on it before you have more users.

In short

Deployment is getting a new version to users; hosting is where it runs.
A deploy is build, delivery and switch-over, ideally triggered automatically from Git.
Static hosting, serverless, a VPS and managed platforms differ in how much work stays with you.
First deploys usually break on settings, hardcoded addresses, versions, files on disk and forgotten migrations.
Learn to roll back before you need to.

If your project still lives only inside a builder, SUBXCAT can set it up with a proper deploy, rollbacks and logs.