High availability
The policy evaluator is stateless and scales horizontally. The decision log is the one component that needs a real replication story.
Availability design in Cirvix follows from one principle: an authorization system that fails open is worse than one that fails slowly. Every failure mode below is designed around staying closed.
What can fail independently
| Component | Failure mode | Mitigation |
|---|---|---|
| Evaluator | Pod or process crash | Stateless — add replicas behind the gateway |
| Gateway | Node loss | Multiple replicas behind a load balancer |
| Decision log | Disk or node loss | Replicated append-only store plus an external checkpoint witness |
| Approval channel | Slack outage | Falls back to email or the approve CLI queue |
Fail-open or fail-closed
Fail-closed is not configurable, and that is deliberate. An empty or unparseable rule set denies everything; an unknown condition operator fails closed; a control-plane outage leaves the last cached rule set enforcing rather than opening the door. There is no fail_open setting, because the setting that turns this off is the one nobody discovers until it is being used against them.
Running more than one instance
The evaluator and gateway are stateless enough to run behind your existing load balancer. The decision log's replication topology depends on the consistency guarantee you need for the audit chain, which is a decision to make with your own infrastructure team rather than a default Cirvix can safely pick for you. Note that the bundled control plane is single-writer and the Helm chart pins one replica; multi-region replication and regional data isolation are not features Cirvix implements today.