Renting a VPS and securing it: domain, SSL and firewall basics

The weekend the laptop slept. Picture Maya. She runs a small online yoga studio, and last month she built an automation on her laptop. A form answer comes in, an agent qualifies the lead, then books a trial class. It worked beautifully until she closed the laptop for the weekend. By Monday, twelve customer messages were waiting with no reply. An automation that answers customers has to be awake when they are, and it needs a proper web address that's safe to share. That's today's job: renting a small server that never sleeps, giving it a name, and locking its doors.

What you will learn. By the end of this lesson you'll be able to do three things. First, rent a virtual private server and log in to it safely using a key instead of a password. Second, point a domain name you own at that server, so customers reach bookings dot your shop dot com instead of a string of numbers. Third, lock it down with a firewall and free SSL, the padlock in the browser. Think of it as a server, a name and a lock. Every later lesson in this module builds on these three.

What a VPS really is. So what are you actually renting? Start with the building. A hosting company owns huge physical computers in a data centre, and each one is split into many virtual machines. Now look at your flat. A VPS, short for virtual private server, is one of those flats: your own slice of memory, storage and processor, with your own operating system, and no neighbours walking through. And here's the key. You alone hold the way in, and you decide what runs inside. That's very different from shared hosting, where you only get a folder. With a VPS, the whole flat is yours to furnish.

Choosing a plan. Which size do you need? A vCPU is a share of the processor, the part that does the work. RAM is short-term memory, like the size of your desk: more room means more tools open at once. SSD is the storage drawer. For n8n, a database and a few agents calling cloud AI models, two vCPUs, four gigabytes of RAM and eighty gigabytes of storage is a comfortable start. Choose Ubuntu 24.04 LTS, where LTS means long-term support, so security fixes keep coming for years. Pick a region close to your customers, because a closer server means faster replies. Hetzner, DigitalOcean and Hostinger are well-known providers, and any of them works for this course. Don't overthink it: most providers let you resize later in a couple of clicks.

Giving the server a name with DNS. Your new server comes with an IP address, a number like 203 dot 0 dot 113 dot 10. It works, but nobody will remember it, and you can't put it on a business card. DNS, the domain name system, is the internet's phone book: it turns names into numbers. At the company where you bought your domain, you add an A record. Its name is bookings, and its value is your server's IP address. Now when a customer types bookings dot your shop dot com, their browser looks up the phone book and lands on your VPS. New records usually spread within minutes, though sometimes it takes a few hours.

First login with SSH keys. SSH, or secure shell, is a protected text connection from your laptop to the server. Watch the comment lines on screen: they tell you where each command runs. First, on your laptop, ssh-keygen makes a key pair. A key pair works like a lock and its only key: the public key is the lock you hand to the server, and the private key never leaves your laptop. Next, log in as root, the all-powerful admin. Let's slow down here. On the server, create an everyday user called maya and add her to the sudo group, which lets her borrow admin powers only when she asks. Type exit to come back to your laptop. There, ssh-copy-id asks for maya's password one last time and copies your public key to the server. Log in again, and no password is asked. After this, you never type a password to log in.

Closing the password door. A key only protects you once the old password door is shut. Still logged in as maya, these two lines write a small settings file for SSH: one turns off password login, the other stops root from logging in at all. It does the same job as editing the main settings file, sshd_config, but Ubuntu reads this small file first, so a setting left by your provider can't switch passwords back on. Then we restart SSH. Before you close anything, keep this window open and try a fresh login from a second window. If that new login fails, the open session is your way back in to fix it. Once it works, the bots that guess passwords have nothing left to guess.

The firewall: one door per job. A port is a numbered door on the server, and each service listens at its own door. A firewall is the doorman who decides which doors open at all. UFW, the uncomplicated firewall on Ubuntu, makes this easy. First we deny every incoming door by default. Then we open exactly three: SSH so you can log in, port 80 for plain web traffic, and port 443 for HTTPS, the encrypted web. Finally we switch it on. That's it. Thousands of automated bots scan every new server within hours, and now they find almost every door shut.

SSL in three lines with Caddy. SSL, now officially called TLS, encrypts everything between the customer and your server, so a card number or a phone number can't be read on the way. To do that, your server needs a certificate, a digital ID card proving it really is bookings dot your shop dot com. Here's the shortcut: Caddy, a small web server, fetches free certificates from Let's Encrypt and renews them by itself. To install it, follow the steps for Ubuntu on caddyserver dot com. Those three lines are the whole setup. Caddy acts as a reverse proxy, the receptionist at the front desk, passing each visitor to the room where n8n actually lives, on port 5678. n8n arrives in the next lesson, so until then, put respond Hello in place of the reverse proxy line and Caddy will show a simple page.

Worked example: one lead, end to end. Let's follow one real lead. Start with a visitor on her phone who wants a trial yoga class, plus the DNS phone book she'll ask first. Now look at everything inside the VPS: the firewall, Caddy, n8n and Postgres, the database that stores the leads. She presses the submit button. Her phone asks DNS for the address and gets the IP back. The request arrives encrypted on port 443, the firewall lets it through, and Caddy hands it to n8n through a webhook, an address n8n listens on for incoming form data. n8n saves the lead in the database, and the confirmation travels back the same way. Every hop was named, locked and filtered.

Common mistake: Docker skips your doorman. Here's the trap that catches experienced people. In the next lesson you'll install apps with Docker, and when Docker publishes a port, it writes its own network rules that can slip past UFW entirely. Your doorman guards the front, but the side window is wide open, and suddenly your customer database on port 5432 is reachable by anyone. The fix is simple. Publish internal ports on 127 dot 0 dot 0 dot 1, which means this machine only. In the ports line on screen, that address comes first, then the port twice: 127 dot 0 dot 0 dot 1, colon 5432, colon 5432. Then Caddy is the one service facing the internet, and everything else sits safely behind it.

Recap. Let's pull it together. A VPS is your own always-on slice of a big computer, so Maya's automations keep answering while she sleeps. A DNS A record turns its number into a name customers can trust, and SSH keys, with password and root login switched off, mean only your laptop can log in. Finally, a firewall keeps every door shut except SSH, 80 and 443, while Caddy adds free, self-renewing SSL and passes visitors to the right app. With those pieces in place, your server is ready for the real work, and the booking confirmations can flow day and night.

Your exercise. Now it's your turn. Before the next lesson, rent the smallest VPS that fits our plan, two vCPUs and four gigabytes of RAM. Make your key pair, create your own user, copy your SSH key across, and switch off password and root login. Then switch on UFW with only SSH, 80 and 443 open, and add an A record for a subdomain, something like automations dot your business dot com, pointing at the server. Finally, install Caddy using the steps on caddyserver dot com, and in your Caddyfile write respond Hello instead of the reverse proxy line. Open that address in your browser. When you see the padlock, you're done. Keep the IP address and login handy, because next time we install n8n.