Local High Availability

For the production Helm installation, prerequisites, per-pod Secrets, networking and readiness checks, use Deploy Eden with high availability. The customer profile uses retained-identity active-passive recovery. Five validators share external PostgreSQL and ClickHouse; four are required for control changes, while customer traffic stays on StatefulSet ordinal zero. Obtain a qualified release-matched image, chart and online HA deployment context before installing. Architecture examples do not qualify a customer release.

Commercial HA requires a Professional or Enterprise image and a license with the matching signed HA entitlement. A Professional trial can include HA; Standard uses one embedded instance. The production Helm profile uses five validators and requires four available. Three validators require all three; seven require five. Retain one private state volume per replica and replace one replica at a time. A disruption budget protects voluntary evictions, but does not make simultaneous updates or infrastructure failures safe.

Download the release-matched chart using the customer Helm installation guide. The licensed HA profile requires online authority connectivity; offline HA is not supported by this profile. A rendered chart alone does not establish that its selected image and license are qualified for production.

For Azure storage, private relay addresses, PostgreSQL TLS and rollout checks, see Azure Kubernetes Service.

Active-passive customer profile

The other validators maintain quorum; they do not become different logical migration owners. Stop and fence the old primary before recreating the same ordinal on a replacement host. Retain its UUID, keys, configuration, license custody and PVC. The replacement host must support that volume's zone and attachment policy. Never run the same identity and data on two hosts at once.

A crash-interrupted migration remains fenced. Restore safe source routing, preserve its operation history, explicitly reconcile the target, then start a fresh attempt when required. Service recovery does not imply automatic copy continuation. See migration recovery.

Active-active architecture reference

Concurrent serving and different-identity migration takeover are outside the first customer release. The following explains the separate architecture; do not substitute it for the retained-ordinal installation and recovery steps.

Pingora distributes reads and writes across all healthy active nodes. It probes GET /health and removes a failed node after the configured consecutive failures. Active-active cache peers use stable identities, direct per-shard addresses, and mutually authenticated TLS.

Compose uses service DNS names. Helm uses a StatefulSet and headless Service; Eden re-resolves those peer names every EDEN_HA_CACHE_SYNC_PEER_REFRESH_INTERVAL_MS (default 5000ms) so a replacement pod can receive a new IP without leaving the surviving node pinned to the old route.

Cache Ordering

Postgres remains the source of truth. Committed RBAC cache values, explicit revocation markers, and endpoint or organization fences replicate directly through ShardKV. Each record carries the Postgres (version_ms: i64, version_seq: i64) tuple as a fixed 16-byte ordered revision. A higher Postgres revision wins even when packets arrive out of order.

The revision does not use a wrapping u8. Although serial arithmetic can treat 255 as earlier than 0, ordering becomes ambiguous at 128 revisions of lag and values repeat after 256 writes. An HA peer can be disconnected longer than that. Eden therefore treats revision 255 as earlier than 256 without wrapping.

If either revision component is i64::MAX, Eden keeps the revision as an ordering boundary but does not serve that cached authorization value. The read falls back to authoritative Postgres. A later greater tuple restores caching only when neither component is still i64::MAX (for example, a later timestamp can follow a maximal sequence). Any tuple whose timestamp is i64::MAX, including the fully maximal tuple, remains a read boundary until the cache generation is replaced. It never wraps to i64::MIN.

Eden publishes a replicated RBAC value only when Postgres reports that the revision was applied. Stale or equal mutations rejected by Postgres cannot overwrite the cache.

RBAC writes must go through Eden's write methods. Direct SQL writers are not a supported HA path because RBAC triggers do not enqueue unversioned invalidation events; an additional writer needs a revisioned database changefeed before it can safely update the replicated cache.

Entity ID/UUID mappings, ELS, encryption metadata, and VPN identity records do not all expose a Postgres revision yet. A compatibility outbox invalidates those process-local cache families on every HA node in active-passive and active-active mode. It does not clear the replicated RBAC map.

Health

/health deliberately remains healthy when a peer dies, allowing the survivor to stay in the traffic pool. /health/cache-sync reports 503 while peers are joining or failing. During that state, authorization and membership cache reads bypass ShardKV and use Postgres. Persistent gateway connections revalidate on every request while the cache version is indeterminate.

Recovery timing

Downtime depends on the customer's configuration. Measure failure detection, old-host fencing, disk detach/reattach, scheduling on a compatible spare host, startup and quorum readiness, client reconnects and traffic restoration separately. Migration reconciliation and a fresh attempt can take additional time. No fixed recovery interval or annual availability percentage is promised. Local Linux tests do not qualify Azure Disk, AKS scheduling or Azure load balancers; rehearse those infrastructure steps in the customer's environment.

Deploy and verify

Follow the customer deployment walkthrough with both production-ha-values.yaml and the mandatory production-active-passive-values.yaml overlay. Set five retained per-ordinal UUIDs once, keep nodeUuidFromPodUid: false, and retain OnDelete updates. Standard is a single-instance profile; an eligible Professional trial can use the Professional HA image. An ordinary image update preserves the license and state, while moving from embedded storage to HA is a separate planned migration.

Check /ready, /health/consensus-control and /health/nat-relay on all five members, then exercise an authenticated disposable endpoint write/read through the primary. Verify retained state and license identity after replacing one stopped ordinal. /health/cache-sync is relevant only when a separately qualified profile enables cache sync. Keep the exact image digest and observed results with the customer's deployment record.