Skip to main content
This guide deploys Bifrost to an existing GKE 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 Google Cloud project, so test the selected values in a non-production cluster before rollout.

Bifrost on GKE

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 regional GKE cluster and PostgreSQL database. Run them from Bash after replacing every value inside angle brackets.

Step 1: Connect to GKE

For a zonal cluster, replace --region with --zone and set the corresponding location.

Step 2: Create secrets and Helm values

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:
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.Cloud SQL for PostgreSQL is one Google Cloud-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.

Step 3: Install Bifrost

Step 4: Verify and access Bifrost

Choose how you want to access the deployment:
Keep that terminal open. In another terminal:

Scale Bifrost

  • OSS with SQLite: one replica.
  • OSS DB-managed configuration: one replica; alternatively use file-only OSS multinode.
  • Enterprise: PostgreSQL plus Cluster Mode and HA, pod-discovery RBAC, and internal mesh reachability.
GKE load balancing and NEGs distribute traffic; they do not provide Bifrost state synchronization.

Upgrade, troubleshooting, and production

Follow the upgrade guidance. Diagnose with:
  • Unschedulable OSS SQLite pod: inspect StorageClass, PVC events, zone constraints, and Autopilot policy messages.
  • ImagePullBackOff: verify image repository/tag and Enterprise pull-secret refresh.
  • /health 503: test every configured store from the pod network.
  • Fixed streaming cutoff: inspect GKE/backend/proxy timeout and buffering configuration.
  • Missing Enterprise members: verify RBAC and all three internal port/protocol rules.
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.