Give your project a name, and lock the door with HTTPS

Right now, your project only exists on your server — you're the only one who can see it. In this module, you'll give it a real name, point that name at your server, and put a friendly "security guard" in front of it. When you're done, anyone on Earth can visit your project, safely, just by typing a web address.

Buying a domain

A domain is the friendly name people type instead of a long string of numbers — think example.com. Nobody wants to remember your server's real address, so a domain is like giving your building a nice street name instead of just GPS coordinates.

You buy a domain from a company called a registrar. Popular, beginner-friendly options include Namecheap, Cloudflare, and Porkbun. Pick one, search for a name you like, and if it's free, pay for it. That's genuinely the whole process — a few clicks, and it's yours.

Pointing the domain at your server

Buying the domain doesn't connect it to anything yet — right now it's just a name sitting on a shelf. To connect it, you use DNS, which is short for Domain Name System. Think of DNS as the internet's phone book: you look up a name, and it hands back the actual number (the IP address) to call.

Inside your registrar's dashboard, you'll find a "DNS" or "DNS records" page. You need to add an A record — a simple instruction that says "this name points to this IP address." You'll add two of them, both pointing at your server's IP address from Module 2:

• Type: A  ·  Name: @ (this means "the bare domain," like yourdomain.com)  ·  Value: your server's IP address
• Type: A  ·  Name: www  ·  Value: the same IP address

That second one just makes sure www.yourdomain.com works too, in case someone types the "www" out of habit. Save both records, and you're done with this part.

Why you need a reverse proxy

Here's a wrinkle: your app from Module 7 is quietly running on a specific "door" of your server, called a port — something like port 3000. But visitors typing your domain arrive at the server's main doors, ports 80 and 443, which are the standard doors web browsers always knock on. Nothing is standing there to greet them and walk them over to port 3000.

That's the job of a reverse proxy. Picture a receptionist at the front desk of an office building. Visitors walk in the main entrance; the receptionist quietly checks who they're here for and walks them back to the right office — in our case, your app on port 3000. The receptionist also checks everyone's ID at the door, which is the security part we're about to get for free.

We'll use Caddy as our reverse proxy. Caddy is popular with beginners because it sets up the security padlock (HTTPS) automatically, with almost no configuration.

Installing and configuring Caddy

These are the official install commands from caddyserver.com — always check that site for the very latest version if something here looks out of date. Run them one at a time on your server.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

The first line lets your server trust and download software from Caddy's site. The next two add Caddy's official "shop" to your list of trusted sources. Then apt update refreshes that list, and apt install caddy actually installs it. Once that finishes, Caddy is running in the background, ready to be told what to do.

Writing your Caddyfile

Caddy's instructions live in one plain text file called the Caddyfile. Open it with the same friendly editor you've used before:

sudo nano /etc/caddy/Caddyfile

Delete whatever is already in there, and replace it with this — swapping in your real domain and your app's real port:

yourdomain.com {
    reverse_proxy localhost:3000
}

In plain English, this says: "When someone visits yourdomain.com, quietly forward them to whatever is running on port 3000." Change yourdomain.com to the domain you bought, and change 3000 to whatever port your app actually uses. Save the file (in nano, that's Ctrl+O, then Enter, then Ctrl+X to exit).

Now tell Caddy to pick up the new instructions:

sudo systemctl reload caddy

Here's the magic part: the moment Caddy sees your real domain in that file, it automatically reaches out to Let's Encrypt and requests a free HTTPS certificate for you. No extra commands, no fiddly settings — and Caddy quietly renews that certificate forever, before it ever expires. That's the padlock in the browser bar, handled entirely for you.

✏️ Hands-on: go live

Time to put it all together. Work through these in order.

1. Buy a domain

   Pick a registrar (Namecheap, Cloudflare, or Porkbun all work well), search for a name, and buy it.

2. Add your two A records

   In your registrar's DNS settings, add an A record for @ and one for www, both pointing at your server's IP.

3. Make sure your app is running

   Confirm the project you built in Module 7 is still up and listening on its port.

4. Install Caddy

   Run the five install commands above on your server.

5. Write your Caddyfile

   Open /etc/caddy/Caddyfile and add your domain and port, exactly like the example above.

6. Reload Caddy

   Run sudo systemctl reload caddy so it picks up your new settings and fetches your certificate.

7. Wait a minute, then visit your site

   Open https://yourdomain.com in a browser and look for the padlock. If you see it, congratulations — your project is live and secure, reachable by anyone on Earth.