FalkorDB Enterprise release notes and changelog

​

Added

• Point-in-time restore. A deployment with an aof backup schedule can be restored to a new deployment as it was at any second in its restorable window: in the Admin UI (Backups > Restore > Point in time), with restoreTime on POST /api/clusters/<name>/restores/clone, or with falkordb-admin backups clone --restore-time. The window is reported by GET /api/clusters/<name>/restores/window and falkordb-admin backups restore-window, and a time outside it is rejected. Sharded deployments are restored to the same second on every shard; their window is the time every shard covers. When a sharded deployment’s shard count changes, its continuous backup can no longer be restored to a point in time, and the Admin Server replaces it with a new one by itself, once the deployment is running again. A sharded full backup taken before a scale-in is restored to as many shards as it holds, since KubeBlocks refuses to restore it to fewer. See Point-in-time restore.
• Backups report whether they are continuous and the time range they cover (continuous, timeRange).

​

Changed

• The FalkorDB addon moves from 1.7.15 to 1.8.0. It adds a continuous (aof) backup method, and so point-in-time restore, for sharded deployments (FalkorDB/kubeblocks-addons#41). Its point-in-time restore cuts the AOF with redis-check-aof, so values containing NUL bytes or lines that start with #TS: come back intact; 1.7.15 copied the AOF through the shell, which dropped everything after a NUL byte on a line (FalkorDB/kubeblocks-addons#39). A sharded deployment created before this release gets the aof method when KubeBlocks next reconciles it; see the runbook if an aof schedule is refused.
• POST /api/clusters/<name>/restores/clone no longer requires backupName when restoreTime is given. A continuous backup named without a restoreTime is rejected with a pointer to the point-in-time restore, instead of the generic “Backup still in progress”.

​

Fixed

• On a sharded deployment, the query console could fail to read back a write it had just made, with ERR Invalid graph operation on empty key. It connected through the first shard pod, and when that pod was a replica, as after a failover or an upgrade, it sent every read-only query to replicas. It now connects through a primary.
• The end of install.sh no longer fails with an awk syntax error on macOS, so its summary shows the admin email again. The install itself was not affected.

​

Added

• A query console on each deployment’s page in the Admin UI. Pick a graph, run Cypher, and see the result as a table or, when it holds nodes and relationships, as a graph. Explain and Profile show the query plan. Queries go through the Admin Server with the deployment’s default account, which routes them to the right shard or Sentinel primary. The new clusters.query RBAC resource controls access: read runs read-only queries and Explain, and write also runs queries that change data, and Profile. The predefined operator role has both; the viewer role has neither. Results are capped at adminServer.queryConsole.maxRows rows (default 1000), queries run with adminServer.queryConsole.timeoutMs (default 30000), and every query is audit-logged with its graph, row count and duration, and a hash of the query rather than its text. The editor suggests keywords, functions, and the graph’s labels, relationship types, and property keys as you type, and marks syntax errors before the query runs, with the same Cypher engine as FalkorDB Browser. See Query console.
• The create wizards check, before you click Complete, whether the cluster has room for the new deployment. The review step places each pod on a node with enough free CPU and memory, honoring node selectors, tolerations, and cordoned or NotReady nodes. It also checks that the StorageClass exists, or that there are enough pre-provisioned volumes. It warns when replicas would share a node. The check is advisory and never blocks the create. The endpoint behind it is POST /api/system/capacity-check.
• The same check runs when you scale a deployment, quick-edit it, or change it in the update wizard, for any change to node counts, shards, sentinels, resources, storage, or placement. The deployment’s own pods count as replaced, so the check shows whether the result fits, not just the difference.
• The CLI runs the same check before deployments create, update, replace, scale, and the operations that change a deployment. It prints a warning to stderr when the cluster has no room, then goes ahead anyway. Pass --ignore-capacity to skip the check. See CLI reference.
• Installations whose node capacity is managed outside what the check can see, such as nodes provisioned on demand, can turn it off with adminServer.env.disableCapacityCheck: "true". The UI and the CLI then show no capacity warning. See Helm values.
• RDB exports and imports read and write backup repositories on object storage directly, with datasafed (the tool KubeBlocks backups use), instead of through a mounted volume. Exports are written from the root of the bucket, so every namespace and every installation whose repository points at the bucket, or a replica of it, sees the same files. They no longer need the csi-s3 driver, and repositories with the Tool access method, including Azure Blob, now work. Transfer Jobs run datasafed from the image KubeBlocks uses (adminServer.rdbTransfer.toolsImage). The Admin Server reads repository credentials from the namespaces in adminServer.rdbTransfer.credentialNamespaces (kb-system and default by default).
• In the import dialog, the Repository file source lists every export in a repository on object storage, newest first, read from the files themselves, so an installation can import exports another one wrote, for example after losing a region. A short Job in the deployment’s namespace reads them. Each export says whether every file its manifest lists is present. Also available as GET /api/clusters/{name}/transfers/repository-exports and falkordb-admin rdb repository-exports. See Disaster recovery.

​

Changed

• Exports taken before this release stay in their volume’s folder of the bucket (pvc-<id>/); the export list finds them there, and importing or deleting one still uses the volume. Export schedules created before this release keep writing through the volume until they are recreated.
• The installer raises the release namespace’s Pod Security enforce level to privileged when your values enable the bundled csi-s3 or csi-nfs driver, as it already did for csi-hostpath-driver; their node pods are rejected at baseline. Later runs keep the namespace’s current level instead of resetting it to baseline, so --pod-security-enforce only has to be passed once. The exception is a stricter level while a bundled CSI driver is enabled: a run without the flag raises it to privileged, so pass it on every run. See Pod security.
• With networkPolicy.enabled, the Admin Server’s policy now allows egress to database pods on 6379 and 26379 in every namespace, which the query console needs. Set adminServer.queryConsole.enabled=false to turn the console off and drop the rule.
• The FalkorDB Browser moves from 2.4.0 to 2.7.3. See the falkordb-browser release notes.

​

Fixed

• The first RDB export or import to an object-storage repository in a namespace no longer fails with 403: the Admin Server can now read the repository’s StorageProvider to create its volume there. A refused RDB transfer also names the permission Kubernetes refused, instead of always blaming Jobs.

​

Security

• The FalkorDB Browser signed its sessions with the published placeholder CHANGE_ME_IN_PRODUCTION unless you set falkordb-browser.env.nextauthSecret, so anyone who knew it could forge a Browser session. New installs now get a random secret. On upgrade the installer replaces a placeholder with a random one, which signs Browser users out once. If you upgrade with helm upgrade directly, the upgrade fails while the Browser Secret (<release>-falkordb-browser) still holds the placeholder: replace its NEXTAUTH_SECRET with a random value first. Pipe the patch in, so the value stays off the command line: printf '{"data":{"NEXTAUTH_SECRET":"%s"}}' "$(openssl rand -hex 32 | tr -d '\n' | base64 | tr -d '\n')" | kubectl patch secret <release>-falkordb-browser -n <namespace> --type merge --patch-file /dev/stdin.

​

Added

• Kubernetes ServiceAccounts can call the Admin Server API with their own token (Authorization: Bearer <token>) instead of a login session. List them in adminServer.machineAuth.allowedServiceAccounts as system:serviceaccount:<namespace>:<name>; the server checks each token with a TokenReview and admits listed accounts as admins. The list is empty by default, which keeps machine authentication off. See Helm values.
• On a new install whose nodes span several zones, the installer stops when the default backup repository is a volume on zonal block storage (EBS, Persistent Disk, Azure Disk other than zone-redundant *_ZRS SKUs) or node-local storage. That volume stays where it is created, so the backup pods of databases elsewhere stay Pending. In the terminal UI it offers a ReadWriteMany StorageClass it found instead. --allow-zonal-backup-repo installs anyway; upgrades and --dry-run only warn. See Backups.

​

Changed

• The Kubernetes labels and annotations FalkorDB sets use the falkordb.cloud/ prefix. Existing falkordb.io/ and falkordb.com/ keys are still read, and are moved to falkordb.cloud/ with the same name.
• A PUT /api/clusters/{name} that leaves out a label or annotation managed by another tool keeps its current value. That covers falkordb.cloud/, kubeblocks.io/ and their subdomains, app.kubernetes.io/, and any domain in ADMIN_SERVER_PRESERVED_LABEL_PREFIXES. To remove one, PATCH it to null by name. Reserved annotations, KubeBlocks’ own and the Admin Server’s TLS and pending-settings ones, can’t be removed. See Deployments.

​

Fixed

• The installer’s terminal UI no longer shows the terminal’s password key icon during long steps, and pressing Enter while a step runs no longer aborts the install at the next confirmation.

​

Added

• The deployment page shows a Changes pending notice listing each pending change, how it will be applied, and a link to its operation. The Parameters tab shows when changes are being applied in the cluster, and its fields are locked while a save is in flight.
• On a terminal, the installer runs as a guided, step-by-step UI. It asks only for what the flags left out: the kube context when there are several, registry credentials on a first install without any (checked against the registry), and how to reach the Admin UI. It shows each phase with a spinner and its progress, such as how many pods are ready, and ends with a summary of how to sign in. Helm and kubectl output goes to a log file whose last lines are shown when a step fails. Redirected runs, CI, --dry-run and --debug keep the plain log lines, and --plain forces them. See Terminal output.

​

Fixed

• The installer no longer prints BASH_SOURCE[0]: unbound variable when it is piped into bash (curl ... | bash). A piped run also no longer installs a chart it finds next to the current directory instead of the published one.
• After an install with a gateway Ingress, the installer prints the Admin UI URL (https:// when the Ingress has TLS for the host) instead of saying the Admin UI is not exposed and suggesting kubectl port-forward.
• The sentinels and data nodes of a replication deployment now share one password, so sentinel-aware clients can authenticate against both with the same credentials. With a password chosen, the sentinels use it too; without one, the data nodes use the password KubeBlocks generates for the sentinels. Before, the sentinels always got their own generated password, and the credentials API could return either one. Existing deployments keep their passwords; the sentinels’ is in the <name>-falkordb-sent-account-default Secret.
• In dark mode, the Admin UI’s default buttons, such as Save FalkorDB, show their labels again.
• The Admin UI’s switchover confirmation performs the switchover, and backup and restore lists are scoped to their deployment.
• OAuth sign-in keeps a user’s existing roles when group synchronization isn’t configured. RBAC changes take effect at once instead of after a cache expires.
• Long release names no longer produce Kubernetes resource names over the length limit for the gateway Ingress and the FalkorDB PodMonitor.

​

Security

• The admission policy for the Admin Server also checks which ServiceAccount its RoleBindings bind, which RoleBindings it deletes, and whether its Jobs and scheduled Jobs set hostNetwork, hostPID or hostIPC, or use hostPath volumes or privileged containers. Like the rest of the policy, these checks only warn and audit by default; set adminServer.rbac.admissionPolicy.validationActions to [Deny] to refuse such requests.
• A user who must change their password can only change it or sign out until they do, and new passwords are checked for strength.
• Pod logs and metrics are only returned for pods of the named deployment.
• The CLI no longer sends a stored session cookie to a server given with --url or FALKORDB_ADMIN_URL when that server’s origin differs from the one it signed in to.
• The Admin UI only opens http and https links to external applications.

​

Added

• GET /api/clusters/{name}/config?live=true reports where the pods of a sharded deployment are running settings that differ from their shard’s redis.conf. A short read-only Job in the deployment’s namespace reads them with CONFIG GET. See Parameters.

​

Changed

• The installer stores the values passed with --values, --set and --set-string in the Secret <release>-installer-values and upgrades from the new chart’s defaults plus those values, instead of reusing every value Helm recorded. An upgrade now always takes the FalkorDB version list and image tags from the new chart. The first upgrade migrates the release’s Helm values and logs what it carried over. New installer flags: --show-values, --unset-value and --replace-values. See How the installer keeps your values.
• The upgrade docs now say that upgrading FalkorDB Enterprise with install.sh leaves every existing deployment on its FalkorDB version and addon release, and how to upgrade each one from the Admin UI, the CLI (falkordb-admin deployments upgrade) or the API, instead of editing the KubeBlocks Cluster resource. Upgrade FalkorDB version now matches the current dialog, CLI and API, covers the addon component definition, and explains how to check the running version and that every data node has a persistent volume before an upgrade recreates the pods.
• Parameters & resources and Graph offloading warn that settings made with redis-cli CONFIG SET are lost when a pod is recreated, and say how to set them so they persist.

​

Fixed

• The FalkorDB addon moves from 1.7.13 to 1.7.15. A replicated pod that restarts while no Sentinel can name the primary no longer comes up as a second primary when it holds data: it follows the live primary, takes the role back when the replicas still follow it, or waits. A version upgrade that restarted every pod could otherwise leave two pods replicating from each other with no primary. A restored deployment still bootstraps with fresh Sentinels. Adding a shard no longer skips copying the ACL users when no shard reports a healthy cluster. Point-in-time backups stop on a failed upload instead of skipping ahead, and expired archives are purged again. A retried upload checks that every file is readable before it starts, so a missing file no longer replaces an earlier complete archive with one that lacks it (a read error partway through can still overwrite it; the next run uploads it again). A point-in-time restore fails instead of reporting success when it cannot find or fetch the archives. Existing deployments get these fixes once moved to the new addon release.
• An installer upgrade of a release whose Helm values held an older chart’s falkordb-addon.falkordbVersions list installed the new addon with only the old FalkorDB versions, so deployments could not move to the new ones.
• Links to a heading in the published changelog pointed at the repository path (docs/….mdx#…) and were broken on the docs site.
• Saving parameters on a sharded deployment applies them on every shard. With KubeBlocks 1.2.0-alpha.1, a reconfigure rewrote every shard’s redis.conf but ran CONFIG SET on only one shard. Its OpsRequest also stayed Running forever and held up every later reconfigure or restart (KubeBlocks issue 10459). The Admin Server now runs CONFIG SET on every pod of every shard with a second OpsRequest, through a new falkordb-enterprise-cluster-config-apply OpsDefinition, once each pod’s redis.conf holds the new values. The configure response names it in liveApplyOpsName. The reconfigure OpsRequest times out after 10 minutes and ends Aborted. One left Running by an earlier release is given the same timeout, so it is aborted, on the next reconfigure or restart of the shards. Settings that need a restart, and the LDAP bind password, still need a rolling restart of the shards. See Parameters.

​

Added

• Upgrade the addon: how to move a deployment to the FalkorDB addon release a chart upgrade installed. The chart upgrade leaves every deployment on the addon release it runs.
• The compatibility matrix lists the tested upgrade paths: the releases CI upgrades each new release from, one for each addon version a release since 1.0.0-beta.1 shipped. Each run moves every database to the new addon release.
• Rebalance a sharded deployment from the Admin UI (Actions > Rebalance shards on the deployment page), the CLI (falkordb-admin operations rebalance) or the API (POST /api/clusters/{name}/ops/rebalance). It spreads the hash slots evenly across the shards, with or without TLS, through the addon’s falkordb-cluster-rebalance OpsDefinition. Adding or removing shards still moves slots on its own; rebalance when the spread is uneven afterwards. The Admin Server refuses a rebalance while another operation runs, and a shard-count change while a rebalance runs. See Scaling.
• Move hash slots between the shards of a sharded deployment from the new Slots tab, the CLI (falkordb-admin operations reshard --slots 0-999 --to shard-98x [--from shard-4z9]) or the API (POST /api/clusters/{name}/ops/reshard), through the addon’s falkordb-cluster-reshard OpsDefinition. The Slots tab shows which slots each shard owns (also GET /api/clusters/{name}/slots), read by a short read-only Job in the deployment’s namespace, and a move is checked against that map before it starts. See Scaling.

​

Changed

• New deployments now run FalkorDB core v4.22.2 (previously v4.22.0). It fixes crashes on RESTORE … REPLACE of a live graph, in reduce() when the iterator shadows a bound variable, and when a unique constraint checks a string with surrounding whitespace, and refuses truncated or malformed RDB payloads instead of crashing. 4.22.0, 4.20.4 and 4.20.1 remain available, so existing deployments keep reconciling and can be upgraded to 4.22.2 in place.
• The FalkorDB addon moves from 1.7.7 to 1.7.13. Rebalancing a sharded deployment now uses redis-cli --cluster rebalance from the FalkorDB image instead of an ape-dts job, which no longer echoes the password. The unused falkordb-addon.apeDts value is removed. 1.7.11 adds the falkordb-cluster-reshard OpsDefinition that moves given slots.
• Deployment settings fall into three categories, which the API, the Admin UI and the CLI follow (how settings are applied):
  • Applied on the fly: every config.enterprise setting, and many more config.server directives than before, among them loglevel, hz, save, maxclients and the replication and cluster timeouts. These used to restart the pods.
  • Needs a restart: config.graph settings, and config.server directives such as databases and io-threads. The pods restart as part of the same change.
  • Can’t be modified: the directives the addon manages are refused. That now includes appendfilename, pidfile, daemonize, cluster-port and cluster-preferred-endpoint-type.
• A setting can be undone again. In a schemaVersion: 1 PATCH or PUT, null sets a config.enterprise setting back to its default. When the default is empty, null or "" empties it, so LDAP authentication can be turned off. "" also empties a config.server directive applied on the fly. Emptying a setting needs addon 1.7.11 on the deployment, set with spec.componentDefinition. POST /ops/configure, the Admin UI and the CLI (--parameter key) do the same.

​

Fixed

• Sharded deployments form one cluster (FalkorDB addon 1.7.13). A shard that started slowly could form a cluster of its own, most often when restoring a backup into a new deployment, so the deployment reported Running with its data split between two clusters. A secondary that failed to join its shard restarted forever with “Node is not empty”; it now rejoins.
• Adding a Sentinel to a replicated deployment finishes (FalkorDB addon 1.7.12). With 1.7.11 the new Sentinel’s member-join action could not authenticate to it, KubeBlocks retried it indefinitely, and the deployment stayed Updating and refused every other operation.
• A volume expansion (POST /api/clusters/{name}/ops/volume-expand) of a deployment on ephemeral storage is refused with 400. KubeBlocks accepted it and never finished it, and the deployment then refused every other operation.
• RDB export and import work on FalkorDB 4.22. Their Jobs run redis-rdb-cli v0.9.12 (previously v0.9.11), which reads RDB format version 15; every export and import of a 4.22 deployment failed with “can’t handle RDB format version 15”.
• FalkorDB 4.20.7 is no longer offered: no falkordb-enterprise-db:v4.20.7 image was ever published, so a deployment created or upgraded to it never started (ImagePullBackOff). 4.20.4, which is published, takes its place next to 4.20.1 and 4.22.0.
• With the new FalkorDB addon:
  • Sharded backups can be restored into a deployment with TLS on. The restore connected without TLS, so every shard refused it and the deployment came up empty.
  • A sharded restore fails when ape-dts fails or times out. It used to report success regardless.
  • A database container whose server crashes now exits non-zero, so Kubernetes reports the crash instead of a clean exit, and its logs no longer end every line with ^M.
  • Resetting the Sentinel master resets it on every Sentinel and fails if any of them fails. A Sentinel that joins copies the ACL users of an existing one.
  • A rebuilt Sentinel can be registered again with the falkordb-register-to-sentinel operation, which points it at the current primary and copies the ACL of an established Sentinel.

​

Security

• A ValidatingAdmissionPolicy now flags, and from the next release refuses, any request by the Admin Server that would run a pod as a ServiceAccount of its choosing, which its RBAC alone allowed: it could bind its namespace-scoped role into another namespace and create a Job there as any ServiceAccount, the KubeBlocks operator’s included. The policy applies to the Admin Server’s own requests only and allows everything it does today. It needs Kubernetes 1.30 or later; turn it off with adminServer.rbac.admissionPolicy.enabled=false. In this release it only warns and records an audit event (validationActions: [Warn, Audit]); the next release refuses. Set adminServer.rbac.admissionPolicy.validationActions to [Deny] to enforce it now. The Admin Server also loses write access to KubeBlocks ClusterDefinitions, ComponentDefinitions and their versions, which it only ever read. See Security.

​

Added

• RDB export and import, from the Admin UI, the CLI and the API. Export a deployment to RDB files in a backup repository, once or on a schedule with retention. Import into an existing deployment from an export, a repository file, another deployment or a redis:// URI, either merging (existing keys are kept) or replacing (the target is flushed first). File imports are checked with the target’s redis-check-rdb before anything changes, and a snapshot of the target is taken first so a failed import rolls back automatically (rollback: auto, the default) or on request (manual). Finished transfers are cleaned up after the rdb_import_retention_days and rdb_export_retention_days Admin Settings. Transfers need the new clusters.transfers permission. See RDB export and import.
• A K3s deployment guide, covering snapshot CRDs and Longhorn or the bundled hostpath CSI driver for backups.
• Database health alerts, created with the Admin Server alerts when alertRules.enabled=true: a node or its metrics down, a sharded deployment in the fail state, broken or lost replication, memory near maxmemory, a failed BGSAVE, a nearly full data volume, and a failed backup Job. Turn them off with alertRules.databaseRules.enabled=false. The production guide now recommends enabling podMonitor and alertRules.
• The Admin UI forwards /api to the Admin Server (adminUi.apiProxy.enabled, on by default), so a single kubectl port-forward to the Admin UI Service is enough to use it. With network policies on, the Admin UI may reach the Admin Server on its API port.
• install.sh --quick-access, install.sh --local-csi-hostpath auto|enable|disable and uninstall.sh --force.
• Choose who issues a deployment’s TLS certificates in the create wizard. Each option works for every topology, including Sentinel and sharded deployments:
  • Issued by FalkorDB Enterprise, the new default. The Admin Server creates a CA and a certificate for the deployment. The certificate names every pod, the deployment’s Services and its external domain.
  • cert-manager, from an Issuer or ClusterIssuer you choose. The option is disabled when cert-manager is not installed. The chart’s RBAC now lets the Admin Server read cert-manager issuers and manage Certificates in the namespaces it manages.
  • Your own Secret, as before.
• TLS certificates are kept current. Every hour, the Admin Server renews certificates it issued once fewer than 30 days remain, and adds new shards’ names to certificates that FalkorDB Enterprise or cert-manager issues. The FalkorDB nodes then reload the new certificate in place, without a restart, through a Custom OpsRequest that runs CONFIG SET on each node; Sentinel, which cannot reload, is restarted. This can take more than one hourly check. If the reload fails, the deployment is restarted instead. This also applies certificates that cert-manager renews, and a Secret you provide that you have updated, though the Admin Server never changes a certificate you provide. Before, a changed certificate never reached the pods. A sharded deployment whose certificates FalkorDB Enterprise or cert-manager issues reloads its certificate once after it is created, to add its shards’ names. A sharded deployment without persistent volumes is never restarted automatically, because it would lose its cluster state; the audit log says when it needs a restart. The chart’s RBAC lets the Admin Server create the two OpsDefinitions that do the reload, falkordb-enterprise-tls-reload and falkordb-enterprise-cluster-tls-reload.
• The deployment page shows who issues the TLS certificates and when the current one expires. The credentials API returns tlsIssuer, tlsIssuerRef and certificateExpiresAt, and GET /api/clusters/tls/cert-manager-issuers lists the cert-manager issuers a new deployment can use.

​

Changed

• The installer no longer publishes the Admin UI by default. Quick access, which put the Admin UI on a public address over plain HTTP, is now opt-in with --quick-access (--no-ingress implies it). Without it, the installer prints the kubectl port-forward command. Existing installs keep their access settings.
• The bootstrap admin password is generated on first install instead of defaulting to a well-known value, and must be changed at first sign-in (mustChangePassword: true). It is stored in the Secret <release>-initial-admin-password, and the installer and the chart’s install notes print how to read it. On installs upgraded from earlier releases, anyone who signs in with the old published default password must choose a new one, and that password is refused when creating a user or changing a password.
• The installer enables its bundled single-node csi-hostpath-driver in place of local non-CSI storage (local-path, minikube or microk8s hostpath) only on a single-node cluster. On a multi-node cluster it leaves storage alone and warns, because the driver keeps every volume on one node. Installs that already use it keep it. uninstall.sh makes the original default StorageClass the default again.
• uninstall.sh refuses to run while FalkorDB deployments exist, unless --force is given. Removing the release deletes the definitions those deployments reference, after which KubeBlocks can’t reconcile or heal them.
• The default backup repository is kept on helm uninstall (backupRepository.keep) and its volumes use the Retain reclaim policy. The production guide now requires an object-storage backup repository.
• The pre-upgrade hook deletes the addon’s OpsDefinitions and ParametersDefinitions only when they are stale: not owned by this release, from another addon version, or carrying relocated fields. It used to delete them on every upgrade, which could fail operations running during the upgrade.
• The create page now starts on the Prod template, so a deployment created with the defaults has high availability, deletion protection and, when a default backup repository is configured, a daily backup (except sharded deployments; see below).
• New deployments prefer to place the pods of each replica set, Sentinel group and shard on different nodes, then different zones, which makes it less likely that one node failure takes a primary and its replicas down together. The rule is a preference, not a guarantee: deployments still schedule, possibly together, on clusters with too few nodes or capacity.
• The backup step of the create wizard no longer asks for a repository: scheduled backups always go to the default backup repository. When there is no default repository, the wizard and Quick Create create the deployment without a backup schedule and say so, and the API answers 400 to an explicit backup request.
• The create wizard’s username is fixed to the built-in default account, the only account whose password can be set at create time.
• A deployment restored from a backup now copies more of its source: the termination policy (so a restored Prod deployment is protected too), the FalkorDB module configuration, services, external domain and labels. Deletion protection is lifted the same way as on any deployment, by changing its termination policy in the update wizard.

​

Fixed

• Every image and both Helm charts now carry a signed CycloneDX bill of materials, as the 1.0 release notes said they did. Until now, only the database image had one, as an unsigned BuildKit SPDX document, so cosign verify-attestation --type cyclonedx found nothing. An image’s SBOM describes its linux/amd64 platform. A chart’s SBOM lists its subcharts and every image it can pull, including the ones KubeBlocks resolves at runtime.
• The cosign public key is published at https://falkordb.github.io/FalkorDB-Enterprise/cosign.pub. The location the docs gave before was in a private repository and held no key, so signatures could not be verified.
• Sharded backups can be restored. The FalkorDB addon moves from 1.7.5 to 1.7.7, which ships ape-dts 2.0.26.1. Older ape-dts releases hung on the keys FalkorDB stores graphs in, so a sharded restore stalled with only part of the data even though the backup had completed. The Prod template turns sharded backups on again, and the sharded create wizard turns them on when a default backup repository exists, as the standalone wizard does. The new addon also:
  • Lets the shards of a sharded deployment find each other again after every pod restarts at once, such as after a Stop and Start.
  • Finishes giving a new shard its slots when the first attempt is interrupted. A retry used to stop as soon as the shard had joined the cluster, which could leave it owning no slots, and so no data, while the deployment showed as ready.
• Backups and backup schedules created through the API for a sharded deployment without a backupPolicyName now use its <name>-shard-backup-policy. They looked for <name>-falkordb-backup-policy, which only standalone and replication deployments have, and failed with “Backup policy not found”.
• The create wizards no longer turn backups back on after you turn them off. The backup repositories are refetched every minute, and each refetch re-enabled backups whenever a default repository existed. The standalone wizard also preselects the default repository instead of the first one listed.
• Promoting somebody in the Enterprise Portal right after inviting them no longer fails with “Zitadel reported an existing grant that could not be found”. Zitadel can take a moment to list a grant it has just accepted, so the portal now waits up to 10 seconds for it.
• Databases now get PodDisruptionBudgets that match their topology. KubeBlocks creates none for database pods, so a node drain could evict a primary and its replica, a whole shard, or enough sentinels to lose the quorum, at once.
  • A primary with replicas, and each shard that has a replica, keeps at least one pod available.
  • Sentinels keep their quorum available: at least 2, or a majority when there are more than 3.
  • A component with no redundancy (a single primary, one or two sentinels) gets no budget, so it never blocks node maintenance.
  Budgets follow scaling within a minute, apply to databases created by earlier versions too, and are deleted with the shard or database they protect.
• The termination policy chosen at create time is applied. Every deployment was created with Delete, so the Prod template’s DoNotTerminate had no effect.
• Deleting a deployment with deletion protection (DoNotTerminate) is refused with a 409 that explains how to turn it off, before its backup schedules and policies are removed. KubeBlocks would otherwise leave it stuck in Deleting.
• The backup schedule chosen in the create wizard is created once the deployment is running. It was silently dropped before. An invalid cron expression is rejected with a 400 before anything is created, and a schedule is no longer lost when the deployment briefly leaves Running, for example while create-time enterprise settings are applied.
• The password chosen in the create wizard is applied to the deployment’s default account. It was silently dropped, so every deployment got a generated password instead.
• Editing a deployment in the update wizard no longer resets its termination policy to Delete. The API now reports each deployment’s termination policy, and the wizard only sends it when it was changed.
• Creating a deployment answers 400 instead of 500 when the request is invalid, such as an invalid topology or backup schedule.
• TLS chosen in the create wizard is applied. It was silently dropped, so every deployment accepted plain connections. Every component (data nodes, Sentinel, shards) uses TLS, and the deployment page shows the CA clients need and opens the Browser with TLS on. Certificates issued by KubeBlocks are only offered for standalone deployments and replication without Sentinel, because KubeBlocks gives each component its own CA.
• FalkorDB Enterprise module settings (falkordbe.*) now reach sharded deployments. Settings chosen in the create wizard and changes saved on the Parameters tab were sent to the falkordb component, which a sharded deployment does not have, so they never reached the shards. The Parameters tab can also read the configuration of a sharded deployment now. Operations submitted without a componentName (restart, reconfigure, switchover, expose, scaling and volume expansion) target the shard component on sharded deployments and falkordb otherwise.
• The Parameters tab explains when a deployment’s Redis configuration is not available yet, which is the case until KubeBlocks has created its pods, instead of reporting a failure, and checks again every 10 seconds. The API reports this case as a 404 with error: RedisConfigNotFound. While the configuration cannot be read, the Enterprise Module Parameters section no longer shows the module defaults, so saving can no longer overwrite the deployment’s real settings.
• When the admin server is not allowed to read ConfigMaps in a deployment’s namespace, the Parameters tab now says so instead of showing a generic failure.
• Enterprise module settings chosen in the create wizard are no longer discarded when a lookup of the new deployment fails transiently, for example with apiserver not ready. The server keeps waiting for the deployment instead.
• A deployment can now be deleted when the license quota is fully used or exceeded. When usage is over a limit, the license no longer puts the admin UI into read-only mode. Only actions that would grow usage past a limit are refused, such as creating a deployment or scaling one out or up. Deleting, scaling down, restarting, stopping and reconfiguring keep working. Deleting a deployment is also accepted when the license has expired or is invalid. An ended trial now reports the expired state instead of locked.
• Creating or editing a deployment as raw YAML is now checked against the license limits, like the form-based create and update.
• Sharded deployments created from the Admin UI now get persistent volumes. The sharded wizard sends its storage settings for the shards, and creation ignored them, so every such deployment ran on pod-local storage even though the wizard and the cost estimate showed a volume. When a pod was recreated, by a FalkorDB version upgrade, a node drain or an eviction, it came back empty and outside the cluster, which then reported a missing shard and could not finish the upgrade. Existing sharded deployments made with the wizard are not changed. To check one, run kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<deployment>: an affected deployment lists no claims (other deployments’ claims in the namespace don’t count). Move each affected deployment’s data before anything restarts its pods: after upgrading, create a new sharded deployment with the wizard and copy the graphs into it from the old one, then delete the old one. A clone from a backup works too, now that sharded restores bring the data back (#263, #266); check the data on the clone before you delete the old deployment. Before creating the new deployment, check which storage class it will use. If the installer made csi-hostpath-sc the default, which it does when the cluster’s default was local-path, every volume is created on a single node; pick a storage class that spans nodes (#268). Cloning a deployment from a backup now gives the clone volumes even when its source had none, sized at twice the backup and at least 8Gi on the default storage class; before, a clone of a deployment without volumes had none either. Standalone and replication deployments were not affected. See #249.
• Editing a sharded deployment no longer removes its shard settings. An edit that didn’t change the shard template itself, such as adding or removing a service on the Networking tab or saving on the Parameters tab, sent the shard without its template or sharding definition, and the merge patch dropped them: the shards’ component definition, replicas, resources and volumes. See #260.
• Sentinels of new replication deployments get a 1Gi volume on the deployment’s storage class. On pod-local storage, a drained or restarted sentinel came back monitoring nothing, so automatic failover silently stopped working, and after a full restart pod-0 became primary even if another pod held newer data. Existing deployments keep their sentinels as they are. See #267.
• Downgrading FalkorDB is refused. A newer version can write data an older one can’t load (4.22.0 writes RDB encoding v20), so requesting the previous version left every pod unable to start, and the docs described it as a rollback. The upgrade and update requests now answer 400, prereleases included, and so does any version change on a deployment whose running version can’t be determined. A deployment created from YAML without a pinned version now shows the version KubeBlocks resolved for it, in the deployment list and its details, instead of unknown, and editing one no longer fails by sending unknown back as its version. The update wizard offers only the current and newer versions, and the docs say to restore a backup taken before the upgrade instead. See #272.
• Editing a sharded deployment now shows its storage class and size on the Sharding step. The step showed them blank, so a size entered there replaced the volume settings without the storage class. An invalid storage size is now rejected with a clear error, on create and on edit, instead of failing in Kubernetes. Sizes with decimal suffixes such as 100G are accepted, as Kubernetes accepts them.

​

Security

• The Admin Server always refuses to create databases in, and to take Secret access in, kube-* namespaces and the namespaces in adminServer.managedNamespaces.denied (kb-system by default; the installer adds a custom --kubeblocks-namespace). Before, any user allowed to create a deployment could give the Admin Server read-write Secret access in kube-system. On startup the Admin Server removes the binding it made in a namespace that is now denied.
• A default install no longer exposes the Admin UI over plain HTTP with a well-known admin password (see Changed).

​

Fixed

• A first install from registry.falkordb.cloud no longer stops at the preflight pre-install hook with ImagePullBackOff. The preflight and browser-encryption-key hook Jobs now reference the registry pull Secret like the chart’s other workloads, and each gains its own imagePullSecrets list for a private mirror.
• The FalkorDB Browser pod now pulls with the registry pull Secret. The Browser subchart reads global.imageRegistry but not global.imageCredentials, so set the new falkordb-browser.imagePullSecrets for a manual Helm install; install.sh now writes it for you. The chart’s notes warn when it is missing.
• The chart’s notes, values.yaml and docs no longer describe registry.falkordb.cloud as anonymous. Every image there requires authentication. For a manual first install, create the pull Secret beforehand, set global.imageCredentials.name to it with create: false, and list it under falkordb-addon.imagePullSecrets and falkordb-browser.imagePullSecrets: a chart-created Secret doesn’t exist yet when the pre-install hook pulls its image. Do the same before upgrading a release that has no pull Secret yet. See Private images.

​

Added

• Cost showback: the Admin UI can now estimate what each deployment costs to run and total spend across the fleet. Because FalkorDB Enterprise installs on any Kubernetes substrate, the underlying infrastructure price is supplied by the operator as a rate card under Settings → Cost Showback (or adminServer.bootstrap.settingsConfig.settings.cost in Helm values), and applied to the CPU, memory, and storage each deployment reserves. Costs appear on the dashboard, on deployment cards, and on the deployment General tab. Cost visibility follows deployment visibility: fleet totals require clusters:list and a single deployment’s cost requires clusters:read, each scoped to the namespaces that permission already covers. Before a rate card is configured the same views report reserved capacity and each deployment’s share of the fleet. The full per-deployment breakdown lives on Cluster Statistics, which the dashboard and deployment pages link to. See Cost Showback.
• Cost estimates before the spend is committed: the create wizards show what a deployment will cost on their Review step, and the update wizard, Scale and Quick Edit dialogs show the change as a before-to-after figure. Estimates update as resources are adjusted and are served by POST /api/clusters/costs/estimate, which prices a supplied spec and reads no existing deployments.

​

Changed

• New deployments now run FalkorDB core v4.22.0 (previously v4.20.7). It adds A* and k-shortest path-finding procedures and a CCH path index, and fixes crashes on MERGE after a failing clause and on replicas applying updates. 4.20.1 and 4.20.7 remain available, so existing deployments keep reconciling and can be upgraded to 4.22.0 in place. The upgrade is one-way: 4.22.0 writes RDB encoding v20, which earlier releases cannot load, so take a backup before upgrading a deployment.

​

Fixed

• The install commands in the docs and the Enterprise Portal’s install guide now pass --registry-username and --registry-password. The chart is pulled from the private registry.falkordb.cloud registry, so a command without them failed at the chart pull. The portal fills in the registry token the cluster pulls with (its own, or the organization’s) once it is revealed, and the installer creates the image pull Secret from the same values. The portal’s credentials file now holds only the license. See Quickstart.
• Invitations sent from the Enterprise Portal now open a page the invited person can actually complete. Zitadel’s default invitation link points at its legacy login application whatever the instance serves — invitations are the one notification it does not rewrite for the current one — so the email arrived and the account could not be set up. The portal now names the link itself, and does the same for password resets.
• Accepting an invitation, verifying an email address or setting a new password now ends on the Enterprise Portal instead of on the identity provider’s own “you are signed in” page. Those flows start in a mailbox with no application to return to, so the portal configures its public URL as the identity provider’s default redirect. A Zitadel service user without permission to set it is not an error: the emails are sent as before and the portal logs what to grant.
• Re-inviting somebody who has already set up their account now completes and says no email was needed, instead of reporting that the identity provider refused the change and to try again shortly. This also repairs re-inviting somebody who was previously removed: their account still has a password, so the identity provider always refuses the invitation, and the failure used to abandon the invitation before their removal was undone — leaving them able to sign in and then bounced to “no access”, with nothing in the portal able to fix it.
• Licensed CPU and memory usage was over-counted for sharded deployments. A sharded cluster’s top-level replicas and resources mirror its shard template rather than describing a separate component, so they were being counted in addition to the shards themselves — inflating usage by one shard’s worth, or 1/shardCount. Sharded deployments now report the capacity they actually reserve, which lowers their counted usage against licensed limits.

​

Security

• Published images shipped the OS packages that were current when their runtime layer was first built, not the ones current at build time. Every image Dockerfile already ran apk upgrade, but nothing in that stage changed between runs, so the layer was restored from the build cache and the upgrade never re-ran. The most recent effect was twelve High CVEs against libssl3 and libcrypto3 — openssl 3.5.7-r0, which Alpine had already fixed in 3.5.8-r0. The runtime stage is now excluded from the cache and its base image re-pulled on every build, so an image carries the patches available the day it was published. Only that stage rebuilds; dependency and compile layers still come from the cache. Pull the latest images to take the fix.

​

Breaking changes

• Upgrading from 0.3.x requires moving image pulls from ghcr.io to registry.falkordb.cloud, a change first made in 0.4.0. See Migrate from 0.3 to 1.0, which folds in everything 0.4 required so 0.3.x installs can upgrade in one step.

​

Added

• global.kubernetesServiceHost and global.kubernetesServicePort override the API server address every in-cluster client derives from the KUBERNETES_SERVICE_* variables the kubelet injects, for clusters where the API server’s ClusterIP is unusable — a public endpoint that requires SNI, or a firewall that rejects it. install.sh --kubernetes-service-host sets them and fans the value out to the KubeBlocks release; examples/values-apiserver-dns.yaml does the same for a plain helm install. Both default to empty and render nothing when unset. FalkorDB addon 1.7.5 reads the same two values, so the database pods are covered without any extra configuration.
• global.extraEnv appends environment variables to every container the chart owns. It stops at the chart boundary: database pods take falkordb-addon.extraEnv.
• docs/reference/helm-values-reference.mdx lists every value the chart accepts with its real default. It is generated from values.yaml by node scripts/generate-values-docs.mjs, and CI fails if it is stale, so the published defaults can no longer drift from the chart. The hand-written reference/helm-values page stays the curated tour of the values that matter.
• global.imageCredentials is the single place private registry credentials are configured. With create: true the chart owns the pull Secret; otherwise it expects one to already exist in the release namespace. global.imagePullSecrets adds further secrets to every workload the chart owns.
• The admin server replicates the registry pull Secrets from its own namespace into every namespace it provisions a database into, so no namespace has to be seeded by hand before a database is created in it.
• install.sh --version VERSION selects the FalkorDB Enterprise chart version to install, and accepts a leading v. --chart-version remains as an alias. Re-running the installer with a different value upgrades or downgrades the release.
• The installer reports the chart version it resolved, and the plan shows the version transition for an existing release.
• A published changelog and compatibility matrix, generated from this file and the release tags, plus migration guides under docs/upgrades/migrations/.
• install.sh --channel beta installs the latest beta release. Beta releases are published as prerelease versions, so a default install never picks one up.
• The installed chart version and release channel are reported on the Diagnostics page, and recorded in the support package manifest and its viewer, so a bundle identifies the build it came from without being unpacked.
• The chart prints post-install notes naming the release, the pull Secret in use and whether the chart owns it, and warns when falkordb-addon.imagePullSecrets omits that Secret, which would leave database pods pulling anonymously.
• networkPolicy.enabled creates NetworkPolicies for the Admin Server and Admin UI. Both set policyTypes: [Ingress, Egress], so anything not named is denied. networkPolicy.ingressControllerNamespace, .monitoringNamespace and .dnsNamespace say where those callers run, and networkPolicy.externalEgress.ports/.cidrs cover the kube-apiserver and the identity provider, which NetworkPolicy can only express as address ranges. networkPolicy.adminServer.extraIngress/.extraEgress and the adminUi equivalents append whole rules for anything else. Off by default: a CNI that does not implement NetworkPolicy accepts the objects and silently enforces nothing.
• adminServer.metrics.basicAuth.username/.password, or .existingSecret, put HTTP Basic auth on /metrics. The chart’s own PodMonitor picks the same credentials up. Setting only one of the pair fails the render rather than quietly leaving the endpoint open.
• adminServer.image.digest and adminUi.image.digest pin images by content. A digest takes precedence over the tag and is the only reference a registry cannot silently repoint.
• adminServer.managedNamespaces.pattern restricts which namespaces may hold databases. It is an anchored regular expression matched against the namespace name, enforced on the server, so it also covers API clients and restores.
• install.sh --pod-security-enforce, --pod-security-audit and --pod-security-warn set the Pod Security Admission labels the installer applies to the namespaces it creates.
• A security reference describing the whole posture in one place — every RBAC grant and why it exists, which controls are enforced by Kubernetes rather than by the product, and where the limits are — plus Pod security, Network policy and Supply chain for the detail. CI re-checks the claims against the rendered chart on every change, so removing a control from the chart fails the build.

​

Changed

• The FalkorDB addon subchart moves from 1.7.2 to 1.7.5.
• The Admin Server’s Secret and ConfigMap access is no longer granted cluster-wide. It lives in a ClusterRole that is only ever bound per namespace: into the release namespace by the chart, and into each database namespace by the Admin Server as it provisions one. The server has no access to those objects in any namespace it has not been bound into. Existing installs are reconciled on startup, so an upgrade needs no manual step.
• The Admin Server no longer holds namespaces: list. The namespace picker in the console therefore lists only namespaces that already hold a database, plus the release namespace; type a name into the field to deploy into a new one.

​

Security

• Every workload the chart owns — Admin Server, Admin UI and both hook Jobs — runs as a non-root user with readOnlyRootFilesystem, allowPrivilegeEscalation: false, all capabilities dropped and a RuntimeDefault seccomp profile, and so satisfies the restricted Pod Security Standard. The Admin UI no longer mounts a ServiceAccount token it has no use for.
• The installer labels the namespaces it creates for Pod Security Admission, and raises the release namespace to privileged only when it auto-enables the bundled CSI hostpath driver, whose pods require it.
• The Admin Server’s rolebindings: create grant is bounded by bind restricted with resourceNames to the single namespace-scoped ClusterRole, so it cannot be used to grant itself any other role. No role the chart owns uses a wildcard.
• The session signing key is no longer passed through Helm values. The installer creates the Secret out of band and hands the chart only its name, so the key does not appear in the process table, in the Helm release Secret, or in helm get values.
• Container images and the Helm chart are signed with cosign, and images carry a CycloneDX bill of materials as an attestation. scripts/mirror-images.sh copies the signatures alongside the images, so a mirrored registry stays verifiable. Verification is not enforced at admission time; see Supply chain for the commands and for how to make it a boundary.
• A release name long enough to fill the 63-character budget no longer collapses the Admin Server’s namespace-scoped ClusterRole onto the name of its cluster-wide one. The suffix was appended before truncation, so it could be cut off entirely, leaving two objects sharing a name and the cluster-wide ClusterRoleBinding pointing at whichever applied last — the role carrying Secret access. CI now renders the chart under a maximum-length release name and fails if any two objects collide.

​

Fixed

• Requesting a chart version while running the installer from a repository checkout no longer silently installs the working-tree chart. The published chart is used instead.
• The installer no longer leaves the bundled CSI hostpath driver unschedulable on clusters whose default StorageClass is not CSI-capable. Pod Security Admission labels were applied before the driver was enabled, so its privileged pods were refused admission and the install timed out waiting for a StatefulSet that never got a pod.
• Re-running the installer against an existing release no longer tears down the bundled CSI hostpath driver it had previously enabled.
• Setting adminServer.rbac.create=false while letting the chart create the ServiceAccount no longer breaks database creation. The Admin Server was still pointed at a namespace-scoped ClusterRole the chart had not created, so it tried to bind a role it held no bind permission on and every attempt failed with an opaque 403.
• Listing namespaces no longer reports a namespace as absent when the API server refuses the request. Only “not found” and “gone” are treated as a namespace that has disappeared; a lost permission or an unreachable API server is surfaced instead of silently shortening the list.

​

Added

• Scheduling policy support for deployments. Node selectors and tolerations can be set per component for FalkorDB, Sentinel, and shards, from the deployment wizard and from the Admin Server API.
• Administrators can reset a user’s password.

​

Changed

• The falkordb-browser subchart moves from 2.0.9 to 2.4.0. It now reads global.imageRegistry, so the umbrella chart no longer overrides falkordb-browser.image.repository. Mirrored registries need falkordb-browser:v2.4.0 before upgrading.
• The csi-s3 subchart moves from 0.43.4 to 0.43.7.

​

Fixed

• csi-s3 and csi-driver-nfs images updated to clear reported vulnerabilities.

​

Breaking changes

• First-party images and the Helm chart are published to registry.falkordb.cloud instead of ghcr.io. Existing image pull secrets, mirror configurations, and any pinned ghcr.io image references have to be updated. See Migrate from 0.3 to 0.4.
• The chart no longer injects a default image registry through the installer. The registry comes from the chart’s own global.imageRegistry value, so a registry supplied through -f values.yaml is no longer outranked.

​

Added

• Publish summary scripts for the enterprise database image.

​

Fixed

• Helm upgrades read the release revision correctly and wait for addon definitions to reconcile before continuing.
• Admin UI: max uptime renders as a readable duration, memory metrics agree between tabs, and small non-zero CPU and memory percentages are no longer rounded away.

​

Added

• Scripts to collect, mirror, and verify the third-party images the chart pulls, for air-gapped and mirrored-registry installations.

​

Changed

• The FalkorDB addon subchart moves from 1.7.1 to 1.7.2.
• The dm-sql-to-falkordb subchart moves from 1.1.2 to 1.1.6.

​

Added

• External DNS support, including per-pod DNS records and configuration from the standalone and sharded deployment wizards.
• A confirmation dialog for starting and stopping a deployment.

​

Changed

• The FalkorDB addon subchart moves to 1.7.1.
• User-facing terminology changed from “cluster” to “deployment”.

​

Fixed

• Deployments stuck in Pending can be updated, so a failed create no longer strands them.