Multiple Clusters and Regions

Place Swytch beside applications in each cluster or region. Share the keys those applications need while keeping the client endpoint local.

1. Install one operator per Kubernetes cluster.
2. Use a common Swytch identity for peers that should share state. Cloud profiles use the same connection secret; DNS profiles use a matching passphrase.
3. Provide discovery and peer addresses reachable from every participating network.
4. Allow QUIC peer traffic and verify it in both directions before moving application traffic.

The operator advertises Pod IPs on UDP 7379. A cluster-local headless Service does not provide cross-cluster routing. Cloud supplies discovery and storage, but does not make private Pod networks routable. Use a network topology with reachable Pod addresses for this operator workflow.

For manually managed servers behind NAT, standalone cluster configuration documents --cluster-advertise. Do not assume the operator exposes every CLI setting.

A region-specific working set need not become globally shared just because the deployment spans regions. Access patterns determine subscriptions. Transactions involving globally shared keys pay for their relevant subscribers.

Measure first-read latency, shared transaction latency, and recovery after link loss. See local and distributed keys and partition behavior.

Multiple regions do not guarantee that each key has a holder in each region. Use Cloud storage for recovery of acknowledged uploads after all holders disappear, and verify your recovery path before regional maintenance.

If you’re multi-region, please reach out to us at hello@getswytch.com – We’re interested in your use-case and would love to help.