NOC online · 24/7Longview, TX · +1 323 412 0665
KinetikatechServers · Security · Websites
EN

Self-Hosted Open Source Infrastructure

Architecting Highly Available Keycloak Access Gateways Across Multi-Region Kubernetes Fleets

Keycloak as a single instance is a single point of failure for every application that depends on it. A multi-region deployment needs database replication, session affinity, and a global load balancer that routes to the nearest healthy instance. This guide architects it on Kubernetes.

Key points

  1. Use a shared database. Keycloak instances in multiple regions must connect to a replicated PostgreSQL cluster.
  2. Enable Infinispan clustering. Keycloak uses Infinispan for sessions and caches; configure cross-site replication.
  3. Deploy behind a global load balancer. Route users to the nearest region with health checks and failover.
  4. Handle session affinity. Sticky sessions reduce cross-region traffic but complicate failover; use replicated sessions instead.
  5. Tune cache invalidation. Cross-region cache invalidation adds latency; set appropriate TTLs.
  6. Monitor replication lag. Database and cache replication lag affects login consistency.
  7. Plan for split-brain. Network partitions between regions can cause conflicting writes; use quorum-based databases.
  8. Test failover. Simulate a region failure and verify logins continue with acceptable latency.

Architecture

Each region runs a Keycloak pod connected to a replicated PostgreSQL database. Infinispan replicates sessions across regions. A global load balancer routes to the nearest healthy instance. Database replication uses streaming replication with a primary and standbys.

Production configuration

Keycloak deployment on Kubernetes yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: keycloak
        image: quay.io/keycloak/keycloak:25.0
        env:
        - name: KC_DB
          value: postgres
        - name: KC_DB_URL
          value: jdbc:postgresql://pg-primary:5432/keycloak
        - name: KC_CACHE
          value: ispn
        - name: KC_CACHE_STACK
          value: kubernetes
        args: ["start", "--optimized"]
        resources:
          requests:
            memory: 1Gi
            cpu: 500m
Infinispan cross-site replication yaml
cache:
  stack: kubernetes
  remoteCache:
    host: keycloak-remote.example.com
    port: 11222
  sessions:
    owners: 2
    backups: 1
  loginFailures:
    owners: 1
    backups: 0
Verify cluster health bash
kubectl get pods -l app=keycloak
kubectl logs -l app=keycloak | grep -i 'cluster\|infinispan'
# test failover
curl -s https://auth.example.com/health/ready
# simulate region failure
kubectl scale deployment keycloak --replicas=0 -n region-1

Edge cases from production

  • Cross-region database replication adds write latency; consider read replicas for read-heavy workloads.
  • Infinispan split-brain can cause session loss; configure merge policies carefully.
  • Global load balancer health checks must account for Keycloak startup time, which is slow.
  • Token refresh storms after a failover can overwhelm the surviving region.

Frequently asked questions

Can Keycloak run active-active across regions?

Yes with shared database and Infinispan replication, but write latency increases.

How do I handle database failover?

Use a managed PostgreSQL service with automatic failover, or Patroni for self-managed.

Is session replication worth the complexity?

For high availability yes; for single-region, local sessions are simpler.

How do I test multi-region?

Use separate Kubernetes clusters or namespaces with simulated latency.

What is the main risk?

Split-brain causing conflicting writes; use quorum-based databases to prevent it.

How Kinetikatech helps with self-hosted open source infrastructure

Here's the deal: Running sovereign collaboration, storage, and identity stacks on hardware you control. Hand it to our Server Management and Website Maintenance service and it's covered, assessed properly, implemented cleanly, monitored around the clock.

Talk to an engineer

Server problem? Hacked site? Slow website?

Critical issues answered within 30 minutes, 24 hours a day, 7 days a week.

Request Emergency Support support@kinetikatech.com