Deployment GuideUpdated August 22, 2026

first 30 minutes

New VPS Security Checklist

A first-day Ubuntu hardening checklist covering updates, SSH keys, firewall rules, logs and recovery access.

Hardening a new VPS is a sequence, not a single command. First make sure you have a second way back in, then update the system, create a non-root admin, install an SSH key, reduce exposed ports and only afterwards disable password or root login. The order matters because a rushed SSH edit can lock you out of your own server.

Why this matters

A newly created VPS can be scanned within minutes, long before your application is ready. Security work does not need an expensive plan, but it does benefit from provider features such as a recovery console, firewall and snapshots. I would choose those recovery features over a slightly cheaper server with no way back in after a bad SSH or firewall change.

VPS requirements

Buy for the workload, not the install command

Find a matching VPS
MinimumAny supported Ubuntu VPS

The checklist itself needs no extra CPU. Keep enough RAM for updates and the service you plan to run.

Recommended2 vCPU / 2-4 GB RAM + web console

A practical base for Docker or a small web stack, with recovery access and snapshots.

Heavy workloadWorkload-sized plan + external monitoring

Production services need off-server backups, alerts and a tested incident path, not just more cores.

Compare VPS plansBrowse current deals

The first 30 minutes, in the right order

00-05 minRecovery access

Confirm the provider console works and keep the first SSH session open.

05-12 minUpdates + sudo user

Patch Ubuntu, create the non-root admin and install the SSH key.

12-20 minFirewall

Allow SSH first, then expose only the ports the application really needs.

20-26 minSSH policy

Test the second login before disabling root and password authentication.

26-30 minBackup baseline

Create the first off-server backup target and record a recovery path.

Before touching the server

  • A fresh Ubuntu VPS and an active SSH session
  • A local SSH key pair and a tested second terminal
  • The ports your application will actually need

Apply the checklist without locking yourself out

01

Update and create an admin user

Keep your current root session open while testing the new account. Give the account sudo access and add your public key before changing SSH policy.

apt update && apt full-upgrade -y
adduser deploy
usermod -aG sudo deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
02

Configure the firewall conservatively

Allow SSH first, then the web ports required by your reverse proxy. Do not expose databases, Docker APIs or internal application ports to the whole internet.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
03

Test the new SSH path

Open a second terminal and log in as deploy using the key. Only after that works should you change root or password authentication.

ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP
sudo -v
sudo sshd -t
04

Disable password and direct root login

Use a drop-in file so the change is easy to audit. Keep the original root session open until the new policy has been tested from another network.

sudo tee /etc/ssh/sshd_config.d/hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
sudo sshd -t
sudo systemctl reload ssh
05

Add monitoring and maintenance

Enable unattended security updates where appropriate, review authentication logs and install Fail2Ban only after understanding which SSH port and log format you use. Hardening is not a substitute for backups or application updates.

Things not to do

  • Closing the original root session before confirming key login in a second terminal
  • Disabling passwords before the new user's authorized_keys file and permissions are correct
  • Opening every Docker or database port because the application documentation lists it
  • Changing the SSH port and assuming that alone prevents compromise
  • Treating provider snapshots as the only backup and never testing a restore

Before deploying an application

A second SSH session works as the non-root user
ufw status shows only required ports
sshd -t returns without an error
The application remains reachable after the firewall is enabled

Next step

Keep the deployment moving

Sources and further reading

Commands assume a fresh Ubuntu server. Replace domains, users, database names and provider-specific values before running them. VPS sizing is a practical starting point, not a guarantee: monitor the real workload and resize when CPU, memory, disk or network headroom becomes tight.