You want a VPS but you're tired of shared hosting limits and not ready to spend thirty dollars a month. Good news: the market has shifted hard in the last few years, and you can now spin up a solid VPS for the cost of a coffee. I'll walk you through the entire process—from picking a provider to locking down SSH and serving your first page.
Why a VPS instead of shared hosting
Shared hosting puts you on a server with hundreds of neighbors. One bad script can tank everyone's performance, and you're stuck with whatever PHP version or module set the host decides to install. A VPS gives you root access, your own kernel, and full control over the software stack. You can install anything, tune configs, and restart services without opening a support ticket.
The trade-off? You're responsible for security, updates, and troubleshooting. If that sounds scary, this guide will get you comfortable fast.
Eight providers that stay under five dollars a month
Prices shift with promotions, so I'm listing the budget tier each provider typically offers rather than exact numbers. Expect one or two CPU cores, 512 MB to 1 GB RAM, and 10–25 GB SSD storage at this price point.
- Vultr — their starter tier usually sits around this range, and you get hourly billing so you only pay for uptime. Locations span five continents.
- Hetzner Cloud — German data centers with a reputation for fast network and straightforward pricing. The smallest instance is often the cheapest in Europe.
- Linode (Akamai) — the nanode plan has been a budget staple for years. Excellent docs and a clean dashboard.
- DigitalOcean — their basic droplet fits the budget if you catch a promo credit for new accounts. Rock-solid uptime in my experience.
- Contabo — pushes more RAM and disk at the low end than most competitors, though support response can be slow.
- RackNerd — frequently runs promotions that drop annual costs below sixty dollars. Check their LowEndTalk offers.
- Hostinger VPS — entry-level plan is marketed to WordPress users but works for any stack. Managed panel costs extra.
- IONOS — European provider with U.S. data centers. Their intro rates can be aggressive; watch for renewal bumps.
Pick based on geography (latency matters for your visitors), payment method, and whether you need hourly versus monthly billing. I usually go with Vultr or Linode for support tickets—both have active communities and you can spin up a test instance in under a minute.
Step 1: Create your account and deploy the instance
Sign up, verify your email, and add a payment method. Most providers accept cards or PayPal; a few take crypto. Once you're in the dashboard, hit the button to create a new server (called a droplet, instance, or VPS depending on the brand).
You'll choose:
- Operating system — Ubuntu LTS (22.04 or 24.04) or Debian stable are safe bets. Avoid experimental distros unless you enjoy midnight kernel panics.
- Region — closest to your audience. If you're unsure, pick the same continent.
- Plan size — the cheapest option with at least 1 GB RAM. Half a gig can work for a static site but chokes under any real load.
- SSH key — upload your public key now. Some dashboards make this optional, but password-only root login is a bad idea.
If you don't have an SSH key yet, generate one on your local machine:
ssh-keygen -t ed25519 -C "[email protected]"
Press Enter to accept the default path, set a passphrase (or skip it if you're the only user on your laptop), and copy the contents of ~/.ssh/id_ed25519.pub into the provider's key field. The .pub file is public and safe to paste anywhere; keep the private key file secret.
Click deploy. Most providers provision in under sixty seconds.
Step 2: Log in and run your first update
Your dashboard will show the server's IP address once it's running. Open your terminal and connect:
ssh root@your_server_ip
If you used an SSH key, you'll connect without a password. First thing: update the package list and upgrade installed software.
apt update && apt upgrade -y
This can take a minute or two on a fresh Ubuntu install. The -y flag skips confirmation prompts. Some packages will ask about config file changes during upgrade; the default answer (keep your current version) is usually fine for a brand-new server.
Step 3: Create a non-root user
Running everything as root is fast but dangerous. One typo in a command can wipe your data. Make a regular user and give it sudo privileges:
adduser yourname
usermod -aG sudo yourname
Set a strong password when prompted. Now copy your SSH key to the new user's home so you can log in without root:
rsync --archive --chown=yourname:yourname ~/.ssh /home/yourname
Log out and test the new account:
ssh yourname@your_server_ip
If that works, disable root login entirely. Open the SSH daemon config:
sudo nano /etc/ssh/sshd_config
Find the line PermitRootLogin yes and change it to no. Save with Ctrl+O, exit with Ctrl+X, then restart SSH:
sudo systemctl restart sshd
You've just closed the most common attack vector on new VPS instances. Bots scan for open SSH and hammer root with password lists all day.
Step 4: Configure the firewall
Ubuntu ships with ufw (uncomplicated firewall), which is exactly that. By default everything is open. Lock it down:
sudo ufw allow OpenSSH
sudo ufw enable
Type y when it warns you about disrupting existing connections. You already allowed SSH, so you won't get locked out. Check status:
sudo ufw status
You should see port 22 allowed from anywhere. Later, when you install a web server, you'll run sudo ufw allow 'Nginx Full' or sudo ufw allow 80/tcp and sudo ufw allow 443/tcp for HTTP and HTTPS.
Step 5: Install a web server
I'll show Nginx because it's lighter than Apache on low-RAM instances, but the steps are similar for any stack.
sudo apt install nginx -y
Once installed, Nginx starts automatically. Open the firewall:
sudo ufw allow 'Nginx Full'
Now visit http://your_server_ip in a browser. You should see the Nginx welcome page. That's your proof the server is listening and the firewall rule works.
The default site config lives at /etc/nginx/sites-available/default. For a quick test, drop a custom index.html in /var/www/html:
echo "<h1>Hello from my VPS</h1>" | sudo tee /var/www/html/index.html
Refresh your browser. The welcome page is gone and your HTML appears.
Step 6: Point a domain and set up SSL
Buying a domain costs more than five dollars a month, but if you already own one or grab a cheap TLD, you'll want HTTPS. First, add an A record in your DNS panel pointing to the server IP. Wait a few minutes for propagation—dig yourdomain.com will show the new IP when it's ready.
Install Certbot for Let's Encrypt certificates:
sudo apt install certbot python3-certbot-nginx -y
Run the Nginx plugin, which auto-detects your server blocks and modifies the config:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
Enter your email, agree to the terms, and choose whether to redirect HTTP to HTTPS (pick yes). Certbot writes the SSL directives and reloads Nginx. Visit https://yourdomain.com and confirm the padlock appears.
Certs renew automatically via a systemd timer. Check it with:
sudo systemctl status certbot.timer
Step 7: Harden SSH further (optional but smart)
You've already disabled root login. Go one step further and disable password authentication entirely, forcing key-based login. Edit /etc/ssh/sshd_config again:
sudo nano /etc/ssh/sshd_config
Find or add these lines:
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
Restart SSH:
sudo systemctl restart sshd
Anyone without your private key can't log in, even if they know your username and password. That stops brute-force attacks cold.
Another quick win: change the default SSH port from 22 to something random like 2849. Edit the same config file, find Port 22, and change it. Remember to allow the new port in ufw before restarting SSH, or you'll lock yourself out:
sudo ufw allow 2849/tcp
sudo ufw delete allow OpenSSH
sudo systemctl restart sshd
Next time you connect, use ssh -p 2849 yourname@your_server_ip.
What about backups and monitoring
Most providers offer snapshot services for a dollar or two extra per month. Enable weekly snapshots in your dashboard—it's the easiest rollback option if an update breaks something. For manual backups, rsync to your local machine works:
rsync -avz yourname@your_server_ip:/var/www/html ~/vps-backup
Monitoring can be as simple as UptimeRobot (free tier pings your site every five minutes) or as detailed as installing Netdata on the VPS itself. I lean toward external monitoring for uptime and local logs for debugging.
Check disk usage regularly:
df -h
And memory:
free -m
On a 1 GB instance, you'll hover around 200–400 MB used with Nginx and a basic site. Add MySQL or heavy PHP frameworks and you'll climb fast. Swap can save you from OOM kills, but it's slow—better to upgrade the plan or optimize your code.
Common mistakes I see in support tickets
Skipping ufw enable entirely. Your VPS is exposed the moment it boots, and port scanners will find it in minutes. Enable the firewall before you install anything else.
Using weak passwords for database root. If you install MySQL or PostgreSQL, the installer asks for a root password. Don't use "password123" or the same credential you use for SSH.
Not setting up unattended upgrades. Security patches land weekly. Install the unattended-upgrades package and let it handle kernel and package updates automatically:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades
Answer yes to enable. Your server will pull security fixes overnight and reboot if required (though you can tune that behavior in /etc/apt/apt.conf.d/50unattended-upgrades).
What to check first when something breaks
Look at the logs. Nginx errors live in /var/log/nginx/error.log, system messages in /var/log/syslog, and authentication attempts in /var/log/auth.log. Most issues leave a clear trail.
If SSH stops responding, log into your provider's web console (every dashboard has one) and check if the service is running:
sudo systemctl status sshd
If the server is unresponsive entirely, reboot from the dashboard. A budget VPS can hit CPU throttling or run out of memory if you haven't set up swap.
And keep snapshots recent. Rolling back beats debugging a broken upgrade at 2 AM.