VPS & K3s

Everything in this fleet runs on one machine — a single Hostinger VPS running single-node Kubernetes (K3s). There’s no multi-node cluster, no managed Kubernetes offering, and no Terraform anywhere in this stack — the machine is set up and configured with Ansible.

Setup

Three Ansible playbooks handle everything, run in order: one hardens the machine (firewall, intrusion protection, automatic security updates with reboot deliberately disabled — a surprise reboot would take the whole cluster down), one installs K3s itself, and one registers this machine as a GitHub Actions build runner so app repos can build container images directly on it. See CI/CD for what that runner does.

The Kubernetes API is never public

kubectl and similar tools never reach this cluster over the open internet — access is only through an on-demand SSH tunnel to the machine itself. This was a deliberate choice for a single-operator setup: no extra always-on networking layer, just SSH when it’s actually needed.

Capacity

The machine is modest (2 vCPU / 8GB), and an early open question was whether that’s enough for everything running on it. It has held up fine under real use.

Recovery

The firewall’s intrusion-protection can lock out even a legitimate operator after a few failed login attempts. Recovery goes through the hosting provider’s own web console rather than SSH — a separate path that isn’t affected by the lockout.