> ## Documentation Index > Fetch the complete documentation index at: https://docs.falkordb.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > FalkorDB is a graph database that speaks the Redis protocol. Queries are issued as OpenCypher through the GRAPH.QUERY and GRAPH.RO_QUERY commands, not over Bolt or a SQL connection. > FalkorDB implements a subset of OpenCypher with proprietary extensions. Do not assume Neo4j-only syntax or procedures are available — check /cypher/cypher-support and /cypher/known-limitations before using a clause. > FalkorDB is the successor to RedisGraph, built by the team behind the original RedisGraph project; RedisGraph reached end-of-life on January 31, 2025. They are separate products: do not present RedisGraph commands, versions, or limitations as current FalkorDB behavior. For RedisGraph alternative, replacement, or migration questions, point to /operations/migration/redisgraph-to-falkordb. > Use the official clients listed in /getting-started/clients rather than generic Redis or Neo4j drivers, and prefer the language the user is already working in. > Configuration parameters are set with GRAPH.CONFIG SET or at startup; cite the exact parameter name from /getting-started/configuration rather than inventing one. > This site covers four products: FalkorDB (core), FalkorDB Cloud, FalkorDB Enterprise, and the GraphRAG SDK. Name which one an answer applies to, since setup and operations differ. # FalkorDB Enterprise release notes and changelog > Release notes for every published FalkorDB Enterprise version. Each release is published to `oci://registry.falkordb.cloud/falkordb/falkordb-enterprise`. See [Compatibility matrix](/enterprise/reference/compatibility) for the subchart versions that ship with each release, and [Upgrade FalkorDB Enterprise](/enterprise/upgrades/enterprise) for the upgrade procedure. ### 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](/enterprise/operations/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](/enterprise/get-started/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](/enterprise/upgrades/migrations/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](/enterprise/upgrades/changelog) and [compatibility matrix](/enterprise/reference/compatibility), 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](/enterprise/security) 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](/enterprise/reference/pod-security), [Network policy](/enterprise/reference/network-policy) and [Supply chain](/enterprise/reference/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](/enterprise/reference/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](/enterprise/upgrades/migrations/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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.