Initial Server Setup Checklist After Buying a VPS (Ubuntu/CentOS)

A freshly provisioned VPS is a blank, exposed Linux box on the public internet — bots start probing it within minutes. Whether your provider handed you Ubuntu, Debian, or a CentOS-family distribution, the first thirty minutes are the same job: get it patched, lock down remote access, and put a floor under it before you install anything real. This checklist is the sequence we run on every new box. Work through it top to bottom and you will have a server that is patched, firewalled, and no longer accepting root password logins.

Before you start: pick the right OS (Ubuntu vs the CentOS family in 2026)

Two searches land people on this page — setup vps server ubuntu and centos vps setup — and the honest answer to the second one has changed. If you are spinning up a fresh server today, know what you are choosing:

• Ubuntu Server LTS is the safe default. Ubuntu 24.04 LTS receives standard security updates until 31 May 2029, extendable to 2034 with Ubuntu Pro and to 2036 with Legacy Support. It uses apt and ufw.
• CentOS Linux is discontinued. CentOS Linux 8 was retired on 31 December 2021 and CentOS Linux 7 reached end of life on 30 June 2024 — neither receives security patches anymore. If a provider still offers a "CentOS 7" image, do not build a production server on it.
• CentOS Stream is the surviving CentOS, a rolling upstream of Red Hat Enterprise Linux. CentOS Stream 9 is supported until roughly mid-2027, tracking the RHEL 9 lifecycle. For a stable, RHEL-compatible box that behaves like the old CentOS, most people now pick AlmaLinux or Rocky Linux instead — free, community-run, 1:1 binary rebuilds of RHEL.

Every "CentOS" command below (dnf, firewalld, the wheel group) applies unchanged to CentOS Stream, AlmaLinux, and Rocky Linux, so you can follow this guide on any of them. If you are still deciding, our guide on how to choose the right VPS plan covers sizing and OS trade-offs in more detail.

Distribution	Package manager / firewall	Supported until	Use it when
Ubuntu 24.04 LTS	apt / ufw	31 May 2029 (2034 with Pro)	Default choice; largest tutorial base
Debian 12	apt / ufw or nftables	~2028 (with LTS)	You want minimal, rock-stable
AlmaLinux / Rocky 9	dnf / firewalld	~2032 (tracks the RHEL 9 lifecycle)	You need a RHEL-compatible "CentOS"
CentOS Stream 9	dnf / firewalld	~mid-2027	You track RHEL's upstream
CentOS Linux 7 / 8	yum-dnf / firewalld	EOL — no patches	Never, for new builds

Step 1 — Update everything

Nothing else matters if the base image is months old. Bring every package current first.

Ubuntu / Debian:

apt update && apt upgrade -y

CentOS Stream / AlmaLinux / Rocky:

dnf upgrade -y

If the update pulled a new kernel, reboot so you are actually running it: reboot. The old kernel stays installed and bootable if the new one misbehaves.

Step 2 — Create a non-root user

Working as root full-time means one mistyped command can be unrecoverable, and every automated attack targets the root account by name. Create a normal user with sudo rights and use that instead.

Ubuntu / Debian (sudo lives in the sudo group):

adduser deploy
usermod -aG sudo deploy

CentOS family (sudo lives in the wheel group):

adduser deploy
passwd deploy
usermod -aG wheel deploy

Log out and back in as deploy, then confirm sudo whoami returns root before you go any further.

Step 3 — Harden SSH with keys

This is the single highest-value step on the list. Password logins are what the bots are guessing; key-based logins are effectively immune to brute force. Generate a key on your own machine, not the server:

ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id deploy@your-server-ip

Ed25519 is the modern default — short, fast, and cryptographically strong. Once you can log in as deploy with your key, edit /etc/ssh/sshd_config and set:

PermitRootLogin no
PasswordAuthentication no

Then restart the daemon — systemctl restart ssh on Ubuntu, systemctl restart sshd on the CentOS family. The edge case everyone hits: keep your current SSH session open and test a new login in a second terminal before you close the first. If the new session fails, you can fix the config in the still-open one. Lock yourself out with the only session and you are calling support for console access.

Step 4 — Configure the firewall

Default-deny everything, then open only the ports you actually serve.

Ubuntu (UFW):

ufw allow OpenSSH
ufw allow http
ufw allow https
ufw enable

CentOS family (firewalld):

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Only add HTTP/HTTPS if this box will serve web traffic. A database or app server that only talks to other private hosts should expose nothing but SSH.

Step 5 — Install fail2ban

fail2ban watches your logs and temporarily bans IPs that fail to log in repeatedly, thinning out the constant background noise of brute-force attempts.

Ubuntu: apt install fail2ban -y

CentOS family: dnf install epel-release -y && dnf install fail2ban -y, then systemctl enable --now fail2ban.

Out of the box, fail2ban's shipped defaults are maxretry = 5, findtime = 10m and bantime = 10m — five failures inside ten minutes earns a ten-minute ban. Those are deliberately gentle. Never edit jail.conf directly (a package update overwrites it); create /etc/fail2ban/jail.local and override there, for example a longer ban:

[sshd]
enabled = true
maxretry = 4
bantime  = 1h

fail2ban is a rate-limiter, not a lock. It reduces log noise and slows guessing; the actual security comes from Step 3. We go deeper on tuning jails in how to secure your VPS with a firewall, SSH hardening and fail2ban.

Step 6 — Set the timezone and enable NTP

Consistent, synchronised time makes logs from multiple servers actually correlate, and some TLS and authentication checks fail outright if the clock drifts. UTC is the sane default for servers regardless of where they physically sit.

timedatectl set-timezone UTC
timedatectl set-ntp true

Run timedatectl with no arguments to confirm "System clock synchronized: yes".

Step 7 — Add swap (small servers especially)

On a 1–2 GB VPS, a single memory spike can trigger the kernel's OOM killer and take down your application without warning. A swap file gives the kernel somewhere to spill before it starts killing processes. Create a 2 GB file:

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

How much swap? Red Hat's own guidance scales it to RAM: 2× RAM for systems up to 2 GB, equal to RAM between 2 and 8 GB, and at least 4 GB above 8 GB (hibernation needs considerably more — Red Hat suggests around 3× RAM at or below 2 GB, 2× between 2 and 8 GB, and RAM plus half again above that — though servers rarely hibernate). Swap is a safety net on cheap disks, not a substitute for real memory — if a box swaps constantly, size up the plan rather than the swap file. On fast NVMe VPS storage the penalty is far smaller than on the spinning disks those old ratios were written for.

Step 8 — Turn on automatic security updates

You will not log in every day to run apt upgrade. Let the machine patch its own critical vulnerabilities.

Ubuntu:

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

CentOS family:

dnf install dnf-automatic -y
systemctl enable --now dnf-automatic.timer

Scope it to security updates only. Fully automatic feature upgrades can restart services at awkward moments; security-only patching is the balance most single-server setups want.

Step 9 — Set the hostname and verify backups

Give the box an identity so it is obvious which server you are on:

hostnamectl set-hostname web01

Then the step people skip until it is too late: confirm you can restore, not just back up. If your provider offers snapshots, take one now and make sure you understand how to roll back to it. A backup you have never tested restoring is a hope, not a backup.

You are ready to build

That is the baseline. The server is patched, root password login is gone, the firewall is default-deny, fail2ban is thinning the noise, and unattended-upgrades keeps it current. From here you can install your application stack — a web server, database, or runtime — on a box that is already hard to knock over. If you are still weighing whether a VPS is the right tier at all, our comparison of shared hosting vs VPS is the place to start.

Sources

• CentOS end-of-life dates (CentOS Linux 7, 8 and Stream) (unknown)
• End dates are coming for CentOS Stream 8 and CentOS Linux 7 — Blog.CentOS.org (2023-04)
• What to know about CentOS Linux EOL — Red Hat (unknown)
• Getting started with swap — Red Hat Enterprise Linux 9 documentation (unknown)
• fail2ban default jail.conf (bantime, findtime, maxretry) (unknown)
• Ubuntu release and end-of-support dates (unknown)
• AlmaLinux release lifecycle — endoflife.date (2026)
• Debian release lifecycle — endoflife.date (2026)
• CentOS Stream lifecycle — endoflife.date (2026)

Frequently asked questions