Our unified Helm chart deploys Rulebricks and all its dependencies to your Kubernetes cluster in a single command. You'll need:

• Kubernetes 1.29+ (EKS, GKE, AKS, or self-managed; our cluster templates provision 1.34)
• Helm 3.2.0+
• kubectl configured for your cluster
• A domain name you control

Quick Start

# 1. Create your values file
# 2. Install the chart
helm install rulebricks oci://ghcr.io/rulebricks/helm/stack \
  --namespace rulebricks \
  --create-namespace \
  -f your-values.yaml
 
# 3. Follow the on-screen instructions for DNS setup
# 4. Enable TLS once DNS is configured
helm upgrade rulebricks oci://ghcr.io/rulebricks/helm/stack \
  --namespace rulebricks \
  --reuse-values \
  --set global.tlsEnabled=true

Single-Phase Installation (with external-dns)

If you're on AWS, GCP, or Azure and want fully automated DNS:

helm install rulebricks oci://ghcr.io/rulebricks/helm/stack \
  --namespace rulebricks \
  --create-namespace \
  -f your-values.yaml \
  --set external-dns.enabled=true \
  --set global.externalDnsEnabled=true \
  --set global.tlsEnabled=true

See Example Configurations below for minimal values files, and visit the YAML Reference for a complete breakdown of all available options.

What am I deploying?

You're deploying a complete Rulebricks stack to your existing Kubernetes cluster. The chart installs multiple integrated services, pre-configured for production workloads.

For how these components interact, see Architecture.

Database Options

Self-hosted (default): PostgreSQL runs in your cluster with persistent storage. You have full control and data never leaves your infrastructure.

Managed Supabase: Use Supabase Cloud instead. Set supabase.enabled: false and provide your project credentials. The chart automatically configures your managed project. We are also able to manage your database for you, should you prefer a hybrid deployment configuration.

Example Configurations

We recommend consulting the Changelog and pinning global.version to the release containing the latest fixes/features. That single version selects the app, HPS, and HPS worker images together.

Development / Testing

Minimal configuration for evaluation purposes. Self-hosts Supabase.

# values.yaml
global:
  domain: '<domain-you-control.com>'
  email: '<valid-email>'
  licenseKey: '<valid-license-key>'
  version: '<rulebricks-version>' # e.g. "1.8.17"
  smtp: <valid-information>
 
# Everything else uses defaults

Production with Supabase Cloud

Automatic DNS, external database, shared object storage.

# production-values.yaml
global:
  domain: '<domain-you-control.com>'
  email: '<valid-email>'
  licenseKey: '<valid-license-key>'
  version: '<rulebricks-version>'
  tlsEnabled: true
  externalDnsEnabled: true
 
  smtp: <valid-information>
 
  # Shared object storage for decision logs (and database backups
  # when self-hosting Supabase)
  storage:
    provider: s3 # s3, azure-blob, or gcs
    bucket: '<your-bucket>'
    region: '<bucket-region>'
    s3:
      iamRoleArn: '<irsa-role-arn>'
 
  supabase:
    url: 'https://abcd1234.supabase.co'
    projectRef: 'abcd1234'
    anonKey: 'from-supabase-dashboard'
    serviceKey: 'from-supabase-dashboard'
    # Account > Settings > Access Tokens
    accessToken: '${SUPABASE_ACCESS_TOKEN}'
 
supabase:
  enabled: false # Don't deploy self-hosted
 
# Ensure this is configured properly
external-dns:
  enabled: true
  provider: route53

Cloud-Specific Values

Each provider needs a compatible StorageClass and external-dns configuration:

# AWS EKS (requires EBS CSI driver; use IRSA for AWS integrations)
storageClass:
  create: true
  provisioner: ebs.csi.aws.com
  type: gp3
external-dns:
  enabled: true
  provider: route53

# Google GKE (uses Workload Identity; annotate service accounts accordingly)
storageClass:
  create: true
  provisioner: pd.csi.storage.gke.io
  type: pd-ssd
external-dns:
  enabled: true
  provider: google
  google:
    project: 'your-gcp-project'

# Azure AKS
storageClass:
  create: true
  provisioner: disk.csi.azure.com
  type: Premium_LRS
external-dns:
  enabled: true
  provider: azure
  azure:
    resourceGroup: 'your-resource-group'
    subscriptionId: 'your-subscription-id'

Caveats & Limits

Cluster Requirements

The Helm chart deploys to your existing Kubernetes cluster. You're responsible for:

• Cluster provisioning and scaling
• Node pool configuration
• Storage provisioner (e.g., AWS EBS CSI driver)
• Network policies and security

See example-min-cluster.yaml (opens in a new tab) for minimum EKS cluster specifications, or the CLI's cluster-setup resources for ready-made AWS, Azure, and GCP starting points.

Air-Gapped Deployments

Rulebricks can run nearly air-gapped with these exceptions:

Installing Updates

Rule engines usually take critical roles, so we don't release updates continuously. We make upgrades easy with zero downtime, but you control when they happen.

The Rulebricks product version is pinned by a single value, global.version. It selects the rulebricks/app, rulebricks/hps, and rulebricks/hps:worker-* images together, along with app-backed migration jobs, so there's no per-image tag to keep in sync.

First, visit our Changelog and find the version containing the fixes/features you need.

Then, edit global.version in your values.yaml file:

global:
  version: '1.8.17'

Finally, run:

# Upgrade to the pinned version
helm upgrade rulebricks oci://ghcr.io/rulebricks/helm/stack \
  --namespace rulebricks \
  -f your-values.yaml

If anything goes wrong during install or upgrade, see Troubleshooting.