The source of truth is the chart’s own
values.yaml. Extract it with helm registry login registry.falkordb.cloud --username '<username>' (it prompts for your access token), then helm pull oci://registry.falkordb.cloud/falkordb/falkordb-enterprise --untar and verify against the chart version you are installing.values.yaml, so its defaults are always the shipped ones.
Platform dependencies
When using
install.sh, the installer detects the default StorageClass provisioner and configures snapshot values automatically:
- CSI-backed cloud StorageClasses, such as
ebs.csi.aws.com,pd.csi.storage.gke.io, anddisk.csi.azure.com, get a matching chart-managedVolumeSnapshotClassunless a default one already exists for that driver. - Local non-CSI StorageClasses, such as
rancher.io/local-path, enable the optionalcsi-hostpath-driverand makecsi-hostpath-scthe default for new PVCs. Existing PVCs are not migrated. - Unknown or non-CSI provisioners disable the chart-managed
VolumeSnapshotClass; pass--set volumeSnapshotClass.driver=<csi-driver>when the storage platform supports snapshots but cannot be detected.
--set and --set-string values passed to the installer override the detected snapshot configuration.
On upgrades, the installer reuses existing Helm release values before applying new detected values. This preserves deployment-specific image tags, image pull secrets, ingress hosts, TLS settings, and immutable PVC settings while still adding the correct snapshot configuration.
FalkorDB Enterprise is intentionally limited to one installation per Kubernetes cluster. The chart renders a fixed cluster-scoped ClusterRole install lock and also checks for an existing Helm-owned ClusterDefinition/falkordb from older chart versions. Upgrades of the owning Helm release are allowed; installs from a different release or namespace fail during Helm rendering.
Registry credentials
registry.falkordb.cloud requires authentication for every image, including the chart’s hook Jobs, so an install from it needs a pull Secret. install.sh creates one and sets these values for you; configure them yourself only for a manual Helm install, or leave them empty when pointing global.imageRegistry at a mirror that allows anonymous pulls.
For a manual first install, create the Secret in the release namespace beforehand and set global.imageCredentials.name with create: false. A chart-created Secret (create: true) is made with the rest of the release, after the preflight pre-install hook has already tried to pull its image, so that hook fails against an authenticated registry. The same applies to the pre-upgrade hook: switch to create: true only on a release whose Secret already exists and is owned by Helm, as one created by install.sh is. When an existing release has no pull Secret yet, create it the same way before upgrading.
Kubernetes has no cluster-scoped image pull Secret —
imagePullSecrets always resolves in the pod’s own namespace. The Admin Server therefore copies the Secrets named in global.imageCredentials.name and global.imagePullSecrets from its own namespace into every namespace it provisions a database into, refreshing the copy on each cluster operation so a rotated credential propagates. Nothing outside this block needs to know the credentials, and operators do not have to seed namespaces by hand.
install.sh creates the Secret from GITEA_USERNAME and GITEA_TOKEN (or --registry-username / --registry-password) and sets all of the values above for you.
API server address
The kubelet injects
KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT into every container, pointing at the API server’s in-cluster ClusterIP. Every in-cluster client — the Admin Server’s Kubernetes client, kubectl in the hook Jobs, controller-runtime inside KubeBlocks — builds its API URL from those two variables. Leave both values empty unless the ClusterIP route does not work; nothing is rendered when they are unset.
Set them when either failure mode applies:
- The ClusterIP’s only endpoint is a managed or public API endpoint that requires SNI. A client connecting by IP sends no SNI, so the endpoint cannot select a certificate and TLS fails mid-handshake.
- A firewall rejects traffic to the ClusterIP outright.
global. Use install.sh --kubernetes-service-host, which fans the value out to the standalone KubeBlocks release it installs, or examples/values-apiserver-dns.yaml, which sets kubeblocks.extraEnvs and kubeblocks.dataProtection.extraEnvs alongside the global keys.
FalkorDB database pods need no extra configuration. The falkordb-addon subchart reads the same two values and emits them through ComponentDefinition.spec.vars, which KubeBlocks injects into every container of a database pod, including the kbagent sidecar it adds itself.
Gateway and public URLs
Admin Server
Restricting which namespaces can hold databases
Admin Server creates a namespace on demand the first time a database is deployed into it.adminServer.managedNamespaces.pattern confines that to namespaces you have opted into:
falkordb-team-a but rejects team-a and kube-system, and you do not need to write ^ or $ yourself. It is enforced on the server, not only in the console, so it also applies to API clients and to restores that rebuild a namespace from stored metadata.
Whatever the pattern allows, Admin Server refuses every kube-* namespace (kube-system, kube-public, kube-node-lease) and each namespace in adminServer.managedNamespaces.denied, which lists kb-system by default. When you install KubeBlocks in another namespace with --kubeblocks-namespace, the installer adds it. Onboarding a namespace grants Admin Server read-write access to its Secrets, so add the namespaces of other platform components to this list.
Admin Server’s permission to read and write Secrets is granted per namespace rather than cluster-wide. The chart creates a ClusterRole named <release>-admin-server-namespaced holding that access and binds it into the release namespace; Admin Server binds it into each database namespace the first time a database is created there. It has no Secret access at all in namespaces it does not manage. Set adminServer.rbac.create=false to manage these objects yourself — Admin Server then skips creating the per-namespace binding and expects one to already exist.
On startup Admin Server also checks every namespace that already holds a database and creates any binding that is missing, except in denied namespaces. Upgrades from a release that granted Secret access cluster-wide therefore need no manual step, and a binding deleted by hand is restored on the next restart.
Because Admin Server holds no namespaces: list permission, the namespace picker in the console lists only namespaces that already hold a database, plus the release namespace. Type a new name into the field to deploy into a namespace for the first time.
Admin Server license
Set a license directly in values for development or one-off installs:FALKORDB_LICENSE, validates the signature, and persists the license state at adminServer.license.statePath. If the license expires or is invalid, the server and UI enter read-only mode until a valid license is active. Recovery operations on existing deployments (restart, start, stop, switchover and backup) stay available in read-only mode. If usage exceeds a configured limit, the license is locked instead: only actions that would increase usage are refused.
The signed license key payload includes a version field so future payload formats can be introduced explicitly. The current supported payload version is 1.
To bind a license to one Kubernetes cluster, include k8sClusterId in the signed payload. By default the admin server compares this value to the UID of the kube-system namespace. You can retrieve it with:
K8S_CLUSTER_ID on the admin server and issue licenses with the same value. Licenses without k8sClusterId remain unbound.