What is hosting? (where your app actually lives)

What it actually is

Hosting is the computer that keeps your app running and reachable at a URL, all day and all night, whether or not you personally have a laptop open anywhere. Your code has to live somewhere that never sleeps and stays connected to the internet, and that “somewhere” is a company’s servers, sitting in a data center, answering the moment someone types your address into a browser.

Think of it like a restaurant. Writing your code is developing the recipes and building the menu. Hosting is renting the actual building: the address on the street, the lights that stay on, the door that opens whenever a customer walks up, even at 2am when the chef is home asleep. Without a building, the best recipes in the world still serve nobody.

Why your AI just did this

Claude Code writes and runs your app on your own computer. When you type npm run dev and open localhost:3000, your laptop is acting as a tiny, temporary host, one that only you can reach, and only while that terminal window stays open. Close the laptop or lose wifi, and the app is gone for everyone, because it was never actually hosted anywhere, it was just running.

So when you ask your agent to “put this online” or “make it live,” it has to connect your project to a real hosting platform: Vercel, Netlify, Railway, or something similar. It’ll typically run a CLI command like vercel deploy, add a config file the platform reads, or wire up a GitHub connection so every git push triggers a fresh deploy on its own. That’s the whole job of a host: take your code, build it, and keep it answering requests without your laptop involved at all.

If you built your first version in Lovable or Bolt instead, the same idea just shows up earlier. Those tools hand you a free default address so you can publish immediately and skip this step at first. The moment you want your own domain, a database that isn’t tied to the builder, or you’re moving the code out to keep building it with Claude Code, you’re back to picking an actual host yourself.

When you’ll run into it

• Your agent finishes a feature and asks “this is working on localhost, want me to deploy it?”
• You send a friend a link and it’s localhost:3000, which only works on your machine, never on theirs.
• “Bought a domain name, now how do I host the website?” is a common question, because a domain is just the address; it points nowhere until something is hosting a site behind it.
• Your Lovable or Bolt app works fine on its default subdomain, but adding your own domain or real backend logic pushes you toward Vercel, Netlify, or exporting the project to GitHub.
• A deploy fails with a build error your local npm run dev never showed, because the host builds your project fresh in a clean environment and catches things your own machine was quietly tolerating.

What to check

• Whether your app actually needs to reach the public internet yet; a lot of early building is fine on localhost
• Whether you need a static host for plain HTML, CSS and JS (Netlify handles this well) or one that also runs server code and databases (Vercel, Railway)
• That your environment variables are set in the host’s dashboard too, not only in your local .env file
• Whether the platform auto-deploys on every git push or needs a manual deploy command each time
• That your domain’s DNS actually points at the host you picked now, not at an old one from an earlier attempt

Say it like a dev

Instead of: “put my app online” Say: “deploy this to Vercel” or “which host should we deploy this to”

Instead of: “why does my site only work for me” Say: “is this only running on localhost, or is it actually deployed somewhere”

Instead of: “the website isn’t working” Say: “is this a hosting problem or a DNS problem, is the domain even pointing at the right host”