Aryan Tripathi — Writing
← All writing

August 8, 2026 · 3 min read

From localhost to a live URL, no domain required

What localhost:3000 actually means, why nobody else can open it, and how a free host gives you a real public URL the moment you connect a repo — Part 1 of a 5-part course on how a website actually gets from your laptop to the internet.

#course#fundamentals#hosting

This is Part 1 of a five-part series I teach in almost every cohort I train, because it answers a question beginners ask constantly and rarely get a straight answer to: "my site works on my laptop — how do I actually let someone else see it?"

The honest answer has more moving parts than most tutorials admit. This series walks through all of them, in the order you actually hit them: localhost, free hosting, buying a domain, nameservers, and finally a real CI/CD pipeline. We'll use this very site — arytripathi.com and this blog — as the running example, because every diagram here is describing something actually live, not a toy.

Where we are in the journey

1
Localhost
2
Free host
3
Domain
4
DNS / Cloudflare
5
Production

What "localhost" actually means

When you run npm run dev and your terminal says ready on http://localhost:3000, a process on your machine started listening on port 3000. Your browser, also on your machine, can reach it because they share the same network stack — literally the same computer. "localhost" is just a hostname that always means "me."

Your machine

Browser
Dev server — localhost:3000

Both live on the same machine. “localhost” just means “this computer, talking to itself.”

connection
refused

Anyone else, anywhere else

Their browser

They have no route to your laptop’s port 3000. Nothing is “wrong” — the address was never public to begin with.

Nothing about this is broken or half-finished. It's a complete, fully working web server — it's just only reachable from inside the same machine. Your phone, on the same wifi, can't open it. Your friend across the world definitely can't. There's no address for them to even try.

Why this trips people up

A dev server and a "real" server run the exact same code. The difference isn't the server — it's whether anything routes to it from outside your machine. That's the entire subject of this series.

Getting a URL, before you own anything

Here's the part that surprises people: you don't need to buy a domain to put something on the internet. Free hosts — Vercel, Netlify, Cloudflare Pages, GitHub Pages — will build your project and give it a real, working, shareable URL on their domain, for free, the moment you connect a GitHub repository.

Where we are in the journey

1
Localhost
2
Free host
3
Domain
4
DNS / Cloudflare
5
Production

git push → live URL, with no domain and no server to manage

GitHub repogit push origin mainFree host builds itVercel / Netlify / PagesLive URLyourapp.vercel.app

No domain purchase happened here. The host owns vercel.app (or netlify.app, or pages.dev) and hands you a free subdomain of it — enough to share a real, working link with anyone, instantly, every time you push.

This is usually the right first move for a portfolio, a hackathon project, or an MVP you're not sure will go anywhere yet. It costs nothing, it's genuinely production-grade hosting (the same infrastructure serving huge production apps), and it removes "I don't have a domain yet" as a blocker entirely.

What you're trading away is the address itself — yourapp.vercel.app instead of yourapp.com. For a lot of projects, that's a completely reasonable trade, permanently. You only need what comes next in this series once the project needs its own identity: a business, a personal brand, an email address that matches your site, or just because yourapp.com reads better on a resume than yourapp.vercel.app.

The one thing already happening here: CI/CD, in miniature

Notice what actually happened in that diagram: you pushed code, and something else — not you — built it and put it live. That's continuous deployment, and you already used it without a single YAML file. Part 4 of this series goes deep on how that pipeline works and how to build your own with GitHub Actions; for now, just notice the shape of it, because every deployment method in this series is a variation on the same idea: push triggers build triggers live.

What's next

Part 2 covers what actually happens when you do decide to buy a domain — who ICANN is, what a registrar sells you, and what ICANN Lookup can tell you about any domain on the internet (including, thanks to privacy redaction, mostly not who owns it).

Continue to Part 2 — Buying a domain, ICANN, and WHOIS →