Platform

Workload connectivity

When service B talks to service A, it should know exactly who it's talking to — whether they're in the same rack or different clouds.

Service-to-service, the hard way

mTLS everywhere

Works, but every team maintains cert rotation, SANs, and sidecars. The complexity tax compounds per service.

Private links by the meter

Cloud provider interconnects are reliable — and billed per GB and per hour, in every direction, forever.

Flat internal networks

"Internal" segments where any workload can reach any other. Lateral movement stays trivial.

Workloads on the tailnet

Named identities per workload

Each service is a first-class tailnet node with a stable name and identity — not just an IP that changes on redeploy.

AmneziaWG between everything

Every connection encrypted end-to-end, regardless of the underlying network — same DC, cross-cloud, or cross-continent.

ACLs instead of hope

Only the payment service reaches the payment DB. Policies express service topology, versioned in Git.

Direct paths, default

Peer-to-peer when routable, NAT-traversing when not, relayed only as fallback. No hair-pinning through a hub.

Container-native

Sidecar or CNI plugin modes for Docker and Kubernetes — pods get identities without host-level changes.

Humans ride the same rail

Operators debug workloads over the same identity-aware network — same ACLs, same audit trail.

Where teams use it

Cross-cloud service graphs

Frontend in one cloud, worker fleet in another, database in a third — connected privately, no transit costs.

Legacy + modern bridge

The COBOL box in thecolo talks to the new k8s service securely, without a week of firewall tickets.

Services that know each other