First Steps After Getting a VPS: A Practical Setup Checklist

A freshly delivered VPS is a blank Linux machine with a public IP address, and automated scanners will find it within minutes. Nothing about that is dramatic, but it means the first hour matters. This checklist walks through the steps in a sensible order, using Ubuntu or Debian commands. If you run a Red Hat style distribution such as AlmaLinux or Rocky Linux, the ideas are identical and only the package manager changes (dnf instead of apt).

1. Log in and update everything

Your provider will give you an IP address and initial credentials. Connect as root once, from your own computer:

ssh [email protected]

Replace the example address with your own. Then bring the system up to date before installing anything else:

apt update
apt upgrade

If the upgrade installs a new kernel, reboot with reboot and reconnect. Old images often ship with packages that are several months behind, so this step closes known vulnerabilities straight away.

2. Create a normal user with sudo

Working as root all day is risky: one mistyped command has no safety net. Create a regular account and give it administrative rights through sudo:

adduser deploy
usermod -aG sudo deploy

On Red Hat style systems the group is called wheel rather than sudo. Pick any username you like; "deploy" is just a convention.

3. Set up SSH key login

Passwords can be guessed, keys effectively cannot. From your local machine, create a key pair if you do not already have one, then copy the public half to the server:

ssh-keygen -t ed25519 -C "my-laptop"
ssh-copy-id [email protected]

Open a second terminal and confirm that ssh [email protected] logs you in without a password and that sudo -v works. Do not close your original session until this test passes. The knowledge base has more help if a connection does not behave.

4. Lock down SSH

Once key login works, tighten the SSH daemon. Edit /etc/ssh/sshd_config (or add a file under /etc/ssh/sshd_config.d/) and set:

PermitRootLogin no
PasswordAuthentication no

Validate and reload, keeping your existing session open as a lifeline:

sudo sshd -t
sudo systemctl reload ssh

On Red Hat style systems the service is named sshd. If the test command prints nothing, the syntax is fine. Open a new connection to confirm you can still get in before you log out.

5. Turn on a firewall and automatic updates

Firewall

A default install may expose services you did not intend to. On Ubuntu, ufw keeps this simple. Allow SSH first, otherwise you will lock yourself out:

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

Only open ports for services you actually run. Anything else stays closed by default.

Automatic security updates

On Debian and Ubuntu the unattended-upgrades package installs security patches automatically:

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

This does not replace regular maintenance, but it means a critical patch does not wait for you to remember.

6. Housekeeping worth doing early

• Hostname and time: set a meaningful hostname with hostnamectl set-hostname and check the timezone with timedatectl. Logs with the wrong time are painful to debug later.
• Backups: decide now how you will back up, not after the first incident. A copy that lives only on the same server is not a backup.
• Documentation: keep a short text file noting what you installed and why. Future you will be grateful.
• Disk and listening ports: run df -h to see how much disk space you have, and sudo ss -tulpn to list every service listening for connections. If you see something you did not install on purpose, find out what it is before going further.
• Provider details: note where the provider's emergency console or rescue mode is, so you have a way in if an SSH change goes wrong.
• Swap and sizing: small servers often have no swap. Check with free -h and read up on swap before the first out-of-memory surprise.

What comes next. With the basics done, the server is ready for a role. Install a web server such as Nginx, a runtime for your app, and a database if you need one, and add monitoring so you hear about problems before your visitors do. Resist the urge to install tools "just in case"; every extra service is one more thing to patch.

A good habit is to repeat the same first-hour routine on every server so that nothing is left to memory. Write it as a script or a short runbook, and your second server will take ten minutes instead of an hour. Configuration tools such as Ansible can later automate the same steps, but doing them by hand once is the best way to understand what each one protects you from.

Mistakes to avoid in the first hour

Do not disable the firewall "just for a moment" and forget about it, do not leave sample applications or default pages running, and do not install a control panel, a mail server and three language runtimes in one sitting on a small machine. Make one change at a time, test it, and write it down. For a broader view of protecting a server and the sites on it, see our security page.

Getting a VPS from Zebra Hosting

Zebra Hosting delivers VPS servers within 24 hours of payment, and support is available in 17 languages if you get stuck on a first-time setup. See the VPS plans.