Setting Up a VPS: From First Login to a Running Web Stack

Moving to a VPS is the point where you stop renting a slice of someone else's setup and start running a server of your own. It's a genuine step up in performance and control — and in responsibility. On a managed shared plan, the host handles security and maintenance. On an unmanaged VPS, that's now your job. The good news is that the core setup follows a predictable order, and getting that order right is most of the battle.

The short version: pick a server size that matches your workload, choose a Linux distribution you're comfortable with, lock the server down before you put anything on it, then install your web stack and settle into a simple maintenance routine. This guide walks through each step with the reasoning behind it, so you understand not just what to do but why.

If you're still deciding whether a VPS is even the right move, start with our guide to web hosting types, which compares shared, VPS, cloud, and dedicated. This guide assumes you've decided a VPS fits and are ready to set one up.

Before you start: managed or unmanaged?

The first real decision isn't technical — it's how much administration you want to own. An unmanaged VPS gives you full root access and a bare server; everything from security patches to software installation is yours. A managed VPS costs more, but the provider handles patching, hardening, and often support.

Choose unmanaged if you're comfortable on the command line and want full control or lower cost. Choose managed if you'd rather not be responsible for server maintenance, or if downtime would be costly and you don't have the time to administer a box properly. There's no wrong answer — only the one that matches your skills and how much risk you want to carry. The rest of this guide assumes an unmanaged VPS, since that's where the work lives.

Step 1: Size the server to the workload

It's tempting to over-provision "just in case," but a VPS is easy to resize later, so start close to what you actually need. Three resources matter most:

• RAM is usually the first thing you run out of. A small site or a single application is comfortable on a modest amount; databases and multiple services want more. If a server starts swapping to disk, it's short on memory.
• CPU matters for traffic volume and anything compute-heavy. Most small sites are fine with one or two virtual cores; busier or application-heavy workloads need more.
• Storage should fit your files, database, and — importantly — room for logs and backups. SSD or NVMe storage is worth choosing for the speed.

The honest rule of thumb is the same one that applies to hosting generally: start one step below where you think you need to be, then scale when a real constraint appears. Resizing a VPS is routine; paying for idle capacity for months is just waste.

Step 2: Choose an operating system

Almost all VPS hosting runs Linux, and for a web server the practical choice is a stable, well-documented distribution. The two most common families are Debian/Ubuntu and the RHEL family (such as Rocky or AlmaLinux).

Pick based on familiarity and support, not hype. Ubuntu LTS and Debian have enormous communities and documentation, which means when you hit a problem, someone has almost certainly written up the fix. A "Long Term Support" or stable release matters here: you want predictable security updates over a long window, not the newest features. If your application or framework recommends a specific distribution, follow that — compatibility beats preference.

Step 3: Secure the server before anything else

This is the step beginners skip and regret. A fresh server with a public IP will start receiving automated login attempts within minutes. Harden it before you install a single application. The essential first-login steps:

1. Update everything. Apply all available package updates immediately so you start from a patched baseline. On Debian/Ubuntu that's apt update && apt upgrade.
2. Create a non-root user with sudo. Don't do daily work as root. Make a regular user, give it sudo rights, and use that account.
3. Set up SSH key authentication and disable password login. Keys are far harder to brute-force than passwords. Once your key works, disable password authentication and root SSH login in the SSH config.
4. Enable a firewall. Allow only the ports you actually use — typically SSH plus web ports 80 and 443 — and block the rest. A simple tool like ufw makes this straightforward.
5. Consider automated security updates and brute-force protection. Unattended security upgrades and a tool like Fail2ban reduce the day-to-day exposure without constant attention.

The reason this comes before installation is simple: a compromised server is worse than no server, and the cheapest time to secure a box is when there's nothing on it yet. Security isn't a final polish; it's the foundation.

Step 4: Install your web stack

With the server hardened, install the software that actually serves your site. The two classic stacks are LEMP (Linux, Nginx, MySQL/MariaDB, PHP) and LAMP (the same with Apache instead of Nginx). Nginx is often chosen for its efficiency with high concurrency and as a reverse proxy; Apache is flexible and uses per-directory configuration that some applications expect. Either is a sound choice — pick the one your application documents or that you know better.

A typical install sequence:

• Web server (Nginx or Apache) to handle incoming requests.
• Database (MariaDB or MySQL, or PostgreSQL depending on your app) and then run its security script to remove test defaults and set a root password.
• Application runtime (PHP, Node.js, Python, etc.) matched to what you're deploying.
• TLS certificate so the site is served over HTTPS. A free automated certificate authority makes this a one-command job and auto-renews, so there's no reason to run a site without encryption.

Test each component before moving to the next. It's far easier to find the broken link when you've only just installed it.

Step 5: Set up backups and a maintenance routine

Running your own server means recovery is your responsibility too. Before you rely on the box, make sure you can restore it.

• Back up off the server. A backup that lives only on the same VPS disappears with the VPS. Store copies somewhere separate, and include both files and databases.
• Test a restore. An untested backup is a hope, not a plan. Confirm you can actually bring data back before you need to.
• Keep a light routine. Apply security updates regularly, watch disk space (logs fill up quietly), and skim the logs for anything unusual.

None of this is heavy work once it's set up, but it's the difference between a hiccup and a catastrophe when something fails.

Scaling later

A VPS grows with you. When you hit a real constraint, you have options in roughly increasing order of effort: resize the existing server to add RAM, CPU, or storage; tune your stack with caching and database optimization; or, for larger workloads, move to a more powerful VPS, a dedicated server, or a multi-server setup. The trigger should always be a measured limit — sustained high resource use or slow response times — not a guess. Scaling on evidence keeps you from paying for capacity you don't use.

Frequently asked questions

Do I need to know Linux to run a VPS?

For an unmanaged VPS, yes — at least the basics of the command line, package management, and editing config files. If you'd rather not learn server administration, a managed VPS hands the maintenance back to the provider, which is a reasonable trade for the higher price.

What's the very first thing I should do on a new VPS?

Update all packages, then secure access: create a non-root sudo user, set up SSH key authentication, disable password and root SSH login, and enable a firewall. Do this before installing any application, because a fresh public server is targeted by automated attacks almost immediately.

LEMP or LAMP — which stack should I choose?

Both are solid. Nginx (LEMP) is efficient under high concurrency and popular as a reverse proxy; Apache (LAMP) is flexible and expected by some applications that rely on per-directory configuration. Choose the one your application recommends or the one you know better.

How much RAM and CPU does my VPS need?

Match it to your workload and start small, since resizing is easy. A simple site is comfortable on a modest amount of RAM and one or two virtual cores; databases, multiple services, or heavier traffic need more. Watch for memory swapping or sustained high CPU as signals to scale up.

Should I get a managed VPS instead?

Get managed hosting if you don't want to handle patching, hardening, and troubleshooting yourself, or if downtime would be costly and you lack the time to administer a server properly. Unmanaged is cheaper and gives full control, but the maintenance and security are entirely on you.

Next step

Provision a small VPS that matches today's workload, then resist the urge to install anything until the server is locked down. Work the security steps first — updates, a sudo user, SSH keys, a firewall — then install your stack, set up off-server backups, and confirm you can restore them. Build the habit of starting with the foundation, and scaling up later becomes a routine task rather than a scramble.