Before installing the RavenDB Kubernetes Operator, ensure your environment meets the following requirements:
- A running 1.19 or higher Kubernetes cluster (such as: EKS, AKS, Kubeadm-based-clusters, Kind, Minikube (1.25 or higher))
- kubectl
- Helm
- cert-manager - The RavenDB Operator uses admission webhooks, which require TLS certificates.
- RavenDB License
- RavenDB Let's Encrypt Setup Package/Self Signed Certificates Materials
There are three supported installation methods:
- Helm (recommended) - install via the two official charts published on ArtifactHub.
make deploy- local development / testing from source.- OLM bundle - for clusters running Operator Lifecycle Manager.
The operator runs in a dedicated namespace (e.g. ravendb-operator-system); each RavenDBCluster and its Secrets live in their own workload namespace. The operator creates namespace-scoped ServiceAccount, Role, and RoleBinding resources per cluster namespace, scoped to only the operations the operator needs.
The Helm distribution is split into two charts, each owning a clearly-bounded lifecycle:
| Chart | Scope | Installed | Contains |
|---|---|---|---|
ravendb-operator |
Cluster-wide | Once per Kubernetes cluster | Controller Deployment, RavenDBCluster CRD, RBAC, admission webhooks, cert-manager Certificate/Issuer |
ravendb-cluster |
Per-namespace | Once per RavenDB cluster you want to run | A RavenDBCluster CR, its license/cert Secrets (provisioned or referenced), and Traefik IngressRouteTCPs when applicable |
Install in that order: the operator first, then one cluster chart per RavenDB cluster.
helm repo add ravendb-operator https://ravendb.github.io/ravendb-operator/helm
helm repo update
helm install ravendb-operator ravendb-operator/ravendb-operator \
-n ravendb-operator-system --create-namespaceThis installs the controller, CRDs, RBAC, and webhooks. The operator chart does not create cluster-side Secrets or RavenDBCluster resources. See helm/chart/README.md for full documentation, including the migration guide for users upgrading from operator chart 1.x to 2.0.0 (the legacy provisioning.* flow has been removed).
helm install my-cluster ravendb-operator/ravendb-cluster \
-n ravendb --create-namespace \
-f my-values.yaml \
--set-file secrets.license.file=/path/to/license.json \
--set-file secrets.clientCert.file=/path/to/admin-client-cert.pfx \
--set-file secrets.nodeCerts.files.a=/path/to/node-a/server.pfx \
--set-file secrets.nodeCerts.files.b=/path/to/node-b/server.pfx \
--set-file secrets.nodeCerts.files.c=/path/to/node-c/server.pfxmy-values.yaml mirrors RavenDBClusterSpec 1:1 (nodes, mode, domain, external access, storage, …). The chart provisions Secrets from --set-file arguments, or references pre-existing Secrets you create with kubectl if you'd rather manage them yourself (cert-manager, Vault, sealed-secrets, etc.).
For full options - provisioning vs BYO Secrets, Traefik routing, supported networking modes, upgrade and uninstall semantics, limitations - see helm/cluster-chart/README.md.
This installation method is intended only for local development, contributing to the operator, or testing changes before building a production image.
It uses the manifests generated by Kubebuilder under the config/ directory and deploys the operator directly from your local source tree.
git clone https://github.com/ravendb/ravendb-operator.git
cd ravendb-operator
# Option A: If you're modifying code or testing custom logic, build the operator binary.
# This compiles the controller and ensures your local environment is correct before deploying.
make build
#Option B: If you want to test the operator inside your own cluster (kind, minikube, or remote):
make docker-build IMG=<your-registry>/<repo>:<tag>
make docker-push IMG=<your-registry>/<repo>:<tag> # or load it inside your cluster
# Uninstall (clean up)
make undeploy# Install Operator Lifecycle Manager (OLM), a tool to help manage the Operators running on your cluster.
$ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.38.0/install.sh | bash -s v0.38.0
# Install the operator by running the following command
$ kubectl create -f https://operatorhub.io/install/ravendb-operator.yaml
# After install, watch the operator come up using next command
$ kubectl get csv -n operatorsThe RavenDBCluster custom resource is the single source of truth for your RavenDB deployment.
It defines node topology, TLS mode (Let's Encrypt or self-signed), external access strategy (Ingress / LoadBalancer), storage layout, images, and bootstrap behavior.
Once the operator reconciles this resource, it will create and manage all underlying Kubernetes objects (StatefulSets, Services, Ingresses, Jobs, PVCs, etc.) needed to run the cluster.
Note: Feel free to shape the CRD however you need - the validation webhooks have your back, watching for misconfigurations and letting you know right away if something doesn’t look right.
For a deeper dive into each aspect of the spec, see the dedicated examples and documentation:
- TLS modes (Let's Encrypt / Self-Signed) examples/tls/README.md
- External access options
- AWS NLB: examples/networking/external_access/aws-nlb/README.md
- Azure LB: examples/networking/external_access/azure-lb/README.md
- HAProxy: examples/networking/external_access/haproxy/README.md
- Traefik: examples/networking/external_access/traefik/README.md
- NGINX: examples/networking/external_access/nginx/README.md
- Storage options examples/storage/README.md
- Cluster bootstrapping examples/cluster/README.md
Below is an example of a Let's Encrypt–based cluster using the AWS-NLB external access mode and Perssist/Restoring Data.
apiVersion: ravendb.ravendb.io/v1
kind: RavenDBCluster
metadata:
labels:
app.kubernetes.io/name: ravendb-operator
name: ravendbcluster-sample
namespace: ravendb-dev
spec:
nodes:
- tag: a
publicServerUrl: https://a.domain.development.run:443
publicServerUrlTcp: tcp://a-tcp.domain.development.run:443
certSecretRef: ravendb-certs-a
- tag: b
publicServerUrl: https://b.domain.development.run:443
publicServerUrlTcp: tcp://b-tcp.domain.development.run:443
certSecretRef: ravendb-certs-b
- tag: c
publicServerUrl: https://c.domain.development.run:443
publicServerUrlTcp: tcp://c-tcp.domain.development.run:443
certSecretRef: ravendb-certs-c
image: ravendb/ravendb:latest
imagePullPolicy: IfNotPresent
mode: LetsEncrypt
email: user@ravendb.net
licenseSecretRef: ravendb-license
clientCertSecretRef: ravendb-client-cert
domain: domain.development.run
env:
RAVEN_Features_Availability: "Experimental"
externalAccessConfiguration:
type: aws-nlb
awsExternalAccessContext:
nodeMappings:
- tag: a
eipAllocationId: eipalloc-0f12ab34cd56ef789
subnetId: subnet-0aa1bb22cc33dd44e
availabilityZone: us-east-1a
- tag: b
eipAllocationId: eipalloc-0123abcd4567ef890
subnetId: subnet-0555aa66bb77cc88d
availabilityZone: us-east-1b
- tag: c
eipAllocationId: eipalloc-0abc1234def567890
subnetId: subnet-0999ee11ff22gg33h
availabilityZone: us-east-1c
storage:
data:
size: 10Gi
storageClassName: gp3
accessModes:
- ReadWriteOnce
logs:
ravendb:
size: 1Gi
storageClassName: gp2
accessModes:
- ReadWriteOnce
audit:
size: 1Gi
storageClassName: gp2
additionalVolumes:
- name: scripts
mountPath: /tmp/scripts
volumeSource:
configMap:
name: myscripts
- name: restore-volume
mountPath: /tmp/restore
volumeSource:
persistentVolumeClaim:
claimName: restore-backup-pvc - Let's Encrypt mode using RavenDB’s built-in LE support
- Self-signed / bring-your-own certificate mode
- Works with:
- Per-node certificates from a RavenDB Setup Package.
- A single shared server certificate in self-signed scenarios.
- Manages webhook serving certificates through cert-manager.
- Handles certificate provisioning for nodes and clients.
- Automatically rotated secrets upon server-certificate renewal
- Runs a short-lived Kubernetes
Jobto:- Wait for all RavenDB pods to be running.
- Validate HTTPS reachability on all nodes.
- Register the ClusterAdmin client certificate on the leader node.
- Form the cluster (leader + members/watchers) based on
spec.nodes.
- Declarative definition of node topology, URLs, and certificate references.
- Supports multiple exposure mechanisms:
- AWS Network Load Balancer (one NLB per node, with explicit
tag→ EIP/subnet/AZ mapping). - Azure Load Balancer (per-node public IPs via AKS-managed SLB frontends).
- NGINX Ingress.
- HAProxy Ingress.
- Traefik Ingress.
- AWS Network Load Balancer (one NLB per node, with explicit
- Declarative configuration of data, log, and audit volumes.
- Supports Kubernetes storage backends including:
- local-path
- AWS EBS / EBS-CSI
- Azure Disk / Azure Disk CSI
- Additional volumes (ConfigMap, Secret, PVC, emptyDir)
- Ability to set environment variables on RavenDB pods via
spec.env(for feature flags and advanced configuration).
- Orchestrates rolling upgrades of RavenDB nodes.
- Ensures availability and ordering requirements during updates.
- Performs node-by-node upgrades in the order defined in the
RavenDBClusterspec. - Stops the upgrade on failed gates, keeps the state visible in status and Events, and automatically resumes from the same node once the underlying issue is fixed.
- Prevents accidental version downgrades.
- Exposes a single lifecycle field,
.status.phase(Deploying,Running,Error), plus a short.status.messageexplaining the current state. - Maintains detailed
.status.conditions[]forReady,Progressing,Degraded, and required health gates such asCertificatesReady,LicensesValid,StorageReady,NodesHealthy,BootstrapCompleted, andExternalAccessReady. - Derives
phasedeterministically from these conditions and emits Kubernetes Events on every condition transition, sokubectl describe ravendbclusters <name>shows exactly what is blocking readiness and why.
- Local deployment via
make deploywithout requiring Helm or OLM. - Validating and mutating admission webhooks for CRD correctness.
- Server-side apply for consistent updates and ownership.
- Supports incremental and partial reconciliations based on resource changes.
