# Multi-cluster deployment — Use case > Run one control plane and many data planes — across regions, environments, and providers. Promote definitions once; clusters pick them up wherever they live. *Platform teams · Topology · For platform teams* ## One control plane. As many data planes as your operators need. Region, environment, edge, DR — Apinizer's Manager publishes once and every Worker cluster picks it up. Active/active or active/passive, on the Kubernetes you already run. [Request a demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## The problem *The problem* ### Most gateways are single-cluster animals. When you add a region, a DR site, or a partner edge, the gateway needs to come with you — and so does every policy, every secret, every transform. Teams improvise with a second installation, a manual export, and a prayer. Apinizer treats topology as a first-class concern: one Manager, many Workers, one published source of truth. --- ## Capabilities ### Manager / Worker split Control plane is one Manager. Data plane is N Workers. Policies and definitions publish to every Worker; the Manager never sits in the runtime path. ### Region-aware routing Pin endpoints to the cluster closest to the user — domestic, cross-border, and partner-edge — and let the Manager keep them in lockstep. ### Environment isolation Dev, test, staging, DR — every environment is its own Worker cluster with its own secrets, variables, and policies, but the same definition source. ### Active/active failover Workers run side-by-side. When one drops, traffic shifts; when it comes back, it resyncs from the Manager. No manual reconciliation, no drift. ### Hybrid + remote deploy Managed control plane in your central cluster; Workers anywhere — partner data centers, edge sites, even air-gapped operators with the remote deploy pattern. ### Promote with one apply APIops manifests describe the topology. Promotion is the same apply you use for code — every Worker picks it up on the next reconcile. --- ## Real-world examples ### Government **Scenario:** National e-government portal runs Manager in Ankara, Workers in 7 regions **Outcome:** Citizen-facing APIs serve from the nearest data center. The Manager in Ankara stays out of the request path; Workers reconcile every minute. **Metric:** 7 regions, 1 Manager ### Automotive **Scenario:** Connected-vehicle OEM ships APIs to 4 regional clusters **Outcome:** Four data centers run identical Workers. A vehicle that crosses a border doesn't notice — and neither does the SLA. ### Banking **Scenario:** Riyadh Tier-1 bank meets sovereign hosting with regional DR **Outcome:** Primary Workers in Riyadh, DR Workers in Jeddah. The Manager publishes to both; a regional outage flips traffic in under a minute, with full audit continuity. **Metric:** <60s RTO ### Retail **Scenario:** Warsaw retailer brings up store-edge Workers for in-store APIs **Outcome:** Each store gets a tiny Worker on the local cluster — POS, inventory, queue. The central Manager owns the policy; stores keep serving even if WAN drops. ### Logistics **Scenario:** Cross-border carrier runs partner-edge Workers in 12 regions **Outcome:** Customs and tracking APIs deploy to partner data centers with the remote deploy pattern. Partners never get root; the Manager pushes definitions and watches health. **Metric:** 12 partner regions ### Telecom **Scenario:** Madrid carrier runs active/active across Madrid + Barcelona **Outcome:** Both clusters carry production traffic. When Barcelona drops during a fibre cut, Madrid absorbs 100% within the gateway's heartbeat window. ### Energy **Scenario:** Stockholm utility separates SCADA APIs from public APIs by cluster **Outcome:** Operator network and citizen network share a Manager but never share a Worker. Definitions are the same; policies and reachability are not. ### Public sector **Scenario:** Baku ministry promotes manifests across dev / test / prod with one command **Outcome:** Each environment is its own Worker cluster, its own namespace, its own secrets. The promotion path is reviewed in Git; nobody touches kubectl after midnight. --- ## Manager publishes. Workers reconcile. You sleep. - **01 · Install Manager** — One control plane on the cluster of your choice — central data center, primary region, anywhere with Kubernetes. - **02 · Register Workers** — Bring up Worker clusters in the regions and environments you need. They register with the Manager over a secure channel. - **03 · Publish** — Apply a definition once. Every registered Worker picks it up on the next reconcile loop — no manual sync, no drift. - **04 · Operate** — Watch health, traffic, and lag in the Manager. Promote across environments with one apply; clusters pull when ready. --- ## Recommended modules - [API Gateway](https://apinizer.com/products/api-gateway) — The Worker that runs everywhere — your central cluster, regional edges, partner data centers. - [Analytics Engine](https://apinizer.com/products/analytics-engine) — Per-cluster, per-region traffic and health — one view across every Worker. - [Cache](https://apinizer.com/products/cache) — Distributed cache that survives Worker reschedules and stays coordinated across regions. - [Monitoring](https://apinizer.com/products/monitoring) — Uptime probes from each region; alarms that escalate when a Worker falls behind. --- ## Resources - [Multi-cluster topology](https://docs.apinizer.com/en) — Manager / Worker split, environment isolation, and active/active patterns. - [Architecture overview](https://docs.apinizer.com/en/concepts/architecture) — How the control plane and data plane fit together on Kubernetes. - [Cache](https://apinizer.com/products/cache) — Hazelcast-backed distributed cache with coordinated invalidation across Workers. - [Analytics Engine](https://apinizer.com/products/analytics-engine) — Real-time per-cluster traffic, latency, and error breakdowns. - [Managed + remote hybrid](https://apinizer.com/solutions/managed-remote-hybrid) — Central control plane with remote Workers in partner data centers and edge sites. - [APIops manifests](https://apinizer.com/developers/apiops) — Describe topology, environments, and promotions as code. --- ## Related use cases - [Managed + remote hybrid](https://apinizer.com/solutions/managed-remote-hybrid) — For platform teams - [Hot deploy & cache](https://apinizer.com/solutions/hot-deploy-cache) — For platform teams - [Three-tier permissions](https://apinizer.com/solutions/three-tier-permissions) — For platform teams - [Observability & audit](https://apinizer.com/solutions/observability-audit) — For platform teams --- ## Next step *One control plane* **Take the gateway where the traffic lives.** A 30-minute walkthrough — Manager, Workers, promotion, and failover — on the Kubernetes you already run. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.