Proxmox Beginner's Guide: VMs, LXC, and Your First Self-Hosted Service
A plain-English walkthrough of how Proxmox actually works -- VMs vs. containers, the web UI, storage, networking, and how to run your first self-hosted service without breaking anything.
This guide assumes you already have Proxmox installed. If you’re starting from scratch, the Proxmox on a Mini PC setup walkthrough covers hardware selection, BIOS prep, and first-VM layout for N100 machines specifically. The Proxmox install guide covers the ISO install process step by step.
The install guide gets you to the login screen. This guide is about what to do after that — how Proxmox actually works, what all the panels mean, and how to go from a blank hypervisor to running your first real service.
If you’ve ever set up a regular Linux server, some of this is familiar. If you’re coming from a consumer NAS or a plain Docker setup, a few concepts will be new. Either way, the goal is the same: get something useful running without spending three hours fighting the UI.
See the full homelab stack this fits into at /stack/.
How the Proxmox web UI is laid out
Open https://<your-proxmox-ip>:8006 in a browser. You’ll get a certificate warning — ignore it for now and proceed. Log in as root.
The layout has three main sections:
Left panel — the tree: Your entire infrastructure lives here. At the top is Datacenter (global settings). Below that is your node (the physical machine — usually named pve by default). Under the node you’ll see every VM and container you create, listed by ID.
Right panel — the details view: Click anything in the tree and the right side shows you everything about it. For the node, you see hardware summary, running services, and resource usage. For a VM, you get Summary, Console, Hardware, Options, Backup, Replication, and more.
Top bar: Notifications (subscription warnings — ignore them), the Create VM and Create CT buttons you’ll use constantly, and a Shell button that drops you into a root shell on the Proxmox host itself.
That’s it. It’s denser than consumer software but not complicated once you understand the tree model.
The two things Proxmox runs: VMs and containers
Every service you run will be one of these two things.
Virtual Machines (VMs)
A VM emulates a complete computer. Proxmox acts as a hypervisor and runs a full operating system in isolation. The VM has its own kernel, its own memory, its own virtual hard disk. It thinks it’s a real machine.
The practical result: VMs are heavier. A minimal Ubuntu Server VM uses around 512MB of RAM just at idle. Boot time is 20-60 seconds. But they’re completely isolated — what happens inside a VM can’t escape to the host, and VMs can run any OS including Windows.
When to use a VM:
- Running Docker (the recommended approach — Docker inside an LXC container requires privileged mode which weakens isolation)
- Running Windows
- Running anything internet-facing where you want the strongest isolation
- Testing and experimenting — you can snapshot before a destructive change and roll back instantly
LXC Containers
An LXC container shares the host kernel. It’s an isolated process environment, not a full OS. The result: much lower overhead. An LXC container running Pi-hole might use 50MB of RAM. Boot time is 2-5 seconds. They start fast, use almost nothing, and you can run dozens of them on modest hardware.
When to use LXC:
- Lightweight services that run as a Linux service, not via Docker — Pi-hole, AdGuard Home, Technitium DNS
- High service count — 20 LXC containers are feasible where 20 VMs are not
- Services where Docker’s overhead isn’t needed
The standard budget homelab layout: one Ubuntu 24.04 VM as a Docker host that runs the majority of services, plus a handful of LXC containers for the few things that don’t need Docker. This is what the stack on this site uses.
For a deeper breakdown of the trade-offs with concrete examples, see Proxmox VM vs LXC.
Storage in Proxmox
When you installed Proxmox, it created a default storage pool on your drive. In the web UI, go to Datacenter → Storage and you’ll see something like local and local-lvm.
local — stores ISO images, CT templates, and Proxmox backups. Think of it as the staging area.
local-lvm — stores the actual disk images for your VMs and containers. This is where the 32GB you allocate to a VM actually lives.
For a single-drive setup, you don’t need to change anything. The defaults work fine for a basic homelab.
Adding storage later
If you add a second drive or an external disk, you can add it via Datacenter → Storage → Add. Proxmox supports local directories, LVM, NFS shares, and more. Most budget homelabbers start with the defaults and add a NAS or additional drive later when they’re running out of space.
Networking in Proxmox
Proxmox creates a virtual bridge called vmbr0 by default. Every VM and container gets a virtual network interface connected to this bridge. The bridge is connected to your physical network interface, which plugs into your router. From your router’s perspective, each VM or container appears as its own device with its own IP address.
The practical result: assign a static IP to each VM and container. Your router sees them as separate machines. You reach them directly at those IPs from any device on your network.
Your Router
|
vmbr0 (Proxmox bridge)
|
+-- VM 100 (Ubuntu Docker host) -- 192.168.1.20
+-- LXC 101 (Technitium DNS) -- 192.168.1.21
+-- LXC 102 (Pi-hole) -- 192.168.1.22
Static IP tip: Assign IPs in a range your router won’t hand out via DHCP. Most routers default to DHCP from .100 or higher — I use .10-.50 for static assignments to avoid conflicts.
Creating your first LXC container
LXC containers need a template — a base Linux filesystem to start from. Download one first.
In the web UI: pve → local → CT Templates → Templates
Click Templates, search for Debian, and download Debian 12 Bookworm. Ubuntu 22.04 LTS also works if you prefer.
Once the template downloads, click Create CT (top right of the UI):
-
General tab
- CT ID: leave as default (Proxmox auto-increments from 100)
- Hostname: something descriptive like
piholeordns - Password: set a root password
- Uncheck “Unprivileged container” only if the service specifically requires privileged mode
-
Template tab
- Select your downloaded template
-
Disks tab
- 8GB is fine for most lightweight services
-
CPU tab
- 1 core is enough for most things; bump to 2 if you expect load
-
Memory tab
- 512MB for lightweight services; 1024MB if you’re unsure
-
Network tab
- Bridge:
vmbr0 - IPv4: Static
- IPv4/CIDR:
192.168.1.XX/24(pick an IP in your range) - Gateway: your router’s IP
- Bridge:
-
DNS tab
- Leave default or point at your local DNS if you have one
Confirm, click Finish, then click the container in the tree and hit Start. Click Console to open a terminal inside it.
Creating your first VM
You need an OS ISO. Ubuntu Server 24.04 LTS is the default recommendation — it’s what the Docker guides on this site use.
Get the ISO: In the web UI, go to pve → local → ISO Images → Download from URL. Paste the Ubuntu Server 24.04 ISO URL from ubuntu.com and click Query URL, then Download. Wait for it to finish.
Click Create VM:
-
General tab
- VM ID: auto-assigned
- Name:
docker-hostor similar
-
OS tab
- Storage: local
- ISO image: select your downloaded Ubuntu ISO
- Type: Linux, Version: 6.x - 2.6 kernel
-
System tab
- Leave defaults (SeaBIOS is fine; OVMF/UEFI if you have a preference)
- Check “Qemu Agent” — install this later inside the VM for better Proxmox integration
-
Disks tab
- 32GB minimum for a Docker host; 64GB if you’ll store data in containers
- Check “SSD emulation” if your underlying storage is SSD (it usually is on a mini PC)
-
CPU tab
- 2 cores for a general Docker host
- Bump to 4 if you’re running transcoding (Jellyfin, Plex)
-
Memory tab
- 4096 MB (4GB) for a typical Docker host
- 8192 MB if you’re running memory-hungry services like Nextcloud
-
Network tab
- Bridge:
vmbr0 - Model: VirtIO (better performance than the default)
- Bridge:
Click Finish. The VM is created but not started.
Select the VM in the tree, click Start, then click Console. Work through the Ubuntu Server installer — set hostname, create a user, enable OpenSSH. The only setting that matters here: when you get to storage, the defaults are fine unless you have a specific preference.
After the installer finishes and the VM reboots, SSH in from your local machine:
ssh [email protected]
Then set a static IP. Ubuntu 24.04 uses Netplan. Edit the config:
sudo nano /etc/netplan/00-installer-config.yaml
A static IP config looks like this:
network:
version: 2
ethernets:
ens18:
dhcp4: no
addresses:
- 192.168.1.20/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
Replace ens18 with your actual interface name (run ip a to find it), and adjust the IPs to match your network. Apply it:
sudo netplan apply
If you lose your SSH connection, reconnect at the new IP.
Running your first service
At this point you have a VM and/or an LXC container running. The next step is getting something useful running inside them.
The fastest path: install Docker inside your VM and follow the Docker Compose basics guide to set up your first container. The Docker guide walks through installation and then deploys a sample service with a complete compose.yml file.
Quick Docker install on Ubuntu:
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
Log out and back in, then test with docker run hello-world.
From there, pick a service and follow its setup guide. Uptime Kuma is a good first one — it’s small, it’s useful immediately, and the Uptime Kuma setup guide is short. From there, Jellyfin, Vaultwarden, and Paperless-ngx cover the highest-value categories.
Snapshots before you do anything destructive
Proxmox snapshots are instant and cheap. Use them before you try anything that might break the VM.
In the VM tree entry, click Snapshots → Take Snapshot. Give it a name. It takes 2-5 seconds.
If something goes wrong — a bad config change, a failed OS upgrade, a package that breaks things — click the snapshot and hit Rollback. The VM reverts to exactly the state it was in when you took the snapshot. No reinstalling.
The Proxmox Snapshots and Backups guide covers the full backup strategy including scheduled backups to external storage, which is different from snapshots — snapshots live on the same disk, so they won’t save you if the drive fails.
The post-install checklist
If you haven’t done this yet, the Proxmox post-install checklist covers a few configuration changes that eliminate common annoyances:
- Removing the subscription nag popup that appears on every login
- Disabling the enterprise repository (which requires a paid sub you don’t need)
- Enabling dark mode if you’re into that
None of these affect functionality, but the subscription nag gets old fast.
What comes next
This guide covers the concepts and the basic operations. The real value of Proxmox comes from building out the stack — services that talk to each other, protected by authentication, reachable from anywhere via Tailscale.
The logical next guides depending on where you want to go:
- Add more services: Docker Compose basics to get Docker running, then any of the self-hosted app guides
- Remote access: Tailscale homelab setup — connect to your homelab from anywhere without port forwarding
- A real domain and HTTPS: Nginx Proxy Manager setup — friendly URLs and valid SSL certificates for every service
- SSO and authentication: Authelia SSO setup — one login for all your services, optional 2FA
All of these run as Docker containers inside the VM you just created. They’re designed to work together. The full picture is at /stack/.