Jonathan

Commented on Staxa · Nov 3, 2026

Hey, sorry about the late reply I just got a chance to get to this. The honest answer is that it depends on the layer. Staxa runs on a single node right now, and it's a deliberate choice. At current load, a multi-node HA cluster would be paying for redundancy before there’s traffic to justify it, so maintenance today is a short scheduled window that affects every tenant at once. The tenant model was built so that changes with capacity, not a redesign, and the plan to get there is written down. What limits the impact on the shared kernel today: each tenant gets its own namespace with a ResourceQuota, Pod Security baseline enforcement, default-deny NetworkPolicies (tenants can’t reach each other or private ranges), no service-account tokens in tenant pods, and builds run in a separate locked-down namespace. A noisy tenant can’t starve the others, but a node event is still shared. When usage warrants it: - Cordon, then roll instead of evict. Tenant Deployments already roll with maxSurge 1 / maxUnavailable 0, so after cordoning a node, a rolling restart brings each replacement up elsewhere before the old pod stops. Even single-replica apps move without downtime, one node at a time. - Topology spread so a tenant’s services don’t all land on the same node. - Tenant databases on network-attached volumes instead of node-local disk, so they can follow their pod. That’s the main piece of work, and it’s scoped. Stronger kernel isolation (gVisor or Kata) as an opt-in for tenants who need it. Happy to go deeper if you're interested.

Commented on Staxa · Oct 23, 2026

Hello DevHunt community! I built Staxa to give your customers their own isolated app, database, subdomain and SSL, all managed per‑tenant in a dedicated Kubernetes namespace. You can spin up a tenant from the dashboard or from the management API, and the free tier includes two tenants. Would love your thoughts 😊