Container Orchestration

This is the page to read most skeptically. Orchestration is the default "next step" people reach for once they've heard of it, and it's the one most likely to add real complexity to a homelab without a corresponding real benefit. Read the whole page before deciding you need this.

What orchestration actually solves

Kubernetes and Docker Swarm both solve the same core problem: given a fleet of machines, automatically schedule containers onto them, restart failed containers, move containers off a dead node, and load balance across replicas - without a human deciding where each container runs. That's genuinely valuable when you have enough nodes and enough services that manual placement is untenable, or when you need a service to survive a single node failure without you noticing.

What most homelabs actually have

A handful of services, on one to three Proxmox VMs, run by one person who already knows exactly where everything is because they put it there. In that situation, the problem orchestration solves doesn't really exist yet - you don't need automatic scheduling across nodes you can count on one hand, and you already have the mental map an orchestrator exists to replace.

The realistic alternative: Compose across a couple of VMs

For most homelabs, "orchestration" needn't mean Kubernetes at all - it means two or three Proxmox VMs (see Proxmox VMs and Containers), each running its own docker compose stack, fronted by a shared reverse proxy (see Reverse Proxy and TLS). If one VM's host node dies, the HA setup from Proxmox Clustering and HA restarts the whole VM elsewhere - coarser-grained than per-container failover, but far simpler to reason about and covers the failure mode that actually happens at home (a node going down), not the ones orchestration is really built for (rolling out changes to hundreds of replicas, autoscaling under variable load).

If you still want it: Swarm vs. k3s

If you've decided you want the orchestration experience itself - learning it, or genuinely running enough services that scheduling matters - two realistic options:

• Docker Swarm - built into the Docker Engine you already run, no new tool to install, and it understands your existing Compose files almost as-is (docker stack deploy -c docker-compose.yml mystack). The lowest-friction way to get multi-node container scheduling if you're already comfortable with Compose.
• k3s - a lightweight, single-binary Kubernetes distribution (Rancher/SUSE) built for edge and resource-constrained environments, much lighter than full upstream Kubernetes. The better choice if your actual goal is learning Kubernetes itself - it's the same API and concepts, just a smaller footprint - since Kubernetes skills and ecosystem (Helm charts, the broader tooling) transfer to jobs and projects in a way Swarm's don't.

Full upstream Kubernetes (kubeadm, or a managed-feeling distro like RKE2) is realistic for a homelab only if you specifically want production-grade Kubernetes experience - it's a heavier operational burden than k3s for no homelab-specific benefit.

Resource and complexity expectations

• Swarm: minimal overhead beyond Docker itself; a 3-node swarm with modest VMs (2 vCPU / 4GB RAM each) is comfortable.
• k3s: lighter than full Kubernetes but still meaningfully more than Swarm - budget at least 2 vCPU / 4GB RAM per node before adding workloads, more for the control-plane node(s).
• Both require you to learn a new deployment vocabulary (services, stacks, and overlay networks for Swarm; pods, deployments, services, and ingress for Kubernetes) on top of everything else in this tier. That's a genuine ongoing cost, not a one-time setup tax.

Version note: Kubernetes' API deprecates fields on a roughly year-long cycle, and k3s tracks upstream releases closely - a homelab cluster left unpatched for a year or two will likely need manifest changes to upgrade cleanly, not just a version bump.

If, after all that, your honest answer is "I just want my Compose stacks to survive a node dying" - that's what HA VMs already give you. Save orchestration for when you actually hit its problem.

Next: GitOps for Homelab.