Skip to main content
Cluster mode enables multiple Bifrost replicas to share state - rate limits, budget counters, and governance data - across pods. When bifrost.cluster.enabled is false (the default), each replica operates independently and state is only shared via the database.
Cluster mode requires PostgreSQL as the storage backend. SQLite is single-node only.
bifrost.cluster.* is an enterprise capability. OSS images accept these values but do not run cluster mode at runtime.

When to Use Cluster Mode

The Helm chart deploys the default mesh clustering, which needs nodes to reach each other directly over gossip (10101) and gRPC (10102). On platforms that do not allow peer-to-peer connectivity - such as Google Cloud Run - use broker mode, where nodes only make an outbound connection to a central relay. See Enterprise Clustering → Broker Mode.

Basic Cluster Setup

For version 1.4.x - you will need to expose 10102 TCP port and 10101 UDP port for cluster discovery.

Peer Discovery

Bifrost uses a gossip protocol (memberlist) for peer-to-peer state sync. Configure how peers find each other:
For consul, etcd, and udp discovery, set bifrost.cluster.discovery.serviceName so nodes register/discover under a stable service identity.

Allowed Address Space

Restrict gossip to a specific subnet (useful in multi-tenant clusters):

Region-Aware Routing

Tag replicas with a region identifier for latency-aware routing:

Full HA Production Example


Verifying Cluster Health