This guide deploys Bifrost to an existing EKS 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 AWS account, so test the selected values in a non-production cluster before rollout.
Bifrost on EKS
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.
Deploy Bifrost
The commands below use an existing EKS cluster and PostgreSQL database. Run them from Bash after replacing every value inside angle brackets.
Step 1: Connect to EKS
Continue only after the nodes report Ready.
Step 2: Create secrets and Helm values
The following commands prompt for sensitive values so they are not written into the values file:
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.
Choose the storage configuration for this deployment:
PostgreSQL
SQLite (OSS only)
This configuration uses PostgreSQL for both Bifrost stores. It does not create a Bifrost SQLite PVC. Enterprise customers should replace the image settings with the private image coordinates supplied by Maxim before continuing.Amazon RDS or Aurora PostgreSQL is one AWS-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 StorageClass backed by the EBS CSI driver or another CSI implementation that provides a ReadWriteOnce volume.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.
Step 3: Install Bifrost
Step 4: Verify and access Bifrost
Choose how you want to access the deployment:
Without a load balancer
With a load balancer
With ingress
Keep that terminal open. In another terminal:Expected: HTTP 200 and a response containing "status":"ok". Use this option when the cluster has EKS Auto Mode load balancing or AWS Load Balancer Controller configured:After EXTERNAL-IP displays a hostname, stop the watch and run:This creates an HTTP endpoint. Configure TLS through the customer’s ingress, gateway, or load-balancer policy before exposing Bifrost to untrusted clients. This example uses AWS Load Balancer Controller and an existing ACM certificate. Install the controller using the AWS Load Balancer Controller guide before applying these values.Point the hostname to the provisioned load balancer and verify https://<BIFROST_HOSTNAME>/health. Adjust the idle timeout for the longest expected streaming interval.
Scale Bifrost
Replica configuration
- Keep OSS with SQLite at one replica.
- Keep OSS with DB-managed configuration at one replica, or use the file-only OSS multinode pattern.
- For Enterprise replicas, use PostgreSQL, enable clustering, enable
rbac.podDiscovery, and permit internal cluster ports. Start from Cluster Mode and HA, not from an EKS-specific copy of those values.
An external load balancer distributes client traffic; it does not synchronize Bifrost configuration or governance state.
Upgrade, troubleshooting, and production
Follow the upgrade guidance. Common EKS-specific checks are:
- Pending OSS SQLite pod: inspect PVC events, StorageClass, EBS CSI controller, and zone placement.
ImagePullBackOff: verify the repository, tag, node/pod pull identity, and registry reachability.
/health returns 503: inspect Bifrost logs and verify each configured store from the pod network.
- Streaming stops at a fixed interval: inspect every ingress/proxy idle timeout and response buffering setting.
- Enterprise members are missing: verify pod-discovery RBAC and bidirectional
10101/TCP+UDP and 10102/TCP.
Complete the deployment verification checklist for database availability, backups, TLS, secrets, autoscaling, and observability. See Enterprise clustering when the deployment spans several clusters or regions.