The idea, and why it fits
The platform was built provider-agnostic. The Terraform cluster module literally says retargeting means "replace the resources here while keeping the same module interface." Swapping managed EKS for self-managed K3s on Contabo is exactly that swap — and the region model is already in the data layer (servers.region).
- HTTP origin reached via Cloudflare Tunnel (dials out) — no cloud LB needed.
- Operator + DragonflyDB + Velocity pattern is per-cluster already.
- Cloudflare DNS/Workers/R2 + Upstash stay global, untouched.
- R2 is zero-egress object storage reachable from any region.
- Minecraft edge LB (AWS NLB) → MetalLB / kube-vip on the server's public IP.
- Secret store: AWS IRSA → 1Password / Vault (templates exist).
- Policy-enforcing CNI (Calico/Cilium) — Flannel won't enforce NetworkPolicy.
- World PVCs: EBS → Longhorn / local-path.
- − Self-managed control plane, etcd, OS patching, bare-metal net.
- + 3–5× lower cost at equal RAM (the binding constraint).
- + Unlimited egress, included NVMe, provider independence.
- + Clean multi-region the data model already anticipates.
Global brain, regional muscle. A single global control plane (API · Postgres · billing · auth) plus one self-contained K3s data plane per Contabo region (operator · Velocity edge · DragonflyDB · tenants). Control is global & consistent; play is regional & local — a player's packets never leave their region; a billing event is never region-ambiguous.
Naming: the provider is Contabo (German budget host, ~9 global regions). "Cantabo" is a common misspelling. The design works on any API-driven bare-metal host (Hetzner, OVH, Latitude.sh).
Topology
Toggle between today's single managed cluster and the proposed multi-region K3s layout. Notice what moves and what stays put.
Cloudflare zone, the three Workers (gateway/status/webhooks), R2 buckets, Upstash, and the control-plane API + Postgres. Adding a region does not touch any of these.
A full K3s cluster: 3 HA server nodes (embedded etcd), N agent nodes for RAM-bound game servers, the operator, DragonflyDB, the Velocity proxy fleet, and a regional worker for backups.
Request flow: connect & wake
A player connects to a hibernated server in their region. Step through what happens — nothing on this hot path crosses a region boundary except the single idempotent wake call.
Global vs Regional
The single most important design decision. Filter the inventory — get this split right and everything else follows.
Mental model: control = global & consistent; play = regional & local. Anycast for a single hostname across regions would be wrong here — a Minecraft world is stateful and lives in one place. Route to where the world is, and place it well at creation.
Contabo footprint
Click a region to inspect its K3s cluster. Start with 2–3 and expand on demand; servers.region keys map 1:1 to these clusters.
Cost model
Minecraft is RAM-bound and egress-heavy — exactly where bare metal wins. Drag the sliders; figures are indicative, confirm against live pricing.
EKS: control-plane fee + EC2 (m6i, ~64 GB/node) + EBS + NAT + NLB + egress over free tier. Contabo: AMD EPYC bare metal (RAM included, NVMe included, unlimited egress, no NAT/LB fee).
Part of the delta is ops labor you now own (control plane, storage HA, networking). Budget engineering time, not just euros.
Open decisions
Resolve these before the single-region pilot. Recommendations in green.