▚ xentropy
← All posts
Jan Pruszynski

Running production on a single k3s node

Notes on moving the xentropy stack off managed Kubernetes and onto a lean, self-hosted k3s cluster — and what we'd do differently.

We moved the production stack off managed Kubernetes onto a single self-hosted k3s node. This is a short field report on why, and the sharp edges worth knowing before you try the same.

Why

Managed control planes are convenient until the bill arrives. For a workload that comfortably fits one well-specced box, the economics flip hard. k3s gives you a real, conformant Kubernetes API with a fraction of the overhead.

The sharp edges

A few things that cost us time:

  1. Storage. No cloud volume provisioner out of the box — you own the local-path lifecycle and your own backups.
  2. NetworkPolicy defaults. A default-deny policy will silently break in-cluster service calls until you allow-list them explicitly.
  3. Ingress + certs. Wire up cert-manager early so Let's Encrypt renewals aren't a manual chore.
# One-liner to see everything that's actually running
kubectl get pods -A --field-selector=status.phase!=Running

Would we do it again

Yes — with eyes open. The savings are real, but "single node" means the node is your blast radius. Snapshots and a tested restore path are not optional.