← Writing
Tutorial
July 4, 2026 · 5 min read22

Handling SSL, Domains, and Production Servers: The Grown-Up Guide to Going Live

Buying a domain, pointing DNS at your server, and slapping on a padlock can feel like dark magic the first time. It isn't! Here's a friendly, hands-on tour of domains, DNS records, SSL certificates, and hardening a production server so your app goes live safely and stays that way.

Abdulboriy Malikov

The Grown-Up Guide to Going Live

You've built something great and it runs beautifully on a server somewhere. But right now, reaching it means typing an ugly IP address like 203.0.113.42 into the browser, and there's no reassuring padlock in sight. Not exactly the confidence-inspiring experience you want for real users.

In this guide we'll cover the three pillars of shipping a real production site: getting a domain and wiring up DNS, locking everything down with SSL, and hardening the server so it doesn't fall over the moment the internet notices it exists. Grab a coffee, this is the fun part.

Part 1: Domains and the Magic of DNS

A domain name is just a friendly human-readable label that points to a not-so-friendly IP address. yoursite.com is way easier to remember than a string of numbers. You rent one from a registrar (Namecheap, Cloudflare, Google Domains, and friends), usually for a modest yearly fee.

The real magic happens in DNS, the internet's giant phone book. When someone types your domain, DNS translates it into your server's IP address so the browser knows where to knock. You control this with a handful of record types.

The DNS Records You Actually Need

Don't let the alphabet soup scare you. For most sites, you only care about a few records:

A      yoursite.com        ->  203.0.113.42     (points root domain to server IP)
A      www.yoursite.com    ->  203.0.113.42     (points www to the same IP)
CNAME  api.yoursite.com    ->  yoursite.com     (alias for a subdomain)

An A record maps a name directly to an IPv4 address, a CNAME points one name at another name, and if you send email you'll eventually meet MX and TXT records too. Set your A record for both the root and www, and you're 90% of the way there.

One gotcha that trips up everyone: DNS changes aren't instant. They're cached according to a value called TTL (time to live), so a change can take anywhere from a few minutes to a day to spread everywhere. If your new domain isn't resolving yet, grab a snack and check again shortly. It's almost never actually broken.

Part 2: SSL and That Beloved Padlock

SSL (technically TLS these days) is what turns http:// into https:// and puts the little padlock in the address bar. It encrypts the traffic between your users and your server so nobody snooping on the network can read passwords, tokens, or that embarrassing thing they just searched for.

In the old days SSL certificates cost real money and involved emailing PDFs to a certificate authority. Today, Let's Encrypt hands out trusted certificates for free, and a tool called Certbot automates the whole dance. There is genuinely no excuse to run without HTTPS anymore.

Getting a Certificate with Certbot

Assuming Nginx is already serving your domain, installing SSL is basically two commands:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yoursite.com -d www.yoursite.com

Certbot verifies you actually control the domain, fetches a certificate, edits your Nginx config to serve HTTPS, and offers to redirect all HTTP traffic to HTTPS automatically. Say yes to that. Refresh your site and admire the padlock: you did that.

Never Let It Expire

Let's Encrypt certificates last 90 days, which sounds scary until you realize Certbot sets up automatic renewal for you. You can prove it works with a dry run:

sudo certbot renew --dry-run

If that runs cleanly, you can forget certificates exist. No more 2 AM alerts about an expired padlock scaring your users away.

Part 3: Hardening Your Production Server

A fresh server is like an unlocked house with the address posted online. Bots start knocking within minutes. Let's put some locks on the doors without turning this into a full security course.

Set Up a Firewall

On Ubuntu, ufw makes firewalls approachable. Allow only what you need: SSH so you can log in, plus HTTP and HTTPS for your site.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Notice we never open your app's raw port (like 3000) to the world. The only way in is through Nginx on 80 and 443. Your Node app stays safely tucked behind the reverse proxy.

Lock Down SSH

Password logins are a magnet for brute-force bots. Switch to key-based authentication and disable password logins entirely. Once your SSH key works, edit the SSH config:

# in /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no

Then reload SSH with sudo systemctl reload ssh. Just be absolutely sure your key works before you disable passwords, unless you enjoy the special thrill of locking yourself out of your own server.

Keep the System Patched

Security holes get patched constantly, but only if you actually install the updates. Enable unattended upgrades so critical fixes land automatically:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Now your server quietly patches itself while you sleep. Combined with the firewall and locked-down SSH, you've cut off the vast majority of drive-by attacks with maybe ten minutes of effort.

The Grand Recap

Here's everything you wired together to go from raw IP address to a real, trustworthy production site:

Domain + DNS gives you a friendly name: an A record points your domain at your server's IP, with a little TTL patience while it propagates.

SSL via Certbot delivers free, auto-renewing HTTPS, so every connection is encrypted and that trusty padlock shows up.

A firewall with ufw keeps only SSH, HTTP, and HTTPS open, so your app's raw port stays private behind Nginx.

Hardened SSH plus auto-updates means key-only logins and hands-off security patches while you sleep.

You're Live and You're Legit

That's the whole journey from a scary bare IP to a proper production site with a real name, a padlock users trust, and a server that shrugs off the constant background noise of the internet. None of it was magic, just a handful of well-chosen commands. Now share that clean https://yoursite.com link with pride, and go build the next thing.