Choosing the box and the name
With the architecture decided, the next step was renting the server and — separately — deciding whether to put a domain name in front of it. Two decisions, in that order, because you need the box before a name has anything to point at, and because some builds never need the name at all.
This is what I chose and why.
Before you spend anything: practise on hardware you already own
If the Linux side of this is unfamiliar, you don’t need a VPS to start learning. An old laptop or desktop with Ubuntu Server on it gives you the same command line, SSH, package manager, and Nginx — for free, on hardware you already have. The early steps — getting comfortable at the terminal, running a web server, breaking things and fixing them — can all be practised on a spare machine on your own LAN with nothing exposed to the internet.
What an old PC can’t be is the hub of this architecture: it’s behind your home boundary, not an always-on public box in a datacentre, so it doesn’t give you the stable public address the design depends on. Learn the skills on it first, then rent the box when you want the public presence.
Choosing the provider
I used a local Australian VPS provider with a datacentre close to home. The main reason was location — for a box I administer over SSH daily and route my own traffic through, a nearby datacentre keeps latency low, and almost all of this build’s traffic originates close to home anyway.
The second reason was that it’s an unmanaged VPS. The provider supplies the hardware and an initial Ubuntu image and nothing above that — everything on top is mine. In practice that means their helpdesk supports the infrastructure (hardware, virtualisation, networking, base OS images) but not the software you install; you’re the administrator, and the server’s software is yours to fix when it breaks. That’s the right split for this project.
Choosing the plan — buy less than you think
I started on a larger plan than I needed — 2 GB RAM, more storage and transfer — on the logic that headroom is good. Once the box had run real workloads for a while and I could see what it actually used, I downgraded to the entry-level tier: 1 vCPU, 1 GB RAM, 20 GB storage, 1000 GB transfer — about the price of a coffee a month, and half what I’d been paying. It’s been adequate for Nginx, the speed test, and WireGuard ever since.
The lesson: buy for what you’re running now, not for what you might run later. You can resize once you have real usage data, and resizing down is straightforward (though it usually needs a reboot, so plan it rather than doing it live). RAM is usually the first resource you’ll hit — the swap file that softens a memory spike is covered in the next section.
For the OS I used Ubuntu 24.04 LTS: LTS gives years of security updates without a version chase, and Ubuntu has large documentation and community support, so searching an error usually turns up your exact case.
Then the name: do you even need one?
With the box running at its raw IP, the second decision: a domain, or not?
For a lot of uses the IP alone is enough — a VPN hub, a tool behind a login, anything you reach by bookmark. The one real friction is trusted SSL: free certificate authorities such as Let’s Encrypt issue certificates for domain names rather than public IP addresses, so IP-only usually means a self-signed certificate and a one-time “trust this” rather than a clean padlock.
CGNAT doesn’t change this either way, though it’s easy to assume it does. Being behind CGNAT is what makes the VPS worth having — with no public address at home, there’s nothing to point a hostname at and nothing to forward a port to. But that’s an argument for the box, not for the name: the VPS gives you a stable public address whatever your home connection is doing, and you can use it by IP alone. So the domain question stays exactly where it was — optional.
I wanted a name, for trusted SSL and because the address should outlive any single box — re-point the name at a new server and everything referring to it still works.
Choosing and registering the name
The usual advice is to keep the name short. I didn’t — I chose one that meant something to me over a shorter, more cryptic option, which I’d do again. Worth keeping either way: avoid hyphens and numbers where you can, and pick something you won’t mind typing for years.
I chose a .app domain, partly because it reads cleanly and partly because .app is on browsers’ HSTS preload lists, so browsers require HTTPS for every .app site — which pushes you toward doing SSL properly from the start.
One thing I’d do again: register the domain with a well-known international registrar, separate from your VPS provider. Keeping the name and the box at different companies means you can change either without touching the other, and avoids handing one vendor control of both. Look for honest pricing (watch for a cheap first year that jumps on renewal) and DNS management included.
With the box rented and the name registered, there’s a server in a datacentre that isn’t secured yet. The next section is taking control of it — the first SSH login, locking down access, and the early hardening that turns a fresh public box into one you can leave running on the internet.