Secure a new Hostinger VPS: the 10-minute checklist

Why do this first

A new server with a public IP gets automated SSH login attempts within minutes of booting. That isn't aimed at you; bots scan the whole IPv4 range all day. The steps below shut out nearly all of that noise and take about ten minutes.

Do them in order, and keep your current SSH session open until the end. If a change locks you out, the open session is how you undo it.

1. Update everything

OS templates are built ahead of time, so a fresh server is usually a few patches behind.

apt update && apt full-upgrade -y
reboot   # if a new kernel was installed

2. Create a non-root user with your SSH key

Day-to-day work happens as a normal user with sudo. If you added an SSH key when you created the VPS, it's in root's `authorized_keys`; copy it across.

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy/

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id deploy@YOUR_SERVER_IP

3. Turn off root and password logins

On Ubuntu 24.04, put your settings in a drop-in file instead of editing `sshd_config`. One detail catches people out: for each setting, sshd uses the first value it reads, and drop-ins load in alphabetical order. Cloud images often ship a `50-cloud-init.conf` that turns password login on, so name your file with a lower number so it's read first.

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF

sudo sshd -t                  # syntax check, prints nothing when OK
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
sudo systemctl restart ssh

4. Firewall: allow only what you serve

UFW is the simplest firewall on Ubuntu. Allow SSH before enabling it, then open web ports. Hostinger also has a network firewall in hPanel's VPS settings; using both is fine, and the hPanel one blocks traffic before it ever reaches your server.

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 --force enable
sudo ufw status verbose

5. Fail2ban for repeated failed logins

With password logins off, brute force can't succeed, but Fail2ban still keeps your logs readable and blocks noisy scanners. The default SSH jail is enough.

sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

6. Automatic security updates

Unattended-upgrades installs security patches every day without touching anything else. Most Ubuntu images have it already; this makes sure it's on.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades   # choose "Yes"

7. Snapshots and real backups

Take a snapshot in hPanel now that the server is clean, and again before any risky upgrade. Restoring takes minutes.

A snapshot isn't an off-site backup, though. Dump your database on a schedule and copy it somewhere else, such as object storage or another machine, so one account problem can't take out both the server and its backup.

• •Snapshot before major upgrades or config changes.
• •Nightly database dump with a cron job, kept off the server.
• •Test a restore once. A backup you've never restored is a guess.

Quick checklist

Print this, or keep it in your repo's README:

• •System fully updated
• •Non-root sudo user with SSH key
• •Root login and password login disabled, tested in a new session
• •UFW on: only 22, 80 and 443 open
• •Docker ports published to 127.0.0.1 only
• •Fail2ban running
• •Unattended security upgrades on
• •Clean snapshot taken; off-server database backups scheduled

• Point your domain at the server →
• Deploy a Next.js app on it →
• Set up push-to-deploy with GitHub Actions →