Linux Lab on a $5 VPS: Commands, Projects, and a 30-Day Roadmap

A $5/month VPS is the cheapest way to own a real Linux server that runs 24/7 with a public IP. Unlike a local virtual machine, everything you break is real: networking, firewall rules, SSH keys, and disk layout. This walkthrough covers the commands and projects that turn a cheap VPS into a working lab for Linux, networking, and DevOps skills — without a paid course.

First 15 Minutes: Secure the Server

On first login you have an IP and a root password. Lock it down before anything else:

# Update everything
apt update && apt upgrade -y

# Create a regular user
adduser lab
usermod -aG sudo lab

# Copy your SSH key up (from your laptop)
ssh-copy-id lab@your-server-ip

# Disable password login for root
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

Add a firewall rule set next. ufw allow 22, then ufw allow 80 and 443, then ufw enable. Install fail2ban to auto-block brute-force attempts — on a public IP these start within hours.

The Core Command Set to Master

Task	Command
Disk usage by directory	du -sh /* | sort -h
Live resource view	htop
Open listening ports	ss -tulpn
Follow a live log	journalctl -fu nginx
Service control	systemctl status|restart|enable
Find large files	find / -type f -size +100M

Memorize systemctl and journalctl first. Almost every service you install — web server, database, VPN — is managed the same way, so learning the pattern once pays off across all of them.

Projects That Build Real Skills

Run these in order. Each one introduces a layer of the stack that employers and real deployments depend on:

1. Static site with NGINX — serve a folder over HTTP, then add TLS with a free Let’s Encrypt certificate via certbot. This teaches DNS, ports, and TLS end to end.
2. Reverse proxy — run a small app on port 3000 and proxy it through NGINX on 443. This is the pattern behind nearly every production deployment.
3. Database — install PostgreSQL or MariaDB, create a user, and connect from the app. Practice backing it up with pg_dump.
4. Containerize — install Docker, run the same app in a container, and mount a volume for persistence. Compare the memory footprint of container vs native install.
5. Automation — write a cron job that backs up a database nightly and rotates old copies.

When you are ready to size a server that can run several of these at once, the budget VPS specifications listed at affordablevpsserver.com show what each RAM tier realistically supports, so you can grow the lab without paying for headroom you do not need yet.

Monitoring Your Lab for Free

You cannot learn operations without watching a system under load. Install these at no cost:

• htop — instant view of CPU, memory, and per-process usage.
• netdata — a browser dashboard with graphs for CPU, disk, and network. One curl | bash install.
• ncdu — interactive disk usage explorer to find what filled your 25 GB.
• A simple uptime check — a cron job curling your own site every five minutes and logging failures.

Keeping the Lab Inside a $5 Budget

Learning should not trigger surprise bills. Three habits keep a lab server within budget:

• Watch bandwidth. Experimenting with large downloads and torrents can burn a transfer allowance fast. Check usage weekly.
• Snapshot before risky experiments. A snapshot is far cheaper than a lost weekend rebuilding a broken config.
• Track renewals. Promotional first-year prices often rise on renewal. Note the date so your lab does not vanish.

A 30-Day Learning Path

Week 1: secure the server and serve a static site with TLS. Week 2: reverse-proxy an application and connect a database. Week 3: containerize it and add automated backups. Week 4: add monitoring, intentionally break a service, and restore it from a snapshot. By the end you will have touched the same layers a junior DevOps role uses daily — for the cost of a few cups of coffee. The VPS is the cheapest classroom you will ever rent.

Making the Lab Safe to Experiment In

The value of a lab comes from breaking things safely. Three habits make that possible without wrecking your server. First, snapshot before any change you are unsure about, so recovery is a button rather than a rebuild. Second, keep a text file of every command that worked, forming a personal runbook you will reuse for real projects. Third, run untrusted services in containers or a separate user account so a broken experiment cannot take down the whole box.

Turning the Lab Into a Portfolio

• Document each project with the commands used and the problem it solved.
• Publish a small write-up of the reverse-proxy and TLS setup — a common interview topic.
• Note the measured memory footprint of each service; real numbers stand out.
• Keep the server public but hardened to show you understand security, not just setup.

A single $5 server running a documented stack demonstrates more practical skill than a folder of certificates. When you outgrow it, upgrading is a matter of picking a larger plan — many beginners start with an entry-tier budget VPS from affordablevpsserver.com precisely because the price stays low while the learning ceiling is high.