Deploy Bifrost to an existing Azure Kubernetes Service cluster
This guide deploys Bifrost to an existing AKS cluster using the Helm chart. It covers the Bifrost image, secrets, storage, database connection, service exposure, verification, and scaling.
The Helm configuration is validated in the repository. The complete guide is not continuously exercised in a live Azure subscription, so test the selected values in a non-production cluster before rollout.
OSS or supplied Enterprise image on linux/amd64 or linux/arm64 Linux nodes
HTTP and health
ClusterIP Service on 8080/TCP; GET /health
SQLite (OSS only)
One replica and a ReadWriteOnce managed disk or another compatible CSI volume
PostgreSQL
PostgreSQL 16 or later reachable from the cluster, inside or outside Azure
External access
Gateway API, ingress, Service LoadBalancer, service mesh, Application Gateway, or external proxy
Enterprise mesh
Kubernetes discovery plus bidirectional 10101/TCP+UDP and 10102/TCP
Image pull
Public Docker Hub for OSS; customer Enterprise registry federation/pull secret from Enterprise Azure
Bifrost Enterprise requires PostgreSQL 16 or later for both stores and does not support SQLite. The SQLite path below is available only for OSS deployments.
export AZURE_RESOURCE_GROUP='<AZURE_RESOURCE_GROUP>'export AKS_CLUSTER='<AKS_CLUSTER_NAME>'export BIFROST_VERSION='<BIFROST_VERSION>'az aks get-credentials \ --resource-group "${AZURE_RESOURCE_GROUP}" \ --name "${AKS_CLUSTER}"kubectl get nodeshelm version
The encryption key protects persisted credentials. Create it once, keep it unchanged after Bifrost writes encrypted data, and use the same value for every replica. Replacing the key makes existing encrypted values unreadable.
This uses PostgreSQL for both Bifrost stores and does not create a Bifrost SQLite PVC. Enterprise customers should replace the image settings and registry authentication using the values supplied by Maxim.Azure Database for PostgreSQL is one Azure-hosted option. The database may instead be operated by the customer or another provider as long as the cluster can reach it.Verify connectivity from the cluster before installing Bifrost:
Enter the PostgreSQL password when psql prompts. A successful connection confirms DNS, TCP, TLS, and database authentication from the pod network. Confirm that server_version reports PostgreSQL 16 or later and server_encoding reports UTF8.
This option is available only for OSS Bifrost. Use SQLite for a single replica and select a compatible ReadWriteOnce StorageClass such as an approved managed-disk CSI class.
Replace <STORAGE_CLASS> with a class returned by kubectl get storageclass. This creates persistent /app/data storage for the OSS SQLite deployment. PostgreSQL is not required for this OSS option.
After EXTERNAL-IP displays an address, stop the watch and run:
export BIFROST_HOST="$(kubectl get service bifrost \ --namespace bifrost \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}{.status.loadBalancer.ingress[0].ip}')"curl --fail --show-error "http://${BIFROST_HOST}:8080/health"
This creates an HTTP endpoint. Configure TLS through the selected Azure or Kubernetes frontend before exposing Bifrost to untrusted clients.
AKS-managed Azure Load Balancers use a 30-minute TCP idle timeout by default. For streams that might remain idle longer, configure TCP keepalive or adjust the load balancer idle timeout.
Point the hostname to the ingress address, configure TLS through the application-routing add-on or another certificate integration, and verify https://<BIFROST_HOSTNAME>/health.