> ## 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. # TLS encryption for FalkorDB deployments > Turn on TLS for a deployment, choose who issues its certificates, and how certificates are renewed. A deployment with TLS only accepts encrypted connections. That covers clients, replication between nodes, Sentinel, and the bus that connects the shards of a sharded deployment. You turn TLS on in the **Encryption** step of the create wizard, and choose who issues the certificates there. TLS is set when a deployment is created. You cannot turn it on or off for an existing deployment. ## Choose who issues the certificates Every component of a deployment has to trust the others, so all of them share one CA. The issuers differ in what they need from you and in which deployments they work for. | Issuer | Works for | Renewal | What you set up | | - | - | - | - | | **Issued by FalkorDB Enterprise** (default) | Every topology | Automatic | Nothing | | **cert-manager** | Every topology | Automatic, by cert-manager | cert-manager and an `Issuer` or `ClusterIssuer` | | **Your own Secret** | Every topology | When you update the Secret | A Secret with a certificate, key and CA | | **Issued by KubeBlocks** | Standalone, and replication without Sentinel | Never; valid for 100 years | Nothing | ### Issued by FalkorDB Enterprise The Admin Server creates a CA for the deployment and a certificate signed by it. * The CA is valid for 10 years. It is stored with its key in the Secret `-tls-ca`, which never leaves the deployment's namespace and is not mounted into any pod. * The certificate is valid for one year and is stored in the Secret `-tls`. It is renewed 30 days before it expires, signed by the same CA, so clients keep working without changes. * The certificate names every pod of every component, the deployment's Services, `localhost`, and its external domain when it has one. Clients that verify hostnames can connect by any of those names. Both Secrets belong to the deployment and are deleted with it. ### cert-manager The Admin Server creates a cert-manager `Certificate` named `-tls` in the deployment's namespace. It asks for the same names as the FalkorDB Enterprise issuer, and is signed by the `Issuer` or `ClusterIssuer` you select. cert-manager writes the Secret `-tls` and renews it. The option is unavailable when cert-manager is not installed in the Kubernetes cluster. The issuer you choose has to: * Sign names under `svc.cluster.local`. A CA or Vault issuer can; an ACME issuer such as Let's Encrypt cannot. * Include its CA certificate in the Secret as `ca.crt`, so that every component trusts the others and the deployment page can show the CA to clients. ### Your own Secret Point the deployment at a Secret that holds a certificate, its private key and the CA that signed it. The default key names are `ca.crt`, `tls.crt` and `tls.key`; you can name others in the wizard. The certificate is used by every component, so it must: * Be signed by the CA in the Secret. * Allow both server and client authentication, because nodes also connect to each other. * Name the hostnames your clients connect to, if they verify them. Pod names follow `*.--headless..svc.cluster.local`. When you replace the certificate in the Secret, the deployment picks it up, usually within a few hours: one hourly check notices the change and a later one reloads it in the pods. See [Renewal](#renewal). ### Issued by KubeBlocks KubeBlocks generates a separate CA for each component, and its certificates only name the pods of that component. Components therefore cannot verify each other, so this option is only offered for standalone deployments and replication without Sentinel. It cannot be used with an external domain. ## Renewal Every hour, the Admin Server checks each deployment that uses TLS (except one issued by KubeBlocks) and takes it one step through the list below, so a change can take more than one check to reach the pods: FalkorDB Enterprise renews its certificate when it is about to expire, or when it no longer names every component. cert-manager is asked for any new names and renews on its own schedule. The certificate reaches every component of the deployment, as files in each pod. Every FalkorDB node loads the new files in place, without a restart: a `Custom` operation, listed on the **Operations** tab, runs `CONFIG SET` for the certificate, key and CA files on each node. Open connections, replication and the cluster bus carry on; new connections get the new certificate. It waits until the deployment is **Running**. Sentinel cannot reload its certificate, so a deployment with Sentinel then restarts its Sentinels (a `Restart` operation). The FalkorDB nodes keep running. If the reload fails, the Admin Server restarts the whole deployment instead (a rolling `Restart` operation), and if that fails too, a later check starts over. Each renewal, reload and restart is recorded in the audit log. A sharded deployment without persistent volumes is never restarted automatically: each shard would come back without its cluster state, and the shards could not form a cluster again. Its certificate is still reloaded in place; only when that fails does the audit log record that it has a new certificate to load. Restart it yourself once that is safe, or recreate it with persistence. KubeBlocks names the shards of a sharded deployment when it creates them. When FalkorDB Enterprise or cert-manager issues its certificates, their names are therefore added once the deployment is running, and the shards reload the certificate. A certificate you provide is used as it is. The reload runs through two OpsDefinitions the Admin Server creates and keeps current, `falkordb-enterprise-tls-reload` and `falkordb-enterprise-cluster-tls-reload`. KubeBlocks runs them in the FalkorDB containers with its own service account. The deployment page shows who issues the certificates and when the current one expires. ## Connect with TLS The deployment page shows the CA certificate under **Connection Details**. Save it to a file and give it to your client. For example, with `redis-cli`: ```bash theme={null} redis-cli --tls --cacert ca.crt -h -p 6379 -a ``` Clients connect to the same ports as without TLS: `6379` for FalkorDB nodes, and `26379` for Sentinel. Plain connections are refused. Nodes do not ask clients for a certificate. **Open in Browser** on the deployment page opens the FalkorDB Browser with TLS turned on. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.