How to Build a Tiny Data Center at Home: A Secure Homelab Guide

To build a tiny data center at home, start with one quiet, low power machine (a mini PC or a small used server), install a hypervisor such as Proxmox VE, put the lab on its own network segment behind a firewall, plug it into a UPS, and reach it from outside only through a VPN such as WireGuard. Back everything up with the 3-2-1 rule, and measure the power draw before you buy more hardware, because electricity is the cost that never stops.

A homelab is a small version of what a real data center does: compute, storage, networking, power protection, cooling, backups and access control. This guide walks through each layer, works out the electricity bill with current US government price data, and builds the stack with commands from the official Proxmox VE, WireGuard, Ubuntu Server and Docker docs, checked on 23 October 2026.

Key takeaways

• Start small. One mini PC with enough RAM runs a hypervisor, a few VMs and a container host.
• Power is the running cost. At the July 2026 US average residential price of 18.31 cents per kWh (EIA), a lab that averages 120 W costs about $192 a year. A used server pulling 300 W costs about $481.
• Proxmox VE 9.2 is the current release (ISO dated 21 May 2026), built on Debian 13 Trixie. It needs a 64 bit CPU with Intel VT or AMD-V, and its own docs recommend SSDs with power loss protection.
• Segment the network. Put the lab, your family's devices and untrusted gadgets on separate VLANs or at least separate subnets, with a firewall between them.
• Never port forward admin interfaces. The Proxmox web UI (TCP 8006), SSH, NAS dashboards and router admin pages belong behind a VPN. Expose one UDP port for WireGuard instead.
• Watch the Docker and ufw trap. Docker's own docs say published container ports bypass ufw rules on the same host.
• Back up with 3-2-1. CISA's rule: three copies, two media types, one copy off site. A copy on the same host is not a backup.

What is a homelab, and what counts as a tiny data center at home?

A homelab is a set of computers you run at home to host services, learn infrastructure skills or test software. "Tiny data center" describes the same thing by function: power and backup power, cooling, network connectivity, compute and storage, physical security, and the routines that keep them running, scaled down to one shelf and a wall socket.

The purpose should drive the design. A learning lab for practising virtualization, Kubernetes or security tooling can be torn down and rebuilt at will. A self hosting lab that holds family photos, file sync or a password manager backend is closer to production: it needs backups you have restored at least once, updates on a schedule and a clear answer to "who can reach this from the internet". Decide which one you are building before you buy anything.

Hardware choices: mini PCs, used servers or a NAS?

There are three common starting points. None is universally right; each trades purchase price against power, noise, expandability and management features.

What Proxmox VE actually requires

If you plan to run Proxmox VE, read its requirements before you shop. Proxmox's own requirements page asks for an Intel 64 or AMD64 CPU with the Intel VT or AMD-V flag, or, as of the current release, a 64 bit Arm processor at Armv9-A or newer. It recommends at least 2 GB of memory for the OS and Proxmox services, plus whatever your guests need, and roughly 1 GB of extra memory per TB of storage if you use ZFS or Ceph. PCI passthrough (for example handing a GPU or a disk controller to a VM) needs VT-d or AMD-Vi. For testing only, Proxmox lists a minimum of 1 GB of RAM, one disk and one NIC.

Two storage notes from the Proxmox docs matter for home builders:

1. ZFS and hardware RAID do not mix. Proxmox says neither ZFS nor Ceph is compatible with a hardware RAID controller. Use a plain HBA or the motherboard's SATA ports and let ZFS manage the disks.
2. SSD quality matters. The Proxmox system requirements wiki recommends SSDs with power loss protection (PLP) for good performance and says consumer SSDs are discouraged. Many home labs run fine on consumer drives, but expect more wear under ZFS and plan to replace them.

RAM is usually the real limit

In a virtualized lab, CPU cores sit idle most of the time, while memory is allocated and stays allocated. Between two mini PCs, pick the one with the higher supported RAM maximum. A second NIC is useful too, but if you have only one port, a VLAN aware bridge (covered below) lets one cable carry several isolated networks.

Rack or shelf? Space, noise and heat

You do not need a rack until you own rack mount gear; a sturdy shelf works for mini PCs, a NAS and a switch. If you buy a used rack server, check its depth first.

Noise. Enterprise servers are designed for rooms where nobody sits, and their fans are sized for worst case load. Near a bedroom or home office, a mini PC or a tower with large, slow fans is a better fit.

Heat. Every watt your lab draws ends up as heat in the room. A lab averaging 120 W releases about 410 BTU per hour (1 W is about 3.412 BTU per hour), which a normal room absorbs easily. A 300 W server releases about 1,020 BTU per hour, enough to warm a closed closet noticeably. Leave space for airflow and check hardware temperatures during a warm week.

Physical access. Anyone who can touch the box can boot it from a USB stick. Full disk encryption and a firmware setup password raise the bar.

Power: UPS sizing and electrical safety at a high level

A homelab's power design has two goals: do not overload anything, and shut down cleanly when power fails.

Electrical safety, at a high level only. Plug equipment into a properly grounded wall outlet, do not chain power strips together, and do not load a single household circuit with more than it is rated for. If you think you need a new circuit, a dedicated outlet or any change to wiring, hire a licensed electrician and follow your local electrical code. This guide does not cover electrical work beyond that.

UPS sizing. An uninterruptible power supply bridges short outages and gives your machines time to shut down. When you size one:

• Add up the measured draw in watts (not just the VA rating on the box) of everything that must stay up, including the router that carries your WireGuard endpoint, and leave headroom.
• Use the UPS's USB or network signalling so the hypervisor and NAS shut down on their own when the battery gets low, guests first. A UPS that runs flat is only a slower version of no UPS.
• Batteries age. Test the UPS periodically and replace batteries on the maker's schedule.

How much does a homelab cost in electricity? A worked example

Electricity is the line item that keeps running long after the hardware is paid for, so it is worth doing the arithmetic before you buy.

The formula is simple:

annual kWh  = average watts x 24 hours x 365 days / 1000
             = average watts x 8.76
annual cost = annual kWh x price per kWh

Two inputs matter: the average draw measured at the wall (not the power supply's rating, which is a maximum), and your price per kWh. For the price, the US Energy Information Administration's Electric Power Monthly (Table 5.6.A, data for July 2026, released 24 September 2026) gives an average residential price of 18.31 cents per kWh across the US, up from 17.45 cents in July 2025. State figures in the same table range widely: 12.72 cents in Louisiana, 14.71 in Washington, 33.61 in California and 48.00 in Hawaii.

Worked example. Take a modest lab: one mini PC running Proxmox, a four bay NAS, a managed switch and the UPS's own overhead, averaging 120 W at the wall.

120 W x 8.76            = 1,051.2 kWh per year
1,051.2 kWh x $0.1831   = $192.47 per year, about $16.04 per month

For context, EIA's FAQ puts the average US residential customer's purchases at 10,791 kWh in 2022, so this lab adds a little under 10 percent to a typical household's annual use.

The prices are EIA's July 2026 averages. Summer and winter prices differ, and your bill adds delivery charges, tiers or time of use rates, so use the all in rate from your own bill for a real answer.

Payback on swapping hardware. Replacing the 300 W setup with the 120 W setup saves 180 W, which is 1,576.8 kWh a year, or about $288.71 at the US average price. If the replacement hardware cost $400 (a hypothetical figure for illustration), it would pay for itself in about 1.4 years at that price, and in under a year in California. The same arithmetic tells you when a cheap used server is not cheap.

How to measure. Put a plug in energy meter between the wall and the power strip for a week, then divide the weekly kWh by 168 hours to get your true average. Most homelabs sit near idle most of the time, so idle draw matters more than peak.

Networking: segments, VLANs, firewall and Wi-Fi

The network is where most homelab security is won or lost. The goal is simple: a compromised smart plug should not be able to reach your hypervisor, and nothing on the internet should reach any admin interface.

A practical segment plan

This needs a VLAN capable router and a managed switch. Ubuntu's WireGuard guide notes that some ISP routers can be put into bridge mode so your own device does the routing.

Firewall at the edge and on each host

CISA's home network guidance recommends a firewall at the network boundary and a host based firewall on each computer, noting that some router firewall features may be off by default. In a homelab that means three layers: the edge router, the Proxmox firewall per guest, and ufw inside each Linux VM.

Wi-Fi

Keep lab servers on wired connections. For Wi-Fi, CISA recommends WPA3, changing the router's default admin password and SSID, disabling WPS, disabling UPnP when you do not need it, disabling remote router management and updating router firmware. UPnP matters most in a lab: it lets software on your network open router ports without asking you.

Virtualization with Proxmox VE: VMs or containers?

Proxmox VE is an open source virtualization platform based on Debian. Its installer ISO includes the Proxmox kernel with KVM for virtual machines and LXC for system containers, plus a web interface on TCP port 8006.

Virtual machines run their own kernel. They give the strongest isolation Proxmox offers and can run any OS.

LXC system containers share the host kernel. They start fast and use less memory. Proxmox creates them as unprivileged by default, which maps root inside the container to an unprivileged user on the host, so most escapes become a generic kernel bug rather than a direct path to host root.

Application containers from OCI images are a newer option: Proxmox can convert an OCI image into an LXC container. Proxmox labels this a technology preview, and its docs say that for use cases demanding maximum isolation, nesting containers inside a QEMU VM remains a recommended practice.

Step by step: build the stack

The walkthrough below builds one Proxmox VE node with a VLAN aware bridge, an Ubuntu Server VM running Docker, a WireGuard endpoint and scheduled backups. Commands come from the official docs listed in Sources. Replace the example addresses and names with your own.

Step 1: Download, verify and write the Proxmox VE installer

Download the ISO only from proxmox.com. The downloads page currently lists Proxmox VE 9.2 ISO Installer, version 9.2-1, 1.71 GB, last updated 21 May 2026, with a separate arm64 build. Each download shows a SHA256 checksum. Compute yours and compare:

sha256sum proxmox-ve_9.2-1.iso

If the hash does not match the one on the downloads page, delete the file and download again.

Warning: the next command erases the target device completely. dd writes over whatever disk you name, with no confirmation. Run the device check first and confirm the size matches your USB stick.

Proxmox's installation media guide tells you to find the stick by running lsblk before and after plugging it in, and to check that the size matches:

# Before plugging in the USB stick
lsblk
# Plug it in, then run again; the new device is the stick
lsblk

Make sure the stick is not mounted and holds nothing you need. Then write the image (replace /dev/XYZ with the device you just identified, never a partition such as /dev/XYZ1):

dd bs=1M conv=fdatasync if=./proxmox-ve_*.iso of=/dev/XYZ

On macOS, the same guide converts the ISO first and uses diskutil to identify and unmount the stick:

hdiutil convert proxmox-ve_*.iso -format UDRW -o proxmox-ve_*.dmg
diskutil list
# Insert the stick, run again, note the new /dev/diskX
diskutil list
diskutil unmountDisk /dev/diskX
sudo dd if=proxmox-ve_*.dmg bs=1M of=/dev/rdiskX

Proxmox's guide says not to use UNetbootin, which does not work with its image.

Step 2: Install Proxmox VE and fix the package repositories

Boot from the stick and follow the graphical installer. Set a strong root password, a static management IP on the management network, and a real hostname.

After installation, sort out the package repositories. Proxmox VE 9 uses Debian 13 Trixie and the modern deb822 format in /etc/apt/sources.list.d/. The enterprise repository is enabled by default and needs a paid subscription key. Without one, Proxmox's docs say you can add an Enabled: no line to that entry to stop the error messages, and configure the no subscription repository instead. Proxmox describes that repository as suitable for testing and non production use, which fits most home labs.

Disable the enterprise entry in /etc/apt/sources.list.d/pve-enterprise.sources:

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Enabled: no

Add the no subscription repository in /etc/apt/sources.list.d/proxmox.sources, exactly as the Proxmox docs give it:

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

The URI is plain HTTP, but Proxmox's docs explain that Release files are signed with GnuPG and APT verifies them against the keyring the ISO installed. Keep the Debian base and security repositories in /etc/apt/sources.list.d/debian.sources too.

Then update. Proxmox's update guide is explicit about using full-upgrade:

apt update
apt full-upgrade

Proxmox warns that plain apt upgrade can leave the system partially upgraded, because it cannot remove packages to satisfy dependencies. Proxmox also checks for updates daily and emails root@pam.

Step 3: Create an admin account and turn on two factor authentication

Do not do daily work as root@pam. Proxmox's pveum tool creates users, groups and permissions. These examples come from the Proxmox user management docs:

pveum group add admin -comment "System Administrators"
pveum acl modify / -group admin -role Administrator
pveum user add testuser@pve -comment "Just a test"
pveum passwd testuser@pve
pveum user modify testuser@pve -group admin

For a read only account, for example one used by a monitoring tool:

pveum acl modify / -user joe@pve -role PVEAuditor

Then add a second factor from the TFA button in the user list: Proxmox supports TOTP apps, WebAuthn security keys and single use recovery keys, which you should store offline. Eight failed TOTP attempts disable a user's TOTP factors until a recovery key is used or an administrator unlocks them:

pveum user tfa unlock joe@pve

Step 4: Make the bridge VLAN aware

With one physical NIC, a VLAN aware Linux bridge lets each VM sit on its own VLAN while the management IP lives on another. This is the Proxmox network docs' example for putting the management address on VLAN 5, using a VLAN aware bridge; adapt the interface name, VLAN ID and addresses to your plan. The file is /etc/network/interfaces:

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0.5
iface vmbr0.5 inet static
        address 10.10.10.2/24
        gateway 10.10.10.1

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Your switch port must carry the same VLANs as a trunk. Apply the change:

ifreload -a

Keep a local keyboard and screen handy: a typo here locks you out of the web UI. Once the bridge is VLAN aware, each VM's virtual NIC gets a VLAN tag in its hardware settings.

Step 5: Turn on the Proxmox firewall carefully

The Proxmox firewall is completely disabled by default. When you enable it, traffic to all hosts is blocked except some traffic from the local network to the web UI, SSH and other core services. Proxmox's advice is to open an SSH session to the host before enabling it, so you still have access if something goes wrong.

Define who may manage the host with the standard management IP set, then enable the firewall. In /etc/pve/firewall/cluster.fw:

[OPTIONS]
enable: 1

[IPSET management]
10.10.10.50
10.10.11.0/24

Here 10.10.10.50 stands for your admin workstation and 10.10.11.0/24 for the WireGuard VPN subnet. Proxmox's docs list the ports it uses: the web interface on 8006/tcp, the VNC web console on 5900 to 5999/tcp, the SPICE proxy on 3128/tcp, SSH on 22/tcp, and corosync and live migration ports for clusters. None of these should be reachable from the internet. Check the service:

pve-firewall status

Proxmox also offers proxmox-firewall, an nftables based implementation, but labels it a technology preview that is not yet suited for production use. The classic pve-firewall is the safe default.

Step 6: Create an Ubuntu Server VM and harden it

Download Ubuntu Server from ubuntu.com and verify it as Ubuntu's own tutorial describes: fetch SHA256SUMS and SHA256SUMS.gpg from the same release folder, check the signature, then check the hash.

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS
sha256sum -c SHA256SUMS 2>&1 | grep OK

If gpg reports a missing key, Ubuntu's tutorial shows how to fetch the signing keys from keyserver.ubuntu.com and compare their fingerprints before you trust them.

Create a VM on the lab VLAN and install. Then, inside the VM, switch to SSH keys, as Ubuntu's OpenSSH guide shows:

ssh-keygen -t ed25519
ssh-copy-id username@target_machine

Once key login works, set PasswordAuthentication no in a snippet under /etc/ssh/sshd_config.d/ (Ubuntu's guide notes snippets there override the main file), and test before restarting so a typo cannot lock you out:

sudo sshd -t
sudo systemctl restart ssh.service

Host firewall. Ubuntu ships ufw but it is disabled initially. Allow SSH only from your admin machine and the VPN subnet, then enable it:

sudo ufw allow proto tcp from 10.10.10.50 to any port 22
sudo ufw allow proto tcp from 10.10.11.0/24 to any port 22
sudo ufw enable
sudo ufw status verbose

Automatic security updates. Ubuntu's docs say the unattended-upgrades package is installed by default, applies security updates automatically and runs once a day. It does not reboot unless you set Unattended-Upgrade::Automatic-Reboot "true"; in /etc/apt/apt.conf.d/50unattended-upgrades, where you can also set a reboot time. Check what it would do:

sudo unattended-upgrade -v --dry-run

Ubuntu's docs carry a warning that matters for the next step: adding another package repository will not make unattended-upgrades consider it for updates. Docker's packages need their own update routine unless you add Docker's origin to the allowed list.

Step 7: Install Docker Engine in the VM

Use Docker's own apt repository, as in Docker's Ubuntu install guide. First remove distribution packages that conflict:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Add Docker's signing key and repository:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Install and test:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl status docker
sudo docker run hello-world

Our full guide to installing Docker safely on Ubuntu, Windows and Mac covers key fingerprints, the docker group and rootless mode in more depth.

The firewall trap. Docker's packet filtering docs say that when you publish a container port, traffic is diverted in the nat table before it reaches the INPUT and OUTPUT chains ufw uses, so ufw rules are effectively ignored for that port. Publish ports only on the address that needs them (for example -p 10.10.20.10:8080:80 rather than -p 8080:80) and make the Proxmox firewall on the VM's interface the real gate.

Step 8: Set up WireGuard for remote access

WireGuard is a small VPN that runs in the Linux kernel. Ubuntu packages it, and WireGuard's install page gives the command:

sudo apt install wireguard

The cleanest home design, shown in Ubuntu's peer to site guide, runs WireGuard on the router itself and gives VPN clients their own subnet (10.10.11.0/24 in Ubuntu's example). If your router cannot run WireGuard, run it on a small dedicated VM or LXC container and forward a single UDP port to it; Ubuntu's guide has a separate peer to site (inside device) page for that layout.

Generate keys with restrictive permissions, as both WireGuard's quick start and Ubuntu's guide show:

umask 077
wg genkey > laptop-private.key
wg pubkey < laptop-private.key > laptop-public.key
wg genkey > router-private.key
wg pubkey < router-private.key > router-public.key

The home side, /etc/wireguard/wg0.conf, from Ubuntu's example:

[Interface]
PrivateKey = <contents-of-router-private.key>
ListenPort = 51000
Address = 10.10.11.1/24

[Peer]
PublicKey = <contents-of-laptop-public.key>
AllowedIPs = 10.10.11.2

The laptop side, /etc/wireguard/home0.conf:

[Interface]
PrivateKey = <contents-of-laptop-private.key>
ListenPort = 51000
Address = 10.10.11.2/24

[Peer]
PublicKey = <contents-of-router-public.key>
Endpoint = <home-ppp0-IP-or-hostname>:51000
AllowedIPs = 10.10.11.0/24,10.10.10.0/24

Both files hold a private key, so lock them down and bring the interface up:

sudo chmod 0600 /etc/wireguard/wg0.conf
sudo chown root: /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show

A few details from the docs are worth knowing:

• AllowedIPs is both a routing table and an access list. Ubuntu's guide explains that on send it chooses which peer encrypts the traffic, and on receive it drops decrypted packets that do not match. Keep each client's entry to the single address it should use.
• There is no standard port. Ubuntu's docs say you can pick any UDP port. Whatever you pick is the only port your router forwards.
• Your ISP connection matters. Ubuntu's example assumes a routable public IPv4 address that is not behind carrier grade NAT. If your ISP uses CGNAT, inbound connections cannot reach you directly, and you need another path such as IPv6 or a relay you control. If your address changes, you need a dynamic DNS name for the Endpoint.
• Optional hardening. Ubuntu's security tips describe adding a preshared key from wg genpsk, and moving the private key out of the config with a PostUp = wg set %i private-key /etc/wireguard/%i.key line so the config can be shared safely.

For a deeper protocol walkthrough, see our guide on how to set up a VPN with WireGuard.

Step 9: Schedule backups and prove you can restore

Proxmox's vzdump backs up VMs and containers. The examples below come from the Proxmox backup docs. A snapshot mode backup of guest 777 to a mounted backup disk:

vzdump 777 --dumpdir /mnt/backup --mode snapshot

A retention policy that keeps the last three backups, thirteen dailies and nine yearlies:

vzdump 777 --prune-backups keep-last=3,keep-daily=13,keep-yearly=9

In practice, create a scheduled job in the web UI under Datacenter, then Backup. With a Proxmox Backup Server target, Proxmox supports optional client side encryption.

Restore into a new guest ID so you do not overwrite the original:

qmrestore /mnt/backup/vzdump-qemu-888.vma 601
pct restore 600 /mnt/backup/vzdump-lxc-777.tar

Boot the restored copy on an isolated VLAN, check that the data is there, then delete it. Do this at least once a quarter.

Backups: applying 3-2-1 to a homelab

CISA's data backup guidance sets out the 3-2-1 rule: keep three copies of any important file (one primary and two backups), keep them on two different media types to protect against different hazards, and store one copy off site, outside your home.

For a homelab, that maps to:

A snapshot on the same ZFS pool is not a backup, and a target that is always mounted and writable can be encrypted by the same ransomware that hits the lab. CISA also recommends encrypting backups. A rotated removable drive that is unplugged most of the time is a cheap answer; see why offline backups on removable media still matter.

How to access a homelab remotely without exposing it

There are three common ways to reach a home lab from outside:

WireGuard fits because its exposed surface is one UDP port, it stays quiet when unused (its quick start calls it not a chatty protocol), and access is controlled by public keys rather than passwords. Before publishing any web app, read is it safe to self host apps on the internet.

Homelab security hardening checklist

Use this list after the build and again every few months.

1. Default credentials are gone on the router, switch, NAS, UPS card, out of band management controller and every app. CISA notes that default credentials are often published online or printed on the device.
2. Admin interfaces live on the management VLAN, reachable only from your admin device and the VPN subnet, with two factor authentication where supported.
3. The hypervisor is patched with apt full-upgrade on a schedule. If you run Proxmox, watch hypervisor advisories such as the one in our PwnEscape Proxmox VE patch guide.
4. Container images are pinned and rebuilt. Know which tag each service runs, pull updates deliberately and scan images for known vulnerabilities before you deploy them.
5. Firmware is current on the router, switch, NAS, drives and motherboard, from each vendor's own site.
6. Logs go somewhere. Even a simple central syslog VM helps you notice repeated login failures or a container that keeps restarting.

What should you never expose to the internet from a homelab?

The single exception in most labs is the WireGuard UDP port.

Where Safeguard fits, honestly

Safeguard does not install Proxmox, configure your VLANs, manage your router or WireGuard keys, protect your endpoints or inspect firmware. Everything above works without it.

The overlap is the software you run on top: container images and self hosted apps, each carrying operating system packages and open source dependencies with known vulnerabilities. Safeguard scans container images, project directories and SBOM files (for example safeguard scan --image <name> or safeguard scan --dir . from the CLI, with results written as JSON under ./output), matches the components it finds against vulnerability databases, and shows which of your projects contain a given component and version. If you write code in the lab, autonomous remediation can open fix pull requests that bump a vulnerable dependency or base image, and it ships switched off until you turn it on. The local runner lets those scans run on your own hardware. If you are building a lab mainly to practise this kind of work, our walkthrough on building a dependency scanning home lab in an afternoon is a good next step, and setting up a safe home lab for web application testing covers isolation for testing.

Common mistakes

• Buying a loud, power hungry server first. Measure what you need on a mini PC before committing to 300 W of idle draw.
• Port forwarding the Proxmox UI or SSH "just for a weekend". Use WireGuard from day one.
• Leaving UPnP on. It lets software on your network open router ports without asking.
• Trusting ufw to guard Docker ports. Docker's docs say published ports bypass it. Bind ports to specific addresses and filter at the Proxmox firewall.
• Using apt upgrade on Proxmox. Proxmox's docs say to use apt full-upgrade.
• Enabling the Proxmox firewall without an open SSH session. Proxmox's own advice is to keep one open so you can recover.
• Treating snapshots or a second disk in the same box as off site backup. A fire or ransomware takes both.
• Never testing a restore. A backup you have not restored is a hope.
• Forgetting that new apt repositories are outside unattended-upgrades. Docker's packages need their own update plan.

FAQ

What is the cheapest way to start a homelab?

Reuse an old laptop or desktop with an SSD and as much RAM as you can fit, install Proxmox VE or Ubuntu Server, and run a few services. Upgrade only when a real workload outgrows it.

Is a mini PC or a used server better for a homelab?

A mini PC is quieter and much cheaper to run. A used server gives you more RAM slots, ECC memory, more drive bays and out of band management, at the cost of noise and a bigger electricity bill. Run the electricity math above with your local price first.

How much electricity does a homelab use per month?

It depends entirely on average draw. At the July 2026 US average residential price of 18.31 cents per kWh, a 45 W lab costs about $6 a month, a 120 W lab about $16 a month, and a 300 W lab about $40 a month. Measure your own average with a plug in meter over a week.

Is Proxmox VE free to use at home?

Proxmox VE is open source and can be used without a subscription. Without a subscription key you use the pve-no-subscription repository, which Proxmox describes as suitable for testing and non production use. The enterprise repository requires a paid subscription.

Should I run Docker in an LXC container or a VM on Proxmox?

Proxmox's docs say that for use cases demanding maximum isolation, nesting containers inside a QEMU VM remains a recommended practice, and its own OCI application container support is a technology preview. For a home lab, a dedicated Ubuntu Server VM for Docker is the simplest, best documented choice.

How do I access my homelab from outside safely?

Run a WireGuard endpoint on your router or on a small dedicated VM, forward only its UDP port, and connect with key pairs per device. Reach the Proxmox UI, SSH and NAS dashboards only through the tunnel. Do not port forward admin interfaces.

Do I need VLANs for a homelab?

Not on day one, but they are the most useful security upgrade you can make, so a compromised camera cannot reach your hypervisor. You need a VLAN capable router and a managed switch.

What UPS size do I need for a homelab?

Choose a UPS whose watt rating comfortably exceeds the measured draw of everything that must stay up, including the router and switch, and connect its USB or network signal so machines shut down automatically before the battery runs out.

How should I back up a homelab?

Follow CISA's 3-2-1 rule: three copies, two media types, one off site. Schedule vzdump jobs, copy them to an encrypted off site location or a rotated removable drive, and restore one guest every quarter.

Fix it without waiting for upstream

A homelab is mostly a stack of other people's software: the hypervisor, the guest operating systems and every container image and self hosted app you pull. The hypervisor, router and firmware fixes still come from their vendors, but the open source dependencies and container images you build and run are where the steps below apply, and they apply at home just as they do at work.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and asks it to fix the lodash CVE in a repository: the assistant reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. If you write or self host apps in your lab, this is the same flow you would use on the code inside your Docker VM.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. In a homelab, that machine could be the Ubuntu Server VM that runs your containers, so scans of local projects and images happen on your own hardware.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and each command is approved on the phone with Allow once, Allow for turn or Deny. For a lab you reach over WireGuard, it shows how a person can stay in charge of every command that runs on a home machine while away from the keyboard.

Click through it at your own pace, or open it full screen.

To try it on your own lab, download Safeguard from safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• Proxmox VE: Hardware requirements
• Proxmox VE wiki: System Requirements
• Proxmox: Downloads (Proxmox VE 9.2 ISO Installer)
• Proxmox VE wiki: Installation
• Proxmox VE wiki: Prepare Installation Media
• Proxmox VE wiki: Package Repositories
• Proxmox VE wiki: System Software Updates
• Proxmox VE wiki: Network Configuration
• Proxmox VE wiki: Firewall
• Proxmox VE wiki: User Management
• Proxmox VE wiki: Backup and Restore
• Proxmox VE wiki: Linux Container
• WireGuard: Quick Start
• WireGuard: Installation
• Ubuntu Server docs: Introduction to WireGuard VPN
• Ubuntu Server docs: WireGuard VPN peer to site
• Ubuntu Server docs: WireGuard VPN peer to site (on router)
• Ubuntu Server docs: Security tips for WireGuard VPN
• Ubuntu Server docs: OpenSSH server
• Ubuntu Server docs: Firewalls (ufw)
• Ubuntu Server docs: Automatic updates
• Ubuntu tutorial: How to verify your Ubuntu download
• Docker Docs: Install Docker Engine on Ubuntu
• Docker Docs: Packet filtering and firewalls
• US EIA: Electric Power Monthly, Table 5.6.A, average price of electricity by state
• US EIA FAQ: How much electricity does an American home use?
• CISA: Home Network Security
• CISA: Data Backup Options (PDF)

Last reviewed: 23 October 2026. Proxmox VE, Ubuntu, Docker and WireGuard change their install steps between releases, and electricity prices change monthly; check the linked pages before you build.