Spinning up your first VPS is less intimidating than it looks. A virtual private server gives you a guaranteed slice of a machine with root access, which means you control the whole software stack — and also that the setup and security are now yours to handle. The work breaks down into four predictable stages: size the server, choose an operating system, connect to it securely, and do a short list of first-boot tasks before you install anything else.
This guide walks through that path without favoring any provider. The short version: start small because resizing up is easy, pick a mainstream Linux distribution so help is plentiful, log in with an SSH key rather than a password, and harden the box on the first boot — before it's exposed to traffic.
Before you provision: what a VPS gives you
A VPS sits between shared hosting and a dedicated server. Virtualization carves a physical machine into isolated instances, each with a reserved amount of CPU, memory, and storage that's yours alone. Unlike shared hosting, a neighbor's traffic spike can't starve your resources, and you get root — full administrative control. If you're still deciding whether a VPS is even the right tier versus shared, dedicated, or cloud, our web hosting comparison lays out the trade-offs; this guide assumes you've landed on a VPS and want to set it up well.
The thing to internalize before you start: with root access, nothing is maintained for you. Updates, security, and configuration are your responsibility on an unmanaged VPS. That's the price of control, and the rest of this guide is about handling it sensibly.
Step 1: Size the server (start small)
The most common first mistake is over-provisioning. People pick a large plan "to be safe" and pay for idle capacity for months. Because resizing a VPS up is usually quick, the better default is to start on a small plan and scale when your own metrics show you're constrained.
Match the basic resources to your workload:
- CPU and RAM — a small site, API, or staging box runs comfortably on modest resources. Memory is usually the first thing you run short of, so watch it before CPU.
- Storage — favor SSD/NVMe storage for responsiveness. Estimate your data plus room to grow, not a worst-case guess.
- Bandwidth — check the monthly transfer allowance against realistic traffic so you aren't surprised by overage.
- Location — choose a data-center region close to your users to lower latency. This costs nothing to get right and is annoying to change later.
The rule: provision for today's load plus a little headroom, then resize when monitoring tells you to. Under-provisioning is a five-minute fix; chronic over-provisioning is money you don't get back.
Step 2: Choose a Linux distribution
For a first server, pick a mainstream, well-documented Linux distribution. The reason is practical, not ideological: when something breaks, a popular distro means the answer is already on a forum or in the docs. Two reliable families cover most needs:
- Ubuntu LTS / Debian — huge community, long-term support releases, and the largest pool of tutorials. A safe default for most projects.
- Rocky Linux / AlmaLinux — enterprise-compatible (RHEL-style), a good fit if your team or stack is built around that ecosystem.
Choose an LTS (long-term support) release rather than the newest version. LTS gets security updates for years, which is exactly what a server needs. Bleeding-edge releases buy features you rarely need on a server in exchange for shorter support and more churn. Avoid distributions you've never used for your first box — learning the server and an unfamiliar OS at once makes every problem harder.
Step 3: Connect over SSH — with keys, not passwords
Once the provider finishes provisioning, you'll get an IP address and initial login details. You connect with SSH, the encrypted remote-shell protocol. The single most important decision here is to use key-based authentication instead of a password, because keys aren't guessable and they shut down the password brute-force attacks that hammer every public server.
If you don't already have a key pair, generate one on your local machine:
ssh-keygen -t ed25519 -C "[email protected]"
This creates a private key (keep it secret, never share or upload it) and a public key (~/.ssh/id_ed25519.pub) that's safe to place on servers. Many providers let you paste the public key into the control panel at creation time, which is the cleanest path. If you instead got a root password, copy your key up once:
ssh-copy-id [email protected]
Then log in:
If the key is in place, you're in without typing a password. That's the foundation everything else builds on.
Step 4: Essential first-boot setup
A fresh server should not run your application as root or sit on default settings. Do this short list before installing your stack — it's the difference between a server that's merely running and one that's running safely.
Update the system
Apply the latest security patches first, so you're not starting from a known-vulnerable base.
apt update && apt upgrade -y
On Rocky/Alma, the equivalent is dnf upgrade -y.
Create a non-root user
Working as root all the time means one bad command can wreck the system. Create a regular user with sudo (administrator) rights and use that day to day.
adduser deploy
usermod -aG sudo deploy # use 'wheel' instead of 'sudo' on Rocky/Alma
Copy your SSH key to the new user so you can log in as them, then confirm you can ssh [email protected] and run sudo before locking root out.
Lock down SSH
Once your non-root user works with key login, tighten the SSH daemon. In /etc/ssh/sshd_config, disable root login and password authentication:
PermitRootLogin no
PasswordAuthentication no
Reload SSH (systemctl restart ssh on Debian/Ubuntu, sshd on Rocky/Alma). Keep your current session open and test a new login in a second terminal before you close anything — that way a mistake locks out a test window, not you.
Turn on a firewall
Allow only the ports you actually use — typically SSH plus web traffic — and block the rest. On Ubuntu/Debian, ufw is the simplest option:
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
A firewall that permits only what you need is one of the highest-value, lowest-effort protections on any server.
Set the basics straight
Set the hostname and the correct time zone, and enable a time sync service so logs and certificates line up. These are small, but accurate timestamps matter the first time you're debugging an incident.
A first-boot checklist
- Size small — pick the smallest plan that fits today, in a region near your users.
- Pick an LTS Linux distro — Ubuntu/Debian or Rocky/Alma; nothing exotic.
- Use SSH keys — generate a key pair, disable password login.
- Update — patch the system before anything else.
- Add a sudo user — stop working as root.
- Harden SSH and enable a firewall — disable root/password login, allow only needed ports.
- Set hostname, time zone, and time sync — get the housekeeping right.
Only after this should you install your web server, database, or application stack.
FAQ
Do I need to know Linux to set up a VPS?
You need the basics: moving around the filesystem, editing a config file, and running commands as sudo. You don't need to be an expert. Choosing a mainstream LTS distribution matters here, because the large community means nearly every beginner question is already answered online.
Should I log in with a password or an SSH key?
Use an SSH key. Keys can't be guessed the way passwords can, which closes off the constant automated brute-force attempts against public servers. Once key login works, disable password authentication entirely for the biggest single security gain on a new box.
How much CPU and RAM does my first VPS need?
Less than you'd expect for a small site, API, or staging environment. Start with a modest plan and watch your memory usage, which is usually the first resource to run short. Because resizing up is quick, it's cheaper to start small and scale than to pay for idle capacity.
Managed or unmanaged VPS?
Unmanaged is cheaper and gives full control, but you handle updates, security, and configuration yourself — which this guide prepares you for. Managed costs more and hands those tasks to the provider; it's the better choice if no one on the team wants to administer a server or your time is better spent elsewhere.
What's the first thing to do after creating a VPS?
Update the system to apply security patches, then create a non-root user with sudo, set up SSH key login, and disable root and password logins. Doing this before you expose the server to traffic is what keeps a fresh box from being compromised early.
Next step
Provision the smallest VPS that fits your project, pick an LTS Linux release, and work through the first-boot checklist before you install anything — keys, a sudo user, a hardened SSH config, and a firewall. Then watch your CPU, memory, and disk, and resize only when the metrics, not your guesses, tell you it's time.
