When Kubernetes Is Overkill: A Process Orchestrator for Homelab
If you have 1–10 machines and your workload is mostly long-running processes (training jobs, browser agents, scrapers, dev servers, AI agents), Kubernetes — even K3s — is overkill. You don't need pod scheduling or service meshes. You need to spawn, supervise, and observe processes across boxes. That's a process orchestrator, not a container orchestrator.
I read every "Kubernetes alternative" article I could find. Best Kubernetes distributions for homelab, Top 13 Kubernetes alternatives, 9 best Kubernetes alternatives. They all map the same ladder: K8s → K3s → MicroK8s → k0s → Nomad → Docker Swarm → Portainer.
The ladder is missing a rung. Below "container orchestrator" there's "process orchestrator" — and for a lot of homelabs, that's the right level.
What a homelab actually runs
Be honest about your workload. Most homelabs run:
- Plex / Jellyfin — long-running daemon
- Pihole / AdGuard — long-running daemon
- Home Assistant — long-running daemon
- Some self-hosted services (Vaultwarden, Immich, Nextcloud) — long-running daemons
- The occasional Python scraper, ML training run, or AI agent — long-running process
Notice what's missing: ephemeral pods, autoscaling fleets, service-mesh sidecars, blue-green deploys, canary rollouts. A homelab doesn't do those things. It runs processes.
The Kubernetes overhead tax
Even K3s — which is genuinely lightweight — adds:
- An etcd cluster (or sqlite if single-node)
- kube-apiserver + scheduler + controller-manager
- kubelet + containerd on every node
- A CNI (flannel by default)
- YAML for everything
- Mental overhead: namespaces, services, deployments, configmaps, secrets, RBAC
For a single-node homelab, the value-to-overhead ratio of all this is poor. Even for 3–10 nodes, unless you're running stateless replicas, most of K3s's cleverness is unused.
The process-orchestrator level
Drop down a layer. What you need:
- A daemon on each machine that exposes "spawn / list / kill / attach"
- One UI that talks to all of them
- Logs / output capture per process
- Auto-restart on crash
- Some sandbox / capability story per process
- Auth so randoms on your network can't drive your machines
That's it. No pod scheduling. No services. No CNI. No YAML.
What this approach gives up
- Auto-scaling. Your homelab doesn't scale; it has the boxes you have.
- Service mesh. Your services talk over a flat L3 network (Tailscale or similar).
- Rolling deploys. You restart the process. It comes back. The downtime is a few seconds.
- Multi-replica fault tolerance. If a box dies, the work on it dies. You restart on another box.
If any of those tradeoffs is unacceptable for your use case, you do need K3s (or higher). For most homelabs, none of them is.
What this approach is good at
- Long-running AI agents. Claude Code, training jobs, browser agents — the daemon supervises one PTY each. Restart on crash. Audit log per process.
- Heterogeneous hardware. An M3 laptop, a beat-up Linux box, a Pi, a GPU rig. Same daemon binary (different arches), same dashboard.
- "Where is that running?" Fleet view sorted by host. Tab-complete agent names in the CLI.
- Privacy. Everything is on machines you own. No cluster control plane in the cloud.
The ladder, complete
| Tool | Right when… |
|---|---|
Bare systemd / launchd | 1 machine, <5 long-running services, you're not afraid of unit files |
| Process orchestrator (Celistra, simpler ones) | 2–10 machines, mostly processes, you want a UI |
| Docker Compose | 1 machine, your services are already containerized |
| Portainer | You're committed to containers, want a Docker Swarm UI |
| Nomad | Mixed workloads (containers, raw binaries, VMs), you don't want K8s complexity |
| K3s / MicroK8s / k0s | You actually want pod scheduling and Kubernetes patterns at small scale |
| K8s | You're doing it for production training, not for homelab |
What we ship
Celistra is the process-orchestrator level. A Go daemon (celistrad) on every machine, a React dashboard talking to all of them, sub-millisecond on LAN, optional tunnel for off-net. Free for 1 node, $2/mo for 5 nodes. Download.
FAQ
Can I run my Plex / Jellyfin under this?
Yes — Celistra spawns any PTY-spawnable process. For long-running daemons that don't need interactive supervision, you'd typically run them under systemd directly and not bother. Celistra is more useful for processes you want to attach to, watch, and approve permissions for.
Does this replace Tailscale?
No. Tailscale is L3 networking (one flat IP space). Celistra is process supervision. They're complementary — Celistra's tunnel is a fallback for off-LAN; Tailscale is the better answer if you've got it.
Why not just use Cockpit?
Cockpit is a system-management UI per host (one URL per machine). Celistra is one URL for all hosts and is process-shaped, not system-shaped. They're solving different problems.
What about high availability?
Process orchestration as described doesn't give you HA — when a host dies, processes on it die. If you need HA, you need replicas, and you need a real orchestrator (Nomad, K3s, or up). Be honest about whether you need it.