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.
Platform teams · Topology
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.
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
What Apinizer does here
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.
Use cases
In production, this looks like…
- Government
National e-government portal runs Manager in Ankara, Workers in 7 regions
Citizen-facing APIs serve from the nearest data center. The Manager in Ankara stays out of the request path; Workers reconcile every minute.
7 regions, 1 Manager
- Automotive
Connected-vehicle OEM ships APIs to 4 regional clusters
Four data centers run identical Workers. A vehicle that crosses a border doesn't notice — and neither does the SLA.
- Banking
Riyadh Tier-1 bank meets sovereign hosting with regional DR
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.
<60s RTO
- Retail
Warsaw retailer brings up store-edge Workers for in-store APIs
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
Cross-border carrier runs partner-edge Workers in 12 regions
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.
12 partner regions
- Telecom
Madrid carrier runs active/active across Madrid + Barcelona
Both clusters carry production traffic. When Barcelona drops during a fibre cut, Madrid absorbs 100% within the gateway's heartbeat window.
- Energy
Stockholm utility separates SCADA APIs from public APIs by cluster
Operator network and citizen network share a Manager but never share a Worker. Definitions are the same; policies and reachability are not.
- Public sector
Baku ministry promotes manifests across dev / test / prod with one command
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.
How it works
Manager publishes. Workers reconcile. You sleep.
- Step 01
Install Manager
One control plane on the cluster of your choice — central data center, primary region, anywhere with Kubernetes.
- Step 02
Register Workers
Bring up Worker clusters in the regions and environments you need. They register with the Manager over a secure channel.
- Step 03
Publish
Apply a definition once. Every registered Worker picks it up on the next reconcile loop — no manual sync, no drift.
- Step 04
Operate
Watch health, traffic, and lag in the Manager. Promote across environments with one apply; clusters pull when ready.
Recommended products
What we'd reach for first
API Gateway
The Worker that runs everywhere — your central cluster, regional edges, partner data centers.
Open the Gateway pageAnalytics Engine
Per-cluster, per-region traffic and health — one view across every Worker.
Open the Analytics pageCache
Distributed cache that survives Worker reschedules and stays coordinated across regions.
Open the Cache pageMonitoring
Uptime probes from each region; alarms that escalate when a Worker falls behind.
Open the Monitoring pageResources
Keep going
Multi-cluster topology
Manager / Worker split, environment isolation, and active/active patterns.
Architecture overview
How the control plane and data plane fit together on Kubernetes.
Cache
Hazelcast-backed distributed cache with coordinated invalidation across Workers.
Analytics Engine
Real-time per-cluster traffic, latency, and error breakdowns.
Managed + remote hybrid
Central control plane with remote Workers in partner data centers and edge sites.
APIops manifests
Describe topology, environments, and promotions as code.
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.