How to Set Up Your Own VPS Hosting (and Actually Secure It)

Every one of our own products — this site included — runs on a VPS we manage ourselves rather than a managed platform-as-a-service. That scares a lot of people off, and reasonably so: "server" sounds like something that requires a computer science degree to touch safely. It doesn't. A VPS is just a computer someone else keeps switched on and connected to the internet, that you get to log into. The setup below is the same handful of steps we run on every new box, and it takes about 20 minutes once you've done it once.

What a VPS actually is (and when you don't need one)

A VPS (virtual private server) is a slice of a physical machine in a data centre, rented to you as your own private Linux box with root access. That's different from shared hosting (where you don't get real server access) and different from a platform like Vercel or Render (where someone else manages the server for you, for a price, in exchange for less control).

You want a VPS when you're running your own Docker containers, a database, or anything that doesn't fit neatly into a managed platform's pricing model. You don't need one if a managed platform already does what you need — there's no prize for self-hosting something that would take five minutes on someone else's infrastructure. Be honest with yourself about which camp you're in before you start.

Step 1: Pick a provider

For a first VPS, we point people at Hostinger — it's what we run our own stack on. The KVM 1 plan is enough to follow along with everything below; if you end up running several Docker containers side by side, KVM 2 gives you more headroom. If you're planning to host a whole portfolio of sites and services on one box the way we do, jump straight to KVM 4 instead of upgrading later. All three come with a one-click Ubuntu image and a control panel that doesn't get in the way once you're comfortable on the command line.

If data residency matters to you — you're handling Australian customer data and want it to legally stay onshore, or your customers are AU-based and you want the latency win — an Australia-based host is worth the extra cost once you're past the "just get something live" stage. Binary Lane is the one we'd look at first: data centres in Sydney, Melbourne, Perth, and Brisbane, straightforward Docker support, and a solid reputation among Australian developers (it comes up favourably on Whirlpool, which is the forum Australians actually trust for this). Crucial is a reasonable second option, Sydney-based and aimed at the same developer audience. Neither is necessary on day one — get comfortable on a cheap box first, migrate later if data sovereignty becomes a real requirement rather than a nice-to-have.

Step 2: Get in, and immediately stop being root

You'll get root SSH access on day one. The first thing to do is stop using it. Running everything as root means one mistake — a bad rm, a compromised script — has no safety net.

# as root, create a new user and give it sudo rights
adduser yourname
usermod -aG sudo yourname

Log out, log back in as yourname, and do everything from here on with sudo in front of anything that needs root.

Step 3: SSH keys, not passwords

Password-based SSH login is the single biggest reason random VPSes get compromised — bots scan the entire internet for port 22 and brute-force common passwords all day, every day. Switch to key-based auth before you do anything else public-facing.

On your own machine (not the server):

ssh-keygen -t ed25519 -C "yourname@yourserver"
ssh-copy-id yourname@your-server-ip

Then on the server, edit /etc/ssh/sshd_config and set:

PasswordAuthentication no
PermitRootLogin no

Restart SSH (sudo systemctl restart sshd) and test logging in from a new terminal window before you close your current session — if something's wrong with the key setup, you want to still be logged in to fix it, not locked out.

Step 4: A firewall — only open what you actually use

ufw (uncomplicated firewall) ships on most distros and is genuinely simple to use. The rule of thumb: deny everything by default, then explicitly allow only the ports you need.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

That's SSH, HTTP, and HTTPS — enough to run a web app behind a reverse proxy. Don't open a port "just in case." Every open port is one more thing that has to stay secure forever.

Step 5: Fail2ban and automatic updates

Two more five-minute jobs that quietly do a lot of work. fail2ban watches auth logs and temporarily bans IPs that fail login too many times — useful even with key-only SSH, since it also covers other services you might add later.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

And unattended security updates, so you're not the last one to know about a critical patch:

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

Step 6: Docker, and a reverse proxy for SSL

This is the point where the server starts being useful. We run everything as Docker containers, and we put Nginx Proxy Manager in front of them — it's a small web UI that handles reverse proxying and Let's Encrypt SSL certificates without hand-editing nginx config every time you add a new domain.

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker yourname

Point your domain's DNS at the server's IP, add it as a proxy host in Nginx Proxy Manager, tick "request a new SSL certificate," and you have a real HTTPS site in a couple of minutes — no separate certificate wrangling.

Where this breaks

Being honest: this is real, ongoing responsibility, not a one-time setup you forget about. Security patches, disk space filling up, a container that quietly stops restarting after a crash, a certificate that doesn't auto-renew the way you assumed — someone has to notice these things. For a single side project that's a manageable trade against the cost saving. For something a business actually depends on, "someone has to notice these things" becomes a real operational cost, and it's worth being honest with yourself about whether that someone is actually going to be you at 11pm on a Sunday.

Practical next step

Spin up a KVM 1 box on Hostinger, work through steps 2–5 in order — user, keys, firewall, fail2ban — before you install anything else. That's the part that actually matters for security; everything after it is just software. If you get through that and decide you'd rather not be the one getting paged when it breaks, that's exactly what our AI infrastructure service line is for.