⬇ Save as PDF / Print

Stack Basics · Module 2 of 5

Module 2 — The plumbing: domains, tunnels, TLS, and staying alive

You have a machine that's always on. Now the internet needs to find it, trust it, and keep getting answers from it even when your code crashes at 4am. That's four small pieces of plumbing. None of them are hard; all of them are the difference between a demo and a vending machine.

1. A domain (~$10/year)

Agents and humans both need a stable address. https://api.yourthing.com survives server moves, IP changes, and provider switches — a bare IP survives nothing. Buy the domain at any registrar, then point its DNS at Cloudflare's free tier even if you do nothing else there: you get DNS management, a CDN, and the tunnel option below, all free.

One habit that pays forever: put services on subdomains (api., shop., stats.). You'll add more services than you think, and subdomains make each one movable on its own.

2. Reachability: open ports vs. tunnels

Two ways the internet reaches your machine:

Open ports (classic way). On a VPS you point DNS at your static IP, open ports 80/443 in the firewall, and put a reverse proxy (Caddy or nginx) in front of your app. Caddy is the beginner-friendly one — it fetches and renews TLS certificates automatically with about three lines of config.

A tunnel (the way I actually run things). A tiny agent (Cloudflare Tunnel / cloudflared, free) runs on your machine and dials OUT to Cloudflare; traffic to your domain flows back down that connection. Why I like it even on a VPS with a public IP: zero open inbound ports (your firewall stays closed — a scanner can't even knock), TLS is handled for you, and adding a new hostname is a dashboard entry, not a config file. And on a Mac mini or Pi behind home NAT, a tunnel isn't optional — it's the whole trick that makes home hosting work.

3. TLS

If you use Cloudflare (proxy or tunnel), you already have it — the padlock costs nothing and takes zero maintenance. If you're raw on a VPS, Caddy gives you the same for free via Let's Encrypt. There is no reason to serve http:// in 2026, and plenty of payment tooling will simply refuse to talk to you if you do.

4. Staying alive: process managers

Your app WILL crash. A dependency hiccup, an unhandled promise, an out-of-memory kill. The question isn't if — it's whether anything restarts it.

• systemd (built into every Linux) — my choice. One small unit file per service: starts on boot, restarts on crash, logs to journalctl. Ask your coding agent to "write a systemd unit for my Node server" and you'll have it in two minutes.
• pm2 — a friendlier Node-world alternative (pm2 start server.js, pm2 startup). Same effect, nicer commands.
• On a Mac mini: launchd (ask your agent for a plist), plus energy settings so the machine never sleeps.

Rule: if killing your process doesn't result in it running again within seconds without you touching anything, you're not done.

5. Knowing it's alive: health checks + logs

Give every service a /health route that returns 200 and something cheap (uptime, version). Then let a free uptime monitor (UptimeRobot and friends) ping it and email you when it stops answering — that's how you find out about the 4am crash at 8am instead of Thursday. Keep logs somewhere you can read them (journalctl -u yourservice on systemd). When a buyer says "it didn't work," logs are the difference between an answer and a shrug.

The pattern, end to end

Domain → Cloudflare DNS → tunnel (or Caddy on open ports) → your app on 127.0.0.1 → systemd keeping it alive → /health being watched. That's the entire production pattern my fleet runs on — every one of the services you see in my videos sits behind exactly this stack. It fits on an index card, it costs about $10/year plus the machine, and once you've done it once, every future service takes minutes to add.

Do this

Take your machine from Module 1 and get one "hello world" endpoint answering at https://api.yourdomain.com/health — with the process under systemd/pm2 so it survives a reboot. Hand your coding agent this exact module and say "help me do this on my setup." That one afternoon is 80% of everything infrastructure will ever ask of you.

Next module: the coding agents themselves — which ones exist, what they cost, and how to actually work with one without it wrecking your repo.

---

Disclosure: some links in this course are affiliate links (including Amazon). They help fund the free course — your price never changes, and every product here is one we'd recommend anyway.