Why bex needs this
bex is a self-hosted Render alternative running on machines you own (Docker mock locally, Hetzner in production). Three factors make a flat network risky:
- Multiple trust domains. The infra cluster (Cluster API, can create/destroy machines) must stay unreachable from the app cluster, which runs arbitrary user workloads from git pushes. A compromised tenant workload shouldn't have a path to infrastructure control.
- Agents as first-class users. bex's API is bearer-authed REST/GraphQL, driven end-to-end by agents. Bearer tokens leak into logs and context windows. Binding identity to device/node (WireGuard keys) rather than a bearer string alone limits the blast radius of a leaked credential.
- No cloud-native isolation on bare metal. Control-plane components (operator, Postgres, Zot registry) should never touch a public interface. An overlay like Tailscale gives encrypted mesh connectivity, ACLs-as-code, and identity-based access without opening ports — and behaves identically on a laptop mock and on production Hetzner nodes.
Recommended segmentation
Put the infra cluster, app-cluster control plane, build/registry plane, and Postgres control plane on a private tailnet, each in its own ACL group. User Apps remain public only via ingress (<name>.onbex.co). Developers and CI join via short-lived node keys instead of bastions or exposed kubeconfigs.
Exposing internal servers (e.g., shared MCP servers)
- Run the service as a tailnet node (Tailscale sidecar/K8s operator) — private DNS name, no public IP.
- Gate access with ACL groups (devs, CI, agent hosts), not tokens alone.
- Layer identity headers on top for per-user/per-agent authorization.
- Apply the same pattern to Grafana, the registry, and kubeconfig access.
Bottom line
With asymmetric-privilege clusters and agent-driven APIs, the network can't be the trust boundary by default. A zero-trust overlay segments infra from app planes and exposes internal services like MCP servers only to the parties that need them.
Why bex needs this
bex is a self-hosted Render alternative running on machines you own (Docker mock locally, Hetzner in production). Three factors make a flat network risky:
Recommended segmentation
Put the infra cluster, app-cluster control plane, build/registry plane, and Postgres control plane on a private tailnet, each in its own ACL group. User Apps remain public only via ingress (
<name>.onbex.co). Developers and CI join via short-lived node keys instead of bastions or exposed kubeconfigs.Exposing internal servers (e.g., shared MCP servers)
Bottom line
With asymmetric-privilege clusters and agent-driven APIs, the network can't be the trust boundary by default. A zero-trust overlay segments infra from app planes and exposes internal services like MCP servers only to the parties that need them.