Module 7: Ship to Production
Lesson 1

Hosting Explained — Servers, DNS, CDN in plain language

Your App Lives on Your Laptop (For Now)

Right now, your app only exists on your computer. When you run npm run dev, a tiny web server starts up at http://localhost:3000. You can open it in your browser — but only you can. No one else on the planet can reach it. The moment you close your laptop, it's gone.

Deploying means putting your app on a server on the internet — a computer that's always on, always connected, and reachable from any browser, anywhere in the world.

When someone types yourapp.com into their browser, their browser connects to that server, the server runs your app, and it sends back the page they see. That's the whole magic. By the end of this module, that someone will be able to be anyone.

The Pieces of a Live Web App

A live app isn't one thing — it's a handful of pieces working together. Here's the journey a single page-load takes:

User's browser
      ↓  types your domain name
DNS (the internet's address book)
      ↓  translates the name into a server address
Your hosting (Vercel)
      ↓  runs your Next.js app
Supabase (your database)
      ↓  returns the data
Back to the user's browser

Let's walk through each piece in plain language. You don't need to memorize this — you just need to recognize the names when they come up.

DNS: The Internet's Address Book

Computers don't actually find each other by name. They find each other by IP address — a string of numbers like 76.76.21.21. But nobody wants to type numbers to visit a website.

DNS (Domain Name System) is the translation layer. When someone types google.com, DNS looks it up and returns the IP address the browser should actually connect to — exactly like looking up a contact's name in your phone to get their number.

When you buy a domain (in a later lesson), you'll configure its DNS records to point at your hosting. That's the step that connects your name to your app.

Hosting: The Always-On Computer

Hosting is the server that runs your app and keeps it online 24/7. We'll use Vercel.

Why Vercel? Because the same company that makes Vercel also makes Next.js — the framework your app is built on. They know exactly how to run it, so deployment is about as painless as it gets. And the free tier is genuinely generous; you can ship a real project without paying anything.

Vercel quietly handles a lot of hard things for you:

  • HTTPS — the little padlock in the address bar that means the connection is secure. Free, automatic.
  • Global CDN — copies of your app live on servers around the world, so it loads fast whether your visitor is in Singapore or São Paulo.
  • Automatic scaling — if your app suddenly gets a thousand visitors, Vercel handles it without you touching a thing.

CDN stands for Content Delivery Network. Think of it as having a copy of your shop on every street corner, so customers always reach the nearest one.

Your App: Next.js

This is the code you've been building. Nothing new to learn here — Vercel runs Next.js apps natively. You hand it your code, it does the rest.

Your Database: Supabase

If your app stores data — users, tasks, posts, anything — that lives in Supabase, which is already in the cloud. Vercel connects to it using the same secret keys you set up on your laptop. You'll copy those keys into Vercel in the next lesson.

What Is a Domain Name?

A domain name is the human-friendly address people type to reach your site: yourapp.com, dailyfocus.app, mytool.io.

Every domain has two parts:

  • The name — yourapp
  • The top-level domain (TLD) — .com, .io, .app, .net, and so on

You don't need a custom domain to go live — Vercel gives you a free address like yourapp.vercel.app automatically. But a custom domain makes your project look like a real product instead of a weekend experiment. We'll cover choosing and buying one in its own lesson.

The Deployment Workflow (The Best Part)

Here's the payoff for all this setup. Once everything is wired up, shipping a change looks like this:

Write code  →  git commit  →  git push  →  Vercel auto-deploys

Within a minute or two of pushing your code to GitHub, your changes are live for the whole world. This is called continuous deployment — you never manually "upload" anything again. You just save your work, and it ships itself.

You also get, for free:

  • Preview deployments — every branch or pull request gets its own private URL, so you can test a change before it goes live.
  • Instant rollbacks — if a deploy breaks something, you can revert to any previous version with one click.
  • Build logs — a full record of what happened during each deploy, so when something goes wrong, you can see exactly why.

Secrets in Production: Environment Variables

On your laptop, sensitive values like your Supabase keys live in a file called .env.local. That file is deliberately kept out of GitHub — secrets should never be committed to your code.

So how does the live app get them? You'll paste them into Vercel's dashboard as environment variables. Vercel injects them securely when your app runs. We'll do this together in the next lesson.

The golden rule: never put secrets in your code. Always use environment variables. Claude Code already follows this pattern when it builds your app — your job is just to copy the values into Vercel.

Summary

  • Deployment = putting your app on an always-on server so anyone can reach it.
  • Vercel hosts your Next.js app — the company that builds Next.js, so it just works.
  • DNS is the address book that translates your domain name into your server's address.
  • HTTPS, CDN, and scaling are all handled automatically by Vercel.
  • Once set up, your workflow is simply: push to GitHub → it deploys itself in 1–2 minutes.
  • Secrets like database keys go in Vercel's environment variables, never in your code.