Cross-cluster communication

Services in one cluster talking to services in another—securely, without opening the whole internet. When you have multiple clusters (e.g. dev in one region, staging in another, or different teams on different infra), you often need workloads in cluster A to reach workloads in cluster B. Kaja is building a service mesh on WireGuard with strong network policy so that cross-cluster communication stays secure, observable, and on the infra you bring. This page explains where we are and where we're headed.

What you get (today and soon)

• Within one cluster — Today you can control which environments talk to which. You set allow ingress/egress between environments and expose specific Helm apps so only the right envs can reach them. So intra-cluster communication is already configurable from the dashboard. See Environments, Apps, and Helm.
• Reaching a cluster (private clusters) — If a cluster has no public IP, you can use a secure tunnel (e.g. Cloudflare tunnel) so you—or your users—can reach the apps running there. No VPN to manage yourself, no open firewalls. That's about access to the cluster, not yet service-to-service across clusters.
• Cross-cluster service-to-service (coming) — We're building a service mesh with WireGuard so that services in cluster A can talk to services in cluster B over an encrypted mesh, with strong network policy so you decide who can reach what. All on your infra; no data crossing our network. That's the true cross-cluster story—and we'll share more as it lands.

So: today you get control inside a cluster and secure access to private clusters; soon you get native, secure cross-cluster communication between services.

Why it matters

• Multi-cluster without the mess — Run dev in one place, staging in another, or split by team—and still have services talk when you need them, without exposing everything to the internet.
• Security by default — The mesh and network policy keep traffic encrypted and scoped. You define which clusters (and which workloads) can talk to which.
• Your infra — The mesh runs on the clusters you connect; we don't sit in the middle. Bring your own infra, keep control.

Where we're headed

We're building a multi-cluster architecture that includes:

• Service mesh on WireGuard — Encrypted, performant links between your clusters so services can discover and call each other across clusters.
• Strong network policy — You define which namespaces or workloads in one cluster can talk to which in another. No need to open broad ranges or rely on manual firewall rules.
• One place to configure it — Same Kaja dashboard you use for environments and apps; cross-cluster policy and mesh config in one place.

This is in development. For the latest, see Architecture (Where we're headed) and the product updates we share as we ship.

Secure access (devices) vs cross-cluster (services)

Two different but related ideas:

• Secure access & VPN — You create devices (e.g. your laptop, a CI runner) and connect them to a cluster via our built-in VPN (WireGuard). You then access the services you've exposed—from your machine or pipeline. So: you or your device reaching the cluster. See Secure access & VPN.
• Cross-cluster communication — Services in cluster A talking to services in cluster B (e.g. API in prod calling a shared service in another cluster). That's the service mesh + WireGuard story we're building. So: workload to workload across clusters.

Both use WireGuard and strong policy; one is "device → cluster," the other is "cluster ↔ cluster" for services.

Summary

Cross-cluster communication—secure, on your infra, configured from one place. We'll share more as the mesh and policy features land.

Next steps

• Architecture — How Kaja fits together and where we're headed (mesh, WireGuard).
• Secure access & VPN — Connect your devices to the cluster and access services.
• Environments — Where apps run; Apps — Configure and expose apps within a cluster.
• Connecting clusters — Add the clusters that will participate in the mesh later.