FalkorDB Enterprise release notes and changelog

​

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.