Skip to content
DevOps devops getting-started 6 min read

Setting Up a Practice Lab

You cannot learn DevOps by reading alone. You need a real Linux server you can log into, install software on, break, and rebuild — without any fear of damaging your work machine or running up a huge bill. This page shows you two cheap, safe ways to get that server: a virtual machine (VM) on your own laptop, or a small cloud VPS (Virtual Private Server — a Linux machine you rent by the hour from a provider). Both run Ubuntu, the Linux version most companies use, so the skills transfer directly to a real job.

A virtual machine (VM) is a complete computer that runs as software inside your real computer. It has its own disk, memory, and operating system, but it is fully isolated — if you wreck it, you just delete it and your laptop is untouched. That isolation is exactly why a lab is the right place to make mistakes.

Option 1 vs Option 2 — which to choose

Local VM (VirtualBox / Multipass)Cloud VPS (DigitalOcean / Hetzner)
CostFree~$4–6/month, or pennies per hour
Setup speed10–20 min first time60 seconds
Works offlineYesNo (needs internet)
Public IP addressNo (hard to reach from outside)Yes (real internet address)
Practice domains, TLS, DNSAwkwardRealistic and easy
Best forDaily practice, no internet, zero costPractising real deploys, networking, firewalls

Start with a local VM to learn Linux basics for free. Move to a cheap VPS once you want to practise things that need a real public IP — like serving a website, configuring a firewall against real traffic, or pointing a domain name at your server.

Option 1: A local Ubuntu VM

You have two easy tools. Multipass is the fastest — one command gives you a ready Ubuntu VM. VirtualBox gives you a full graphical setup and is better if you want to see the install process.

Fastest path: Multipass

Multipass (by Canonical, the makers of Ubuntu) creates Ubuntu VMs from a single command. Install it, then launch a VM.

sudo snap install multipass
multipass launch 24.04 --name lab --cpus 2 --memory 2G --disk 10G

Output:

Launched: lab

Now open a shell inside your new server:

multipass shell lab

Output:

Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-41-generic x86_64)
ubuntu@lab:~$

That prompt means you are now inside the VM. Update its packages and you have a working practice server:

sudo apt update && sudo apt upgrade -y

To stop, start, or delete the VM later:

multipass stop lab      # shut it down
multipass start lab     # boot it back up
multipass delete lab && multipass purge   # remove it completely

When to use Multipass: you want a no-fuss Ubuntu server in seconds and you are comfortable on the command line. When not to: you want to see a graphical desktop or practise the OS install steps — use VirtualBox for that.

VirtualBox

VirtualBox is a free tool from Oracle that runs VMs with a graphical window.

  1. Install VirtualBox: sudo apt install virtualbox -y (on Windows/macOS, download it from virtualbox.org).
  2. Download the Ubuntu Server 24.04 LTS .iso file from ubuntu.com/download/server.
  3. In VirtualBox click New, name it lab, set 2 CPUs, 2048 MB memory, and a 15 GB disk.
  4. Under Settings → Storage, attach the Ubuntu .iso to the virtual CD drive.
  5. Click Start and follow the on-screen Ubuntu installer. Tick “Install OpenSSH server” when asked so you can log in remotely later.

After install, you can connect to it from your laptop’s terminal with SSH (Secure Shell — an encrypted way to log into a remote machine):

ssh ubuntu@<vm-ip-address>

Option 2: A cheap cloud VPS

A VPS gives you a real server on the public internet with its own IP address. This is the closest thing to a production environment, and you only pay for the hours you use. Good 2026 options: Hetzner (cheapest, ~€4/mo), DigitalOcean, and Linode/Akamai. The steps below use DigitalOcean’s term “Droplet”, but the idea is identical everywhere.

Create the server

In the provider’s web console:

  1. Click Create → Droplet (or “Server”).
  2. Choose Ubuntu 24.04 (LTS) x64 as the image.
  3. Pick the cheapest plan (1 vCPU, 1 GB RAM is plenty for practice).
  4. Under Authentication, choose SSH key and paste your public key (generate one with ssh-keygen -t ed25519 if you don’t have it). SSH keys are far safer than passwords.
  5. Click Create. After about a minute you get a public IP address.

Log in from your own terminal:

ssh [email protected]

Output:

Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-31-generic x86_64)
root@ubuntu-lab:~#

Make it safe immediately

A fresh public server is scanned by bots within minutes. Lock it down before doing anything else. Create a normal user, give it admin rights, and turn on the firewall with ufw (Uncomplicated Firewall — Ubuntu’s simple firewall front-end).

adduser deploy
usermod -aG sudo deploy
ufw allow OpenSSH
ufw enable

Output:

Firewall is active and enabled on system startup

Never run your practice apps as root. One typo as root can wipe the whole machine. Log in as your normal deploy user and use sudo only when a command truly needs admin rights.

When you finish for the day, destroy the Droplet in the console — you stop paying the moment it is deleted. Recreate it in a minute next time.

Snapshots — break things, then reset

The single best habit in a lab is taking a snapshot: a saved copy of the entire disk at a moment in time. Practise something risky, and if it goes wrong, roll back to the snapshot instead of rebuilding from scratch.

In Multipass:

multipass stop lab
multipass snapshot lab --name clean-base

To roll back later:

multipass stop lab
multipass restore lab.clean-base

In VirtualBox, use the Machine → Take Snapshot menu. On a cloud VPS, use the Snapshots tab in the console (a small monthly fee usually applies for stored snapshots).

Take a snapshot called clean-base right after first setup. That gives you a guaranteed clean starting point to return to every time an experiment goes sideways.

Best Practices

  • Always start with Ubuntu LTS (Long Term Support — the stable version supported for years): 24.04 or 22.04. It matches what real teams run.
  • Take a clean-base snapshot immediately after setup, and a fresh snapshot before any risky experiment.
  • Use SSH keys, never passwords, and enable ufw on any server with a public IP.
  • Do real work as a normal sudo user, not as root.
  • Keep VMs small (1–2 GB RAM) so you can run several at once and simulate a multi-server setup.
  • On a cloud VPS, destroy the server when you are done practising to avoid paying for idle time.
  • Write down (or script) the steps you take so you can rebuild your lab from nothing — that scripting habit is the heart of DevOps.
Last updated June 15, 2026
Was this helpful?