Bouncer fleet scaling caps
Audience: DevOps / Platform engineers
Time: ~10 min
Prerequisites: Deployment overview, at least one Bouncer registered
Recommended maximum Bouncer counts per Control Plane deployment tier. These are conservative guidance values validated on the online-demo footprint — scale horizontally inside an environment (sandbox, production, custom slugs), not across environments.
Recommended caps
| Tier | Max Bouncers per Control Plane | Notes |
|---|---|---|
| Kickstart | ≤25 | Single-cluster Compose / small K8s |
| Custom (Helm) | ≤100 per shard | Add Policy Bridge / policy-repo shard when approaching cap |
| Enterprise multi-shard | Unlimited | One Control Plane per customer environment; shard Policy Bridge fan-out |
Each environment owns its own fleet and unified API key. Cross-environment promotion follows Environments.
Per-environment isolation
- Register Bouncers with the correct
BOUNCER_ENVIRONMENT— environment is pinned at first registration. - Use Multiple Bouncers for HA patterns inside an environment.
Verification
curl -sS -H "Authorization: Bearer $TOKEN" \
"$CONTROL_PLANE_URL/v1/bootstrap/status" | jq .
Expect bootstrap_complete: true when at least one Bouncer has heartbeated within 24h and one protected resource is linked.
Troubleshooting: If the Control Plane UI loads but no decisions appear in audit, open Settings → Bouncers and confirm heartbeat timestamps. Stale Bouncers are excluded from billing and may be swept as orphans. Full reference: Troubleshooting.