Private Deployment
Storage & Backups

Storage & Backups

Rulebricks uses one cloud provider, one identity, and one bucket (or container) for all storage-backed features. Decision logs and database backups are key prefixes within that single bucket, so adding more data types later never means another identity or bucket to wire up.

Shared Object Storage

ParameterTypeDefaultDescription
global.storage.providerstring"s3"Storage backend: s3, azure-blob, or gcs
global.storage.bucketstring""Bucket name (S3/GCS) or storage account (Azure Blob)
global.storage.regionstring""Bucket region
global.storage.paths.decisionLogsstring"decision-logs"Key prefix for the decision log archive
global.storage.paths.dbBackupsstring"db-backups"Key prefix for database backups

Identity is configured per provider. Workload identity is preferred everywhere; static credentials are an escape hatch.

ProviderPreferred IdentityFallback
s3global.storage.s3.iamRoleArn (IRSA)global.storage.s3.existingSecret.name
azure-blobglobal.storage.azure.clientId + tenantIdglobal.storage.azure.connectionStringSecretRef
gcsglobal.storage.gcp.serviceAccountEmailn/a
global:
  storage:
    provider: s3 # s3, azure-blob, or gcs
    bucket: my-rulebricks-data
    region: us-west-2
    s3:
      iamRoleArn: arn:aws:iam::123456789012:role/rulebricks-storage
    paths:
      decisionLogs: decision-logs
      dbBackups: db-backups

Every component that touches the bucket (Vector, ClickHouse, the backup CronJob) authenticates through the same workload identity pattern, so bucket credentials stay in Kubernetes service account configuration rather than application containers.

Upgrade note: older values that split storage into global.storage.decisionLogs.* and global.storage.dbBackups.* (per-purpose buckets and regions) are still honored as overrides, but new installs should use the unified bucket, region, and paths.* shape shown above.

If you use the Rulebricks CLI, the wizard collects this storage backend during rulebricks init and generates the values above for you. The CLI's cluster-setup resources (opens in a new tab) also create compatible buckets and identity roles per cloud.

What lands in the bucket:

  • Decision logs under paths.decisionLogs: a compressed NDJSON archive written by Vector and queried by ClickHouse. See Decision Logs.
  • Database backups under paths.dbBackups: Barman base backups of the self-hosted Supabase database, covered below.

Database Backups

The Supabase PostgreSQL instance holds all application state and should be backed up regularly if self-hosting. The bundled deployment uses a PersistentVolumeClaim, so data survives pod restarts, but PVCs are not a meaningful backup strategy.

Enable backup.enabled and the chart schedules Barman base backups to your bucket under global.storage.paths.dbBackups:

backup:
  enabled: true
  schedule: '0 2 * * *'
  retentionDays: 30
ParameterTypeDefaultDescription
backup.enabledbooleanfalseEnable scheduled database backups
backup.schedulestring"0 2 * * *"Cron schedule for Barman base backups
backup.retentionDaysinteger30Days to retain restorable backup data
backup.superuserstring"supabase_admin"Postgres superuser role used for logical dumps and restores
backup.ttlSecondsAfterFinishedinteger2592000Seconds to retain completed backup Jobs and their pod logs
backup.jobHistory.successfulinteger30CronJob history limit for successful Jobs
backup.jobHistory.failedinteger30CronJob history limit for failed Jobs

Logical dumps run as backup.superuser so they can read schemas owned by supabase_admin (auth, storage, realtime, and so on).

Backups are only available for self-hosted Supabase. The default history limits assume the default daily schedule; increase backup.jobHistory.* if you back up more frequently and need every completed Job visible for the full TTL window.

On-Demand Backups and Restores

The Rulebricks CLI manages backups outside the schedule:

# Trigger an on-demand backup
rulebricks backup my-deployment
 
# List backups in object storage and interactively restore one
rulebricks restore my-deployment

The restore command lists available backups from object storage and asks for confirmation before restoring.

Block-Level Snapshots

As a secondary measure on AWS with EBS-backed PVCs, you can also schedule EBS snapshots of the database volume. This captures a point-in-time copy at the block level without impacting the running database.