Skip to main content

Prerequisites

  • Azure CLI (az) 2.60 or later, logged in with az login.
  • An Azure subscription where you can create resource groups, networks, and AKS clusters.
  • kubectl, helm, and base64 on the machine that runs the installer.
  • Access to run kubectl commands in the cluster’s context (configured below with az aks get-credentials).
  • At least 3 worker nodes with 4 CPU and 16 GB of memory each.
  • Outbound access from the cluster to pull images: registry.falkordb.cloud (Enterprise images, credentials required), docker.io, apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com, registry.k8s.io, and ghcr.io — or registry.falkordb.cloud alone, since every image is also mirrored there (see Private registries).
Select the subscription to use:
Register the required resource providers once per subscription:

Required infrastructure

A production AKS install needs: Set common variables used by the commands below:

1. Create the resource group

2. Create the virtual network and subnet

3. Create the AKS cluster

Create a cluster with a small system node pool. Database workloads run on a separate user node pool created in the next step. VM size availability varies by subscription and region. Verify a size is allowed before creating the cluster, and substitute an available equivalent if needed (for example Standard_D4s_v4, Standard_D4as_v5, or Standard_D4s_v6 in place of each other):
If your region and subscription support availability zones, add --zones 1 2 3 to spread nodes across zones. Check support first; if the command fails with AvailabilityZoneNotSupported, omit the flag:
Notes:
  • --tier standard enables the uptime SLA for production control planes.
  • If cluster creation fails with The VM size ... is not allowed in your subscription, pick a size from the list in the error message or request a quota increase; see AKS quotas, SKUs, and regions.
  • The Azure Disk CSI driver and snapshot controller CRDs are enabled by default on current AKS versions.

4. Create a user node pool for databases

Size this pool for your FalkorDB memory footprint. Memory-optimized E-series VMs are a good fit for graph workloads.
Add --zones 1 2 3 if your region and subscription support availability zones. Adjust --max-count accordingly.

5. Get cluster credentials

6. Verify storage and snapshot support

FalkorDB Enterprise uses persistent volumes for databases and the Admin Server, and volume snapshots for backups. Verify AKS defaults:
AKS ships the managed-csi and managed-csi-premium storage classes. Use managed-csi-premium (Premium SSD) for database volumes in production. The installer deploys its own Snapshot Controller release into the KubeBlocks namespace. If your AKS cluster already runs a snapshot controller (the volumesnapshots CRD exists and a controller is active in kube-system), skip the bundled one during install with --skip-snapshot-controller.

Install FalkorDB Enterprise

Quick install

With the AKS context active, run the installer:
On a default AKS install, the installer deploys ingress-nginx (unless the cluster already has a default IngressClass), exposes the Admin UI and Admin Server API on a single public IP through the gateway Ingress, and prints the URL. See Quickstart for what the installer does and how to validate it.

Production install

For production, prepare a values file with TLS ingress, a stable JWT secret, and a bootstrap admin user as described in Production install. A ready-to-edit AKS example is available at helm/falkordb-enterprise/examples/values-aks.yaml. Example AKS-specific values:
If you use the AKS application routing add-on as the ingress class above, enable it first:
Alternatively, install ingress-nginx and set className: nginx. Then install:

DNS

Point your Admin UI hostname at the ingress public IP:
Create an A record for admin.example.com pointing at the ADDRESS shown, either in your DNS provider or in Azure DNS:

Validate the install

Open the Admin UI URL and sign in with the bootstrap admin user. For OAuth sign-in, see Azure AD OAuth setup.

Clean up

Delete the Enterprise release first (see uninstall), then remove the Azure resources:
Deleting the resource group removes the cluster, network, disks, and load balancers it contains.