Tuning Your VPS: Eight Things to Do After You Buy
A fresh VPS arrives bare: no swap, SSH still on password login, default file-handle limits. Do these eight and the box is actually usable.
8 min read · updated 2026-10-25
Order matters: security first, then performance
The order is: switch to SSH key login first, put the firewall up second, and only then tune performance.
The other way round, a mistyped SSH setting while you are adjusting kernel parameters locks you out of your own server — and at that moment you may not even have key login working yet.
The eight things
- Make a normal user, stop using root daily
adduser deploy and grant only what it needs sudo for. Do daily work as that user and use root only while setting things up.
- Switch SSH to keys and disable password login
Put your public key in ~/.ssh/authorized_keys, then set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config. Keep the current session open and verify a second terminal can log in before you close it.
- Turn on a firewall, open only what you need
On Debian or Ubuntu use ufw: allow OpenSSH first, then 80 and 443, then ufw default deny incoming && ufw enable. The order matters — enabling the default deny first locks you out.
- Add fail2ban (optional, recommended)
Public IPv4 addresses get scanned constantly. fail2ban bans repeat login failures automatically: apt install -y fail2ban && systemctl enable --now fail2ban.
- Turn on swap (especially below 2 GB RAM)
A 1 GB box running Docker runs out easily, and one OOM kill takes your services down with it. Use fallocate -l 1G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, then add /swapfile none swap sw 0 0 to /etc/fstab. Swap does not replace RAM; it only stops processes being OOM-killed.
- Raise the file-handle limit
The default 1024 is low for concurrent services. In /etc/security/limits.conf set * soft nofile 65535 and * hard nofile 65535, then verify with ulimit -n.
- Tune kernel parameters (BBR and friends)
Switch to a congestion control algorithm that tolerates packet loss: modprobe tcp_bbr && echo 'tcp_bbr' > /etc/modules-load.d/bbr.conf, then add net.core.default_qdisc = fq and net.ipv4.tcp_congestion_control = bbr to /etc/sysctl.conf. Note: BBR needs Linux 4.9 or newer and does not exist on very old images — check uname -r first.
- Clear logs and the apt cache when you are done
On a small disk the disk fills up with logs, not data. Use journalctl --vacuum-time=3d, rm -rf /var/lib/apt/lists/*, and configure log-opts (max-size 20m) in /etc/docker/daemon.json — otherwise container logs fill the root partition.
What not to do
Do not run one-click scripts blindly. Those scripts sed system files, rewrite firewall rules and change SSH configuration. You do not know what they changed, and if something breaks even rolling back is hard. If you cannot read it, do not run it.
Do not install a control panel as an optimisation. Panels like BT and 1Panel solve “easier management”, not “better performance”, and they eat memory of their own. On a 1 GB box, a panel often makes things slower than not having one.
Do not “optimise” things that are not yours to change. Tuning system parameters is your business; changing your datacenter’s upstream policy is not.
Common follow-ups
Is swap mandatory?
With more than 2 GB and no memory-hungry services you can skip it. Having it does no harm though: it makes processes slow under pressure instead of letting them be killed.
Is BBR always faster?
Not always. BBR usually holds up better on lossy links — which is normal for cross-border routes — but the difference is small on a clean link. Measure evening peak-hour loss first; if there is no loss, skip it.
How much does tuning actually gain?
Tuning stops you losing points to system defaults; it does not make the machine magically fast. The bottleneck on a cross-border link is in the network, and no server-side change fixes an upstream congestion.