Production installation guide for FalkorDB Enterprise

Prerequisites

Access to run kubectl commands in the cluster’s context.
At least 3 worker nodes with 4 CPU and 16 GB of memory each.
Outbound access from the cluster to pull images: registry.falkordb.cloud (Enterprise images, credentials required), docker.io, apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com, registry.k8s.io, and ghcr.io — or registry.falkordb.cloud alone, since every image is also mirrored there (see Private registries).

Recommended inputs

Prepare these values before installing:

Kubernetes context name.
FalkorDB Enterprise namespace.
KubeBlocks namespace.
A stable 32+ character JWT secret.
Image pull credentials if Enterprise images are private.
Public Admin UI hostname.
TLS-enabled ingress configuration, and an ingress controller to serve it. The example below uses className: nginx, which needs ingress-nginx; the installer installs it only for --quick-access.
Storage class for Admin Server persistence if the cluster default is not suitable.

Only one FalkorDB Enterprise installation is supported per Kubernetes cluster. The Helm chart creates a cluster-scoped install lock named falkordb-enterprise-install-lock and blocks installs from any other release or namespace in the same cluster. Re-running or upgrading the owning release is allowed. Generate a JWT secret:

openssl rand -hex 32

Production values file

Create a values file for environment-specific settings:

gateway:
  enabled: true
  ingress:
    enabled: true
    className: nginx
    hosts:
      - host: admin.example.com
    tls:
      - secretName: falkordb-enterprise-admin-tls
        hosts:
          - admin.example.com

adminServer:
  env:
    nodeEnv: production
    corsOrigin: https://admin.example.com
    cookieSecure: true
    enableSwagger: "false"
  persistence:
    enabled: true
    size: 8Gi
    storageClassName: ""
  bootstrap:
    adminUser:
      email: admin@example.com

adminUi:
  env:
    viteApiUrl: ""

When gateway.ingress.enabled=true, the chart derives the Admin UI public URL from the first gateway ingress host. The Admin Server CORS origin defaults to that Admin UI public URL unless adminServer.env.corsOrigin is set.

Install with explicit context and Secrets

curl -fsSL https://falkordb.github.io/FalkorDB-Enterprise/install.sh | \
  JWT_SECRET='replace-with-64-hex-characters' bash -s -- \
    --registry-username '<username>' \
    --registry-password '<token>' \
    --kube-context production-cluster \
    --release falkordb-enterprise \
    --namespace falkordb-system \
    --kubeblocks-namespace kb-system \
    --values production-values.yaml \
    --yes

You can also pass the secret as a script argument:

curl -fsSL https://falkordb.github.io/FalkorDB-Enterprise/install.sh | \
  bash -s -- \
    --registry-username '<username>' \
    --registry-password '<token>' \
    --kube-context production-cluster \
    --namespace falkordb-system \
  --kubeblocks-namespace kb-system \
  --values production-values.yaml \
  --jwt-secret 'replace-with-64-hex-characters' \
  --yes

Private images

If Admin Server or Admin UI images are private, configure an image pull Secret. See Private registries for the complete flow.

Browser encryption key

FalkorDB Browser is enabled by default. The chart includes a post-install/post-upgrade hook that ensures a 64-character hexadecimal ENCRYPTION_KEY exists for the Browser deployment and restarts the Browser when needed. To provide your own key:

falkordb-browser:
  browser:
    encryption:
      key: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

To use an existing Secret:

falkordb-browser:
  browser:
    encryption:
      existingSecret:
        name: browser-encryption
        key: ENCRYPTION_KEY

Enterprise license

Leaving adminServer.license empty is a valid choice, not just a placeholder state: the admin server starts a 14-day free trial with no configured limits as soon as it comes up unlicensed. You do not need to pass a license through Helm at all — sign in to the Admin UI and activate or replace the license from the Licensing page at any time, including after install. Helm-provided licenses below are for automating unattended installs. See Licensing for how to obtain one and what it limits.

The admin server can receive a signed Enterprise license from Helm. For production, create a Secret in the Enterprise namespace and reference it from chart values:

kubectl -n falkordb-system create secret generic falkordb-enterprise-license \
  --from-literal=license='falkor.license.v1.<payload>.<signature>'

adminServer:
  license:
    existingSecret:
      name: falkordb-enterprise-license
      key: license

For development installs, you can set the license directly in values:

adminServer:
  license:
    value: "falkor.license.v1.<payload>.<signature>"

The chart exposes the license to the admin server as FALKORDB_LICENSE and persists validated license state at /data/license-state.json by default. Keep admin server persistence enabled so API-activated licenses and Helm-provided licenses survive pod restarts. If the license is expired, invalid, or any resource limit is exceeded, authenticated write operations are locked and the Admin UI becomes read-only until a valid license within limits is active. Generated license keys include a signed payload with version: 1. The admin server currently accepts payload version 1; future license payload formats should increment this field. To bind the license to this Kubernetes cluster, generate it with the cluster ID from the UID of the kube-system namespace:

kubectl get namespace kube-system -o jsonpath='{.metadata.uid}'

The signed payload field is k8sClusterId. The admin server compares it to K8S_CLUSTER_ID when set, otherwise to the kube-system namespace UID. Omit k8sClusterId for an unbound license.

Post-install validation

helm status falkordb-enterprise -n falkordb-system
kubectl get pods -n falkordb-system
kubectl get ingress -n falkordb-system
kubectl get secret -n falkordb-system -l 'app.kubernetes.io/component=admin-server'

Open the Admin UI URL and sign in with the bootstrap admin user. On a first install the chart generates its password and stores it in the Secret <release>-initial-admin-password:

kubectl -n falkordb-system get secret falkordb-enterprise-initial-admin-password \
  -o jsonpath='{.data.password}' | base64 -d; echo

You must change it at first sign-in. Delete that Secret afterwards.

Production notes

Do not install with --quick-access or --no-ingress: both publish the Admin UI over plain HTTP.
If you set adminServer.bootstrap.adminUser.password yourself, keep mustChangePassword: true so it is replaced at first sign-in.
Prefer a values file over long --set command lines.
Do not rely on helm --reuse-values for upgrades unless image tags are set explicitly.
Leave cookieSecure enabled behind TLS.
Keep Admin Server persistence enabled unless audit logs and local state are intentionally disposable.

Storage

Database volumes need replicated, snapshot-capable CSI storage that can attach on any node, such as a cloud provider’s block storage, Longhorn or Rook-Ceph. Make it the default StorageClass, or choose it in the create wizard. Local storage such as local-path keeps each volume on the node its pod first ran on. Losing that node loses the data, and volume-snapshot backups are not available. On a multi-node cluster the installer leaves such storage alone and warns. It enables its bundled single-node csi-hostpath-driver only on a single-node cluster, or when you pass --local-csi-hostpath enable. That driver stores every volume on one node, so never enable it on a production cluster. An install that already uses it keeps using it on upgrade.

Backups

The chart’s default backup repository is a volume in the same Kubernetes cluster as your databases, so a cluster or storage failure can take the backups with the data. For production:

Create a backup repository on object storage (S3, GCS, Azure Blob or MinIO) and mark it as the default. See Backups.
Test a restore of each deployment into a new deployment.

The default repository is kept when the release is uninstalled, and its volumes use the Retain reclaim policy.

Alerts

Enable the pod monitors and the alert rules so you hear about failed shards, broken replication, memory near maxmemory, full volumes and failed backups. Both need the Prometheus Operator CRDs (PodMonitor, PrometheusRule), and a Prometheus instance whose selectors pick up resources in the release namespace, for example from kube-prometheus-stack. Install and configure that first; add its required labels with podMonitor.additionalLabels and alertRules.additionalLabels.

podMonitor:
  enabled: true
alertRules:
  enabled: true

See Database alerts for the full list.

Database namespaces

Admin Server gets read-write access to Secrets in every namespace a database is created in. It always refuses kube-* namespaces and the namespaces in adminServer.managedNamespaces.denied (kb-system by default). For production, also confine databases to a prefix:

adminServer:
  managedNamespaces:
    pattern: "falkordb-.*"

KubeBlocks version

The installer deploys KubeBlocks 1.2.0-alpha.1, which is a prerelease. Check KubeBlocks upgrades before changing it. One known gap: its sharding definition accepts spec.tls.shared and ignores it, so KubeBlocks can’t issue one CA for all shards. A sharded deployment with TLS needs a certificate you provide.

Pod security admission

The installer labels the release namespace enforce=baseline with audit and warn at restricted. With CSI storage, baseline is also enough for kb-system and for database namespaces, and no namespace needs privileged. The chart’s bundled CSI drivers are the exception: csi-hostpath-driver, csi-s3 and csi-nfs run privileged pods in the release namespace, so it needs privileged when any of them is enabled. The installer raises the label itself only for csi-hostpath-driver. If your cluster applies a stricter default, or you manage namespace labels yourself, see Pod Security Admission levels for the measured level of each namespace and the exact workloads that cap it.

Network policies

The chart can restrict what reaches the Admin Server and Admin UI, and what the Admin Server can reach. This is off by default because a CNI that does not implement NetworkPolicy accepts the objects and enforces nothing.

networkPolicy:
  enabled: true
  ingressControllerNamespace: ingress-nginx

Confirm your CNI enforces policy first, then narrow networkPolicy.externalEgress to your control plane and identity provider ranges. See Network policies for the full set of rules, the flows that deliberately have none, and how to verify enforcement.

Supply chain

Verify the chart signature before installing, and the image signatures before promoting a release. helm install does no signature checking of its own.

cosign verify --key cosign.pub --insecure-ignore-tlog=true \
  registry.falkordb.cloud/falkordb/falkordb-enterprise:1.2.0

Admin Server and Admin UI images resolve to the chart’s appVersion by default, so a chart version always requests the same image version. For a stricter guarantee, pin adminServer.image.digest and adminUi.image.digest so the image cannot be swapped underneath you. See Supply chain.

Security review

Security describes the whole posture in one place: every RBAC grant and why it exists, the workload security contexts, the secrets the chart handles, and which controls are enforced by Kubernetes rather than by the product. Point a security reviewer at that page.

Get started

Install

Authentication

Deploy databases

Operations

Licensing

Security

Releases

Upgrade and uninstall

Troubleshooting

Production installation guide for FalkorDB Enterprise

Prerequisites

Recommended inputs

Production values file

Install with explicit context and Secrets

Private images

Browser encryption key

Enterprise license

Post-install validation

Production notes

Storage

Backups

Alerts

Database namespaces

KubeBlocks version

Pod security admission

Network policies

Supply chain

Security review

​Prerequisites

​Recommended inputs

​Production values file

​Install with explicit context and Secrets

​Private images

​Browser encryption key

​Enterprise license

​Post-install validation

​Production notes

​Storage

​Backups

​Alerts

​Database namespaces

​KubeBlocks version

​Pod security admission

​Network policies

​Supply chain

​Security review

Prerequisites

Recommended inputs

Production values file

Install with explicit context and Secrets

Private images

Browser encryption key

Enterprise license

Post-install validation

Production notes

Storage

Backups

Alerts

Database namespaces

KubeBlocks version

Pod security admission

Network policies

Supply chain

Security review