Course B · Module B1 Production · Lesson 4 of 18
Get your app onto the real internet, at your own web address — and understand the invisible machinery keeping it there.
Your app works on your laptop — or inside a builder tool's preview. That's not the same as "on the internet." To reach real customers, your app needs to run on a computer that's always on, at an address people can type into a browser. That's hosting. The good news: for the kind of apps founders build today, the platforms that handle hosting are largely automatic. Your single win: by the end you'll understand the four things that turn a local project into a live web address, and know which platforms do them for you.
Your laptop is a great place to build — but you close the lid. When you close the lid, your app disappears from the internet. Hosting means putting your app on a computer that never closes its lid: a server sitting in a data center, running 24 hours a day, ready to send your app's files to anyone who visits your URL.
You don't own or maintain that server directly. You rent space on it (or, more precisely, you deploy to a platform that rents it for you). Modern platforms like Vercel and Netlify abstract all of the hardware management away.
When you first deploy to Vercel or Netlify, you get an auto-generated address
like my-app-abc123.vercel.app. That works for testing, but real
customers need a real address: yourbusiness.com.
A domain is that address. You buy it from a registrar (Namecheap, Google Domains, Cloudflare) for roughly $10–15 per year, then point it at your hosting platform. The platform gives you a couple of lines to copy into your domain's DNS settings — your AI can walk you through the exact steps in about fifteen minutes.
http:// instead
of https://, fix it before you share the link with anyone. Browsers
show a warning and customers leave.
One of the most important habits in production software is keeping a preview environment separate from your live site. Modern hosting platforms give you this automatically — every branch on GitHub gets its own temporary URL to test against, before any change touches what real users see.
mainpr-42.my-app.vercel.appmain onlyyourbusiness.com)Before platforms like Vercel existed, "deploying" meant renting a server, configuring a web server process, managing security patches, setting up SSL, and writing deployment scripts. Each step was an afternoon. Today, this is what happens automatically when you push to GitHub:
npm run build) to compile the app.You get all of that by connecting your GitHub repository once. The lesson here is not to learn how each step works — it's to appreciate what's being handled for you, so you're not tempted to build something more complicated than you need.
Answer before opening — recalling it is what makes it stick.
Because your laptop isn't always on and isn't publicly reachable. When you close the lid, the app is gone. Hosting puts your app on a server that's always on, always connected, and accessible to anyone via a web address — independent of what your laptop is doing.
Test it on the preview environment — the temporary URL the platform generated for that branch. Every change deserves a run on preview before it touches the production URL where real customers are. This is the whole point of the environment separation.
A domain is the address (yourbusiness.com); hosting is the computer the app actually runs on. The domain points at the hosting platform. You need both: the hosting serves the app, and the domain gives it a recognizable, permanent address.
Read this next (primary source)
Getting Started with Vercel — Vercel Docs. The official guide walks you from zero to a live deployment, including connecting a GitHub repo and setting up a custom domain. ~15 min. See RESOURCES.md for more.
New terms from this lesson — deploy, domain, environment, HTTPS — are in the course glossary. Keep it open as you go.