How Localhost Becomes a Real Website

Let’s break down how you get from a local dev server to a live domain — DNS, hosting, builds, and all that jazz.

So you build your first app and you’ve got it running at the most famous URL known to every developer: http://localhost:3000. You’ve done good — it compiles, it actually looks decent. Then the most infamous question of all lands in your lap:

“Can I see it?”

Sweat forms on your brow, and it hits you all at once: how the hell do you actually put this thing on the internet?

Let’s walk the whole path — from your laptop to a stranger’s browser on the other side of the planet.

The full journey

Click through each node above to see its role. Here’s the whole story, step by step.

Step 1: Where does your code actually live?

Before anything can go live, your code has to sit somewhere your hosting service can reach it — a remote repository. That’s the source of truth everything else pulls from, not just a backup.

If “remote repo,” “push,” and “branch” aren’t second nature yet, go read Git beyond add, commit, push first, then come back. The short version: you push your latest code up to GitHub (or GitLab), and that becomes the version this whole pipeline builds from.

git add .
git commit -m "feat: ready to ship"
git push origin main

Step 2: A clean build runs (budum tss)

Most people don’t deploy by hand — they let a cloud provider do it. These are the companies that host your site and rebuild it every time you push. The big friendly ones:

• Vercel

  Heads up — you're leaving raindev.fyi

  This link heads to vercel.com, an external site we don't control. Cool to keep going?

  Stay hereContinue
  — great with Next.js, Astro, Svelte
• Cloudflare Pages

  Heads up — you're leaving raindev.fyi

  This link heads to pages.cloudflare.com, an external site we don't control. Cool to keep going?

  Stay hereContinue
  — very fast, generous free tier
• GitHub Pages

  Heads up — you're leaving raindev.fyi

  This link heads to pages.github.com, an external site we don't control. Cool to keep going?

  Stay hereContinue
  — dead simple, free, perfect for docs and portfolios

(Those links will give you a heads-up before they bounce you off the site.)

The moment you push, the provider springs into action:

1. Pulls your latest code from the repo you linked.
2. Installs your dependencies — all the packages you’ve been adding by hand or with npm.
3. Runs your build (npm run build) to turn your source into shippable files.

Quick detour, because the terms trip everyone up: npm is the Node Package Manager — the tool that downloads the libraries your project leans on. On a build server it usually runs npm ci (think “clean install”). Instead of guessing, npm ci wipes node_modules and installs the exact versions pinned in your package-lock.json. That’s the trick that makes the build on Cloudflare match the one on your laptop — same versions, every single time.

This whole stage is the CI build (Continuous Integration). If anything breaks — a type error you didn’t catch locally, a failing test — the deploy stops dead right here. Nothing broken reaches your users.

Step 3: The hosting provider serves your build

Once the build succeeds, the output — your folder of HTML, CSS, JS, and images — gets handed to the hosting provider to store and serve. For a static site that’s basically the whole job: they drop your files on a server and hand you a temporary URL like your-project.vercel.app so you can see it live right away.

That temp URL already works for anyone in the world. The only thing missing is your name on it — which is the next two steps.

Step 4: A CDN caches your assets

Here’s where it gets fast. A CDN (Content Delivery Network) is a small army of servers scattered across the planet — those copies are called edge locations. Instead of every visitor phoning one lonely server in Virginia, the CDN keeps a copy of your files close to wherever your users actually are.

“Cached” just means a saved copy. The first time someone in Tokyo loads your site, the nearest edge server fetches your files from the origin and stashes them — that’s a cache miss. Every visitor after that gets the local copy instantly — a cache hit — with no slow trip across the ocean. When you ship an update, the provider clears the old copy so the edges grab the fresh one.

For a static site this is basically free speed: your HTML, CSS, and JS don’t change between requests, so they cache beautifully. Vercel, Cloudflare, and Netlify all bundle a CDN in by default — something that used to cost real money and a lost weekend to wire up yourself.

Step 5: Your domain points at the CDN

So far your site lives at something like your-project.vercel.app. Time to give it a real name.

A domain is just the human-friendly address people type instead of a string of numbers — raindev.fyi instead of 76.76.21.21. Under the hood, computers route everything by IP address; domains exist so you don’t have to memorize those.

You rent a domain (yes, rent — usually a yearly fee) from a registrar. Common ones: Namecheap, Cloudflare Registrar (sells at cost, no markup), Porkbun, or Google’s old domains business, now run by Squarespace. Pick a name that isn’t taken, pay the yearly fee, and it’s yours to point wherever you want.

Pointing it is the job of DNS (Domain Name System) — the phone book of the internet, mapping names to IP addresses. In your registrar’s dashboard you add a record that says “when someone visits raindev.fyi, send them to my hosting provider”:

CNAME  @    cname.vercel-dns.com.
CNAME  www  cname.vercel-dns.com.

That change propagates across the internet — usually within minutes, occasionally up to 48 hours — and after that, your name routes real traffic to your site.

Step 6: The browser does the rest

Someone finally types raindev.fyi and hits enter. Here’s the relay race that runs in well under a second:

1. DNS lookup — “what IP is raindev.fyi?” The CDN’s address comes back.
2. TLS handshake — the secure-connection part. TLS (Transport Layer Security — the “S” in HTTPS) encrypts everything traveling between the browser and the server, so nobody sharing the coffee-shop WiFi can read it. The server presents its certificate (cryptographic proof it really is raindev.fyi, signed by an authority browsers trust), the two sides agree on a set of keys, and from that point on the connection is private.
3. HTTP request — now they can actually talk. HTTP is the request-and-response language browsers and servers speak. The browser sends a request like GET / (“send me the homepage”), and the server replies with a response: a status code (200 = OK, 404 = not found, 500 = the server tripped) plus the actual index.html.
4. Parse — the browser reads the HTML, spots the <link>, <script>, and <img> tags, and fires off more HTTP requests to grab each one.
5. Render — it paints the whole thing onto the screen.

The fastest path to production right now

For a static site or an Astro / Next.js app, here’s the whole thing end to end:

1. Push your repo to GitHub.
2. Connect it to a host like Vercel or Cloudflare Pages (free).
3. Set your build command and output directory.
4. Add your custom domain in the host’s dashboard.
5. Update your registrar’s DNS to point at the host.

That’s it. From there, every push to main deploys itself — you go back to just writing code.

The classic “but it works on localhost” traps

Everything green locally and broken in prod? It’s almost always one of these:

Now you know the whole journey. Every website you’ve ever loaded went through these exact same steps.