DeployEasy
VPSBeginner

What to Do After Buying an Ubuntu VPS: 20 Production Setup Steps

A practical Ubuntu VPS checklist covering a sudo user, SSH keys, UFW, security updates, swap, backups, monitoring, and final checks before deployment.

· 3 min read· 569 words
Table of contents

Buying a new Ubuntu VPS is only the beginning. Before deploying an application, create a repeatable baseline for access, updates, firewall rules, memory, backups, and observability.

This checklist assumes Ubuntu 22.04 or 24.04 and a fresh server. Replace the example IP address with your own.

1. Create a normal sudo user

Connect once with the provider account, then create a dedicated deployment user:

adduser deploy
usermod -aG sudo deploy

Use this account for everyday work. Keep root access for recovery only.

2. Install an SSH key

On your computer, create an Ed25519 key if necessary:

ssh-keygen -t ed25519 -C "deployeasy-vps"

Copy the public key to /home/deploy/.ssh/authorized_keys, then test a second terminal before changing SSH settings. Never copy the private key to the server.

3. Update Ubuntu and configure the timezone

apt update
apt upgrade -y
apt autoremove -y
timedatectl set-timezone Asia/Ho_Chi_Minh

Reboot after kernel updates and reconnect with the deployment user.

4. Enable UFW

Allow SSH before enabling the firewall:

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

Do not expose PostgreSQL, Redis, or internal application ports publicly unless there is a deliberate reason.

5. Harden SSH carefully

After key login works, review /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validate before reloading and keep the original session open:

sshd -t
systemctl reload ssh

6. Add brute-force protection

apt install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status sshd

Fail2ban is an additional layer, not a replacement for keys, updates, and a firewall.

7. Check RAM, swap, disk, and inodes

free -h
swapon --show
df -h
df -i

Small VPS instances can fail during Docker or Node.js builds. If the provider supplies no swap, a basic 2 GB swap file is often useful:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Swap reduces short memory spikes; it does not replace sufficient RAM.

8. Install only required software

apt install -y ca-certificates curl git jq nginx

Keep application data outside disposable image layers. Store uploads and database data in managed volumes or a backup destination.

9. Configure logs and time synchronization

journalctl --disk-usage
timedatectl status

Configure Docker log rotation or journald limits so a noisy service cannot fill the disk. Correct timestamps make incident investigation much easier.

10. Prepare operations before launch

Before production traffic, have all of the following:

  • a database and upload backup schedule;
  • a tested restore procedure;
  • a lightweight /health endpoint;
  • Nginx in front of the application;
  • HTTPS with automatic certificate renewal;
  • a documented deployment and rollback command;
  • monitoring for availability, errors, RAM, disk, and certificate expiry.

Final review

Open a fresh SSH session and verify key login. Confirm that UFW exposes only required ports, application ports remain private, backups can be restored, logs are searchable, and another person can deploy or roll back without guessing.

Should every VPS have swap?

Not necessarily. Swap can help a small instance survive a short memory spike, but sustained swapping means the workload needs tuning or more RAM.

Is disabling root login enough?

No. Use a non-root sudo account, SSH keys, firewall rules, updates, backups, and tested recovery access together.

Continue reading