Skip to main content
Confirm each item below before running the installer. The installer performs a permission preflight check and prints an install plan, but it cannot provision capacity, install a production ingress controller, or open network egress for you.

​
FalkorDB Enterprise Portal access

Registry credentials and licenses come from the FalkorDB Enterprise Portal. Request access from your FalkorDB account manager before you start.
You can sign in to the portal at https://portal.enterprise.falkordb.cloud.
Your organization has quota assigned, so you can register a cluster.
Your portal role is developer or org-admin, so you can see the registry access token.
See Enterprise Portal for how to register a cluster and get its install command.

​
Cluster capacity

At least 3 worker nodes.
4 CPU and 16 GB of memory per worker node.
A default StorageClass, ideally CSI-backed so volume snapshot backups work.
Kubernetes 1.27 or later is recommended. On OpenShift, use OCP 4.14 or later. Only one FalkorDB Enterprise installation is supported per Kubernetes cluster.

​
Ingress controller

A default install publishes nothing outside the cluster: you reach the Admin UI with kubectl port-forward, so an evaluation needs no ingress controller. For a permanent address, the Admin UI and the Admin Server API are published through a single Kubernetes Ingress object, the chart’s gateway Ingress. It routes /api to the Admin Server and everything else to the Admin UI on one hostname. An Ingress object does nothing on its own: the cluster needs an ingress controller that serves its IngressClass.
For a production install, an ingress controller is installed and serving an IngressClass.
The controller is exposed outside the cluster, usually through a LoadBalancer Service.
Check which classes are available, and which one is the default:
The class marked (default) is used when gateway.ingress.className is empty. Set gateway.ingress.className explicitly when the cluster has no default class or has more than one controller.
The installer creates the Ingress, and installs a controller, only when you pass --quick-access on a first install with no custom values. It then uses the cluster’s default IngressClass, an IngressClass named nginx, or the only IngressClass, and otherwise installs ingress-nginx into the ingress-nginx namespace and marks it as the default class. Quick access serves the Admin UI over plain HTTP, so use it for evaluation only. --no-ingress is quick access through two LoadBalancer Services instead of the Ingress. For production, install and manage the controller yourself so its upgrades are not tied to the FalkorDB Enterprise installer.
When you enable the network policy, it admits ingress traffic to the Admin Server and Admin UI only from the controller’s namespace, ingress-nginx by default. Set networkPolicy.ingressControllerNamespace if your controller runs elsewhere.
If clients reach the Admin Server and Admin UI through LoadBalancer Services rather than through a controller, and you also enable the network policy, that traffic is dropped. --no-ingress sets this up only on a first install with no custom values or access overrides. With your own values file, set adminServer.service.type, adminUi.service.type, and gateway.ingress.enabled yourself. Add rules for those clients under networkPolicy.adminServer.extraIngress and networkPolicy.adminUi.extraIngress, or leave the policy disabled.

​
Local tooling

The machine that runs the installer needs: To mirror images into your own registry you also need skopeo and openssl. See Private registries. Verify the active context before installing:

​
Kubernetes permissions

Your Kubernetes user must be able to create:
  • Namespaces
  • CRDs
  • RBAC resources (ClusterRoles and bindings)
  • KubeBlocks resources
  • Namespace-scoped workloads, Services, Ingresses, Secrets, and PVCs
The installer verifies these permissions before it changes the cluster. Pass --skip-auth-check to bypass the check when your platform restricts SelfSubjectAccessReview.

​
Network access

​
Image registry

The chart pulls every image it templates from registry.falkordb.cloud. That covers the Admin Server, Admin UI, FalkorDB Browser, the FalkorDB database image, the KubeBlocks operator, and the hook jobs. The FalkorDB images are published there directly, and third-party images are mirrored there under their upstream path.
The same username and access token authenticate the chart pull and every image pull, because they share the registry host. Copy them from the cluster’s install guide in the Enterprise Portal.

​
Installer downloads

The installer script installs KubeBlocks and the snapshot controller as their own Helm releases from their upstream chart repositories, and applies their CRDs from GitHub. Those releases pull images from their upstream registries rather than from registry.falkordb.cloud. The machine running the installer and the cluster need outbound access to:
A cluster that can reach only registry.falkordb.cloud can still install the full stack. Install with helm directly instead of the installer, or mirror everything into your own registry. See Private registries.

​
Optional components

These subcharts are disabled by default. When you enable one, it pulls from its upstream registry unless you retarget it with examples/mirror-registry-values.yaml.

​
Values to prepare

Production installs go faster if you collect these first:
  • Kubernetes context name
  • The Kubernetes cluster ID, from kubectl get ns kube-system -o jsonpath='{.metadata.uid}'
  • FalkorDB Enterprise namespace and KubeBlocks namespace
  • Public Admin UI hostname, with DNS pointing at the ingress controller
  • The IngressClass to use
  • TLS certificate or cert-manager issuer for that hostname
  • Optionally, a cert-manager issuer that can sign in-cluster names, if deployments should get their TLS certificates from your own PKI. See TLS.
  • A stable JWT secret of at least 32 characters — generate one with openssl rand -hex 32
  • Registry username and access token for registry.falkordb.cloud, from the Enterprise Portal
  • A signed FalkorDB Enterprise license, issued when you register the cluster in the Enterprise Portal
  • Storage class for Admin Server persistence, if the cluster default is not suitable
  • The CSI driver name backing that storage class, for volume snapshot backups

​
Next step

Enterprise Portal

Register the cluster and get its license and install command.

Quickstart

Install the default stack and sign in to the Admin UI.