Deployment, DNS, and HTTPS: The Life of a URL
Type an address, get a page — what actually happens between the enter key and the pixels, and why the little padlock matters.
What happens when you press Enter
- DNS lookup. The browser asks the internet's phonebook: what is the IP
address for
example.com? DNS translates names → numbers, worldwide, cached at many layers for speed. - TCP + TLS handshake. The browser connects to that address and agrees on encryption keys with the server.
- HTTP request/response.
GET /comes back as HTML. - The page loads. The browser parses the HTML, discovers the CSS and JavaScript, fetches those, renders — your code from Module 1, in full circle.
HTTPS — the padlock is non-negotiable
HTTPS is HTTP inside TLS encryption. Anything sent over plain HTTP can be read or modified by anyone between you and the server — passwords, cookies, everything.
HTTPS gives three guarantees: encryption (nobody reads the traffic), integrity (nobody modifies it in transit), and identity (the certificate proves the server is who it claims). Certificates are free and automatic in 2026 (Let's Encrypt and every major host) — a site without HTTPS today is a red flag, full stop.
How code gets deployed
- Static sites (your Modules 1–5 projects): files copied to a CDN-backed host. Fast, cheap, ideal when the browser does all the work.
- Full-stack apps (like Code Journey): a running server process plus a database, deployed to a platform that manages machines, restarts, and scaling.
Either way the rhythm is identical: push code → pipeline deploys it → users get the new version. You have done the static version already with GitHub Pages.
The whole picture — and your place in it
DNS turns a name into a machine. HTTP carries a request to it. The server's backend queries its database and answers in JSON. The browser's frontend renders it. You have now written the frontend, consumed APIs as a client, and understand the machinery behind every remaining piece.
Next: put all of it together — the final project.