Homelab for DevOps in 2026: Mini PC vs Raspberry Pi, k3s vs Talos

Most of what I know about running Kubernetes I learned by breaking it somewhere nobody else could see. A homelab is still the cheapest place to do that, and in 2026 the choices have shifted: a 16GB Raspberry Pi 5 now costs $385, RAM prices have pushed every small computer up, and the cloud free tiers have quietly changed shape. This post is a practical guide to a homelab for DevOps learning: which hardware to buy (or not buy), whether to put Proxmox underneath, k3s vs Talos vs MicroK8s, what electricity actually costs, and which projects teach the skills employers ask about. If you want to skip to building, the paired guide, How to Build a k3s Kubernetes Cluster at Home, walks through every command.

Do you still need a homelab to learn DevOps in 2026?

You do not need one to learn kubectl. kind (v0.33.0, August 2026) runs a whole cluster in Docker on a laptop, and the walkthrough in deploy your first app on kind covers that path. What a laptop cluster cannot teach is the boring physical layer that causes real outages: a node that loses power mid-write, a disk that fills, an IP address your DHCP server hands to something else, an upgrade that runs while a workload is still on the node. Those are the failure modes interviewers ask about, and they only show up when there are separate machines with separate disks.

The other argument is time. A cloud lab costs money per hour, so people tear it down every evening and never get to the part where a system has been running for three months and something has drifted. A homelab stays up. That is the point. The stuff you learn from a long-running system (certificate expiry, log volumes, backup restores you actually test) is the stuff that separates an operator from someone who has done tutorials. The DevOps roadmap for 2026 leans on exactly those skills, and AI assistants have not made them less necessary; they have made it easier to generate YAML you do not understand, which raises the value of having somewhere safe to run it first.

Mini PC vs Raspberry Pi vs old laptop: which hardware?

Here is how the three common options compare on the things that matter for a Kubernetes lab.

Option	CPU and RAM	Storage	Power notes	Main drawback	Source
Raspberry Pi 5	Quad Cortex-A76 at 2.4GHz, 1 to 16GB LPDDR4X	microSD, or NVMe via the PCIe 2.0 x1 port and an M.2 HAT	Needs a 5V 5A (27W class) USB-C supply	16GB model $385 since 2 November 2026; ARM-only images	Raspberry Pi, CNX Software
Intel N100 mini PC	4 cores, 4 threads, Intel lists max memory as 16GB	Usually one NVMe slot, sometimes a SATA bay	6W TDP processor	Single NIC on most models, RAM capped low	Intel ARK
Old laptop	Whatever you have; often 4 cores, 8 to 16GB	SATA or NVMe SSD	Built-in battery acts as a small UPS	Unknown idle draw, worn batteries, lid and sleep settings	your own plug meter

The Raspberry Pi used to be the default answer because it was cheap. It is not cheap any more. Raspberry Pi's own February 2026 notice added $30 to every 8GB board and $60 to every 16GB board, and later rounds pushed the 16GB Pi 5 from its $120 launch price to $385, according to CNX Software. Once you add an NVMe HAT, an SSD, a proper power supply and a case, a three-node Pi cluster costs more than three used x86 mini PCs in most markets. There is also a storage trap: the k3s requirements page says etcd is write-intensive and that SD cards and eMMC cannot handle the I/O load, so a Pi that is a control-plane node needs an external SSD anyway.

Pis still make sense for one thing: learning ARM. If you want to practise multi-arch images (see building amd64 and arm64 images with Buildx), a single Pi as an agent node in an otherwise x86 cluster is a good teacher.

For most people I would buy used small-form-factor or mini PCs with an x86 CPU, an NVMe slot and at least 16GB of RAM. The N100 class is power-efficient, but note Intel's stated 16GB memory ceiling; if you want to run Proxmox with several VMs per box, an older business mini PC with two SO-DIMM slots and 32GB or more is the better buy. An old laptop is the zero-cost option and perfectly fine for a single-node cluster. Measure it first.

What does a homelab cost in electricity?

This is the number people guess at and rarely work out. The US Energy Information Administration's Electric Power Monthly, released 23 October 2026, puts the average US residential price for August 2026 at 18.16 cents per kWh. One watt drawn continuously for a year is 8.76 kWh, so every watt of average draw costs about $1.59 a year at that price. Your local rate will differ, sometimes by a factor of two, so plug in your own.

The arithmetic makes the choice obvious. Three small nodes averaging 10 watts each cost about $48 a year. A retired tower server or a desktop with a discrete GPU idling at 100 watts costs about $159 a year before it does anything useful, and makes noise. Buy a plug-in power meter before you buy anything else; it is the first piece of observability in the lab.

Proxmox or bare metal underneath?

Proxmox VE 9.2, released 21 May 2026, is the default hypervisor in homelab circles for good reason: it is free to use, runs VMs and LXC containers, and makes snapshots trivial. Proxmox VE 8.4 only received security and critical fixes until August 2026, per the 9.0 announcement, so start on 9.x.

The case for Proxmox is that a VM snapshot is the best undo button you will ever have. Before you try an etcd restore or a risky upgrade, snapshot the VMs, break things, roll back. You can also run a three-node control plane on one physical box, which teaches quorum without buying three machines (it does not teach hardware failure, obviously).

The case for bare metal is simpler: fewer layers, all the RAM goes to Kubernetes, and you learn the node OS properly. My rule: one physical machine, use Proxmox and make VMs; three or more machines, install the Kubernetes distribution directly and use the spare box for Proxmox and the "everything else" services (DNS, a Git server, backups).

k3s vs Talos vs MicroK8s: which Kubernetes for a homelab?

All of these run upstream Kubernetes APIs, so what you learn transfers. The differences are in how you manage the node.

Distribution	Latest release checked	How you manage nodes	Good for	Source
k3s	v1.37.2+k3s1 (3 Nov 2026), Kubernetes 1.37.2	Single binary under 100MB on any Linux; systemd service; config file	Learning on hardware you already have; ARM; fast rebuilds	GitHub, docs
Talos Linux	v1.14.5 (26 Oct 2026)	Immutable OS, no SSH or shell, gRPC API with mTLS	Practising declarative, GitOps-style node management	GitHub, Sidero Labs
MicroK8s	snap stable channel at v1.36.2	Snap package with add-ons on Ubuntu	Ubuntu shops; one-command add-ons	GitHub
kind	v0.33.0 (26 Aug 2026)	Clusters as Docker containers	Throwaway clusters on a laptop, CI	GitHub

k3s is what I would start with. It bundles containerd, Flannel, CoreDNS, Traefik, ServiceLB, a network-policy controller and the local-path provisioner, per the docs, so a fresh node has working ingress, load balancing and storage within a minute or two. The v1.37.2+k3s1 release ships Traefik v3.7.15, containerd 2.3.7, etcd 3.7.1 and the Gateway API CRDs, which matters now that Ingress NGINX is retired and Gateway API is what you should be practising. You still SSH in, read journald and poke at the filesystem, which is exactly what you want while learning.

Talos is the better second step. Sidero Labs describes it as "No SSH, no shell, no package manager", with fewer than 50 binaries on the node. That forces you to treat nodes as declarative config, which is how good production platforms work. It is also frustrating the first week, because the debugging habits you built on Ubuntu do not apply.

MicroK8s is fine if you live on Ubuntu, but at the time of writing its snap stable channel was a minor release behind (v1.36.2, while upstream Kubernetes 1.37 shipped on 26 August 2026).

A minimal k3s server config for a lab looks like this. Pin the version; "latest" in a lab is how you lose a Saturday.

# /etc/rancher/k3s/config.yaml on the first server (k3s v1.37.2+k3s1)
# Install with:
#   curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.37.2+k3s1" sh -s - server
cluster-init: true            # embedded etcd, so you can add servers later
write-kubeconfig-mode: "0640" # do not make the admin kubeconfig world-readable
tls-san:
  - "k3s.home.arpa"           # a DNS name you control, for a stable API address
disable:
  - servicelb                 # we will use MetalLB instead (see the guide)
etcd-snapshot-schedule-cron: "0 */6 * * *"  # default is every 12 hours
etcd-snapshot-retention: 10                  # default keeps 5 per server

What should you practise in a DevOps homelab?

Hardware is the easy part. The value is in the projects, and the ones that pay off are the ones that mirror production work:

1. GitOps from day one. Put every manifest in a Git repository and let Argo CD or Flux apply it. Rebuild the cluster from scratch once a month. If it does not come back from Git alone, you have found your undocumented state.
2. Observability. Install kube-prometheus-stack, then write one alert that would have woken you for a real problem in the lab (disk above 85 percent on a node is a good first one). Add logs once metrics are boring.
3. Backups you restore. k3s takes etcd snapshots at 00:00 and 12:00 and keeps five per server by default, per the etcd-snapshot docs. That protects the cluster state, not your volumes. Add Velero or Longhorn backups to an off-box target, then do a restore drill onto a freshly built cluster.
4. Upgrades. Use the system-upgrade-controller to move one minor version at a time, and watch what drains, what restarts, and what breaks.
5. Storage. Learn why a database on local-path storage dies with its node, then try Longhorn. Longhorn 1.13 requires Kubernetes 1.34 or later, so this also teaches reading release notes before upgrading.
6. Security basics. Network policies, Pod Security admission and secrets that do not live in Git in plain text.

Homelab vs cloud free tier: which is better for learning?

Use both. They teach different things.

Provider	What is free now	Catch	Source
AWS	Free plan with $100 in credits, up to $100 more for exploring services, for 6 months	Account closes after 6 months or when credits run out unless you upgrade	AWS Free Tier
Google Cloud	$300 credit for 90 days; one e2-micro VM in three US regions; one free Autopilot or zonal Standard GKE cluster fee per month	GKE credit covers the cluster fee only, not nodes	Google Cloud docs
Oracle Cloud	Ampere A1: 1,500 OCPU hours and 9,000 GB-hours a month (2 OCPUs, 12GB); 200GB block storage	Instances under 20 percent CPU, network and memory over 7 days can be reclaimed	Oracle docs

If you have seen older blog posts promising four free Ampere cores and 24GB on Oracle, note that the current documentation lists half that. The cloud teaches IAM, managed services, networking at a provider's scale and, most importantly, how billing surprises happen. The homelab teaches the layers the cloud hides. If you go the cloud route, start with a securely set up AWS account and a budget alert before you launch anything.

FAQ

What is the cheapest way to build a Kubernetes homelab?

An old laptop or desktop you already own, running a single-node k3s server. It costs nothing up front, and at the August 2026 US average residential price each watt of continuous draw costs about $1.59 a year. Add more nodes only when you want to practise multi-node failure and upgrades.

Is a Raspberry Pi 5 good for a Kubernetes cluster in 2026?

It works, but it is no longer the budget choice: the 16GB model costs $385 after the 2 November 2026 increase. Control-plane nodes also need an SSD rather than an SD card because etcd is write-heavy. One Pi as an ARM agent node in an x86 cluster is a sensible compromise.

Should I use k3s or Talos for my homelab?

Start with k3s if you are still learning Linux and Kubernetes together, because you can SSH in and see everything. Move to Talos when you want to practise fully declarative, API-managed nodes with no shell. Both run current Kubernetes releases.

How many nodes do I need?

One node teaches you Kubernetes objects. Three server nodes are the minimum for an embedded etcd cluster that survives losing one, because k3s requires an odd number of servers for quorum. Agents can be added in any number.

My plan for this quarter, if I were starting from zero: two or three used x86 mini PCs with NVMe and 16GB or more each, k3s v1.37.2 with embedded etcd, MetalLB, Argo CD, kube-prometheus-stack, and an etcd snapshot copied off the cluster every night. Then a monthly rebuild-from-Git drill, because a homelab that you are afraid to wipe has become a pet, and the whole point was to learn to run cattle. The step-by-step build is in the k3s homelab cluster guide.

Related: Is Kubernetes Still Worth It in 2026?, How to Set Up Argo CD for GitOps and Kubernetes Storage Explained.