Firebolt Core can be deployed to a Kubernetes cluster (version 1.19 or newer) using the provided Helm chart. This section provides a step-by-step guide to get a working deployment up and running.

​
Prerequisites

Before you begin, ensure that you have the following installed and configured:
  • A Kubernetes cluster (v1.19+)
  • kubectl command-line tool configured to access your cluster
  • helm (v3+) installed on your local machine
Additionally, you will need one of these configurations:
  1. Kubernetes nodes with a memlock limit of at least 8GB (you can check with cat /proc/self/limits | grep -F 'Max locked memory')
  2. possibility to run Core with the helper root container (memlockSetup=true in Helm values)
The memlock setup helper root container is enabled by default, if you are using configuration (1) the container will be idle and do nothing, you can disable it using memlockSetup=false so that there are no root containers in your deployments.

​
1: Create a Dedicated Namespace

To isolate Firebolt Core resources from other workloads in your cluster, create a dedicated Kubernetes namespace: 
kubectl create namespace firebolt-core
This will create a logical grouping for all resources related to Firebolt Core, making it easier to manage and clean up later.

​
2: Customize Helm Chart Values

The deployment is configured via Helm chart values. You can modify these by editing a values.yaml file or by setting them directly via the --set flag. For example, to deploy a 3-node cluster, ensure the nodesCount value is set to 3; the memory allocation and storage allocation should also be increased for any serious workload you are planning to run. It is advised to not use the default preview-rc value for the image.tag and instead pick a released pinned version from the GHCR repository. Refer to the Helm Chart README for the complete list of configurable parameters, including resource limits, storage options, and networking settings.

​
3: Install the Helm Chart

Once your values are configured, install the chart into the firebolt-core namespace: 
helm install helm/ core-demo --namespace firebolt-core
Instead of core-demo you can use any name you prefer, it will be used as a prefix for the generated Kubernetes resources; the --generate-name flag can also be specified and it will let Helm automatically generate a release name.

​
4: Verify the Deployment

After installation, verify that the Firebolt Core pods are up and running: 
kubectl get pods -n firebolt-core
You should see output similar to the following, depending on your nodesCount value: 
NAME                              READY   STATUS    RESTARTS   AGE
helm-1748880880-firebolt-core-0   0/1     Running   0          5m33s
helm-1748880880-firebolt-core-1   0/1     Running   0          5m33s
helm-1748880880-firebolt-core-2   0/1     Running   0          5m33s
If the pods are not in the Running state, check their logs and events for troubleshooting: 
kubectl describe pod <pod-name> -n firebolt-core
kubectl logs <pod-name> -n firebolt-core

​
5: Querying locally

You can interact with Firebolt Core locally by port-forwarding the HTTP interface port (default: 3473) from one of the pods to your local machine. This enables you to send SQL queries directly via curl without exposing the service externally. To do this, run: 
kubectl port-forward pod/helm-1748880880-firebolt-core-0 3473:3473 -n firebolt-core
Replace helm-1748880880-firebolt-core-0 with the name of one of the running Firebolt Core pods. Once forwarded, you can issue SQL queries using curl, for example: 
curl -s "http://localhost:3473" --data-binary "select 42";
This approach is particularly useful for local testing and debugging.

​
6. Operations

You might want to setup backups for the mounted storage volumes to prevent data loss, and monitor iops usage to avoid slowdowns and latencies.

​
Scaling up/down

⚠️ changing the number of nodes is currently supported for clusters which are only reading data, without performing any write. If you need to perform writes and change cluster size, it will also be necessary to erase the data volume.

​
Changing resources

You can run helm update to apply changes to your cluster after changing resources like memory or CPU allocation; pods will be recreated as necessary. Note that it is not possible to resize storage volumes this way.

​
Updating Firebolt Core version

After changing the image.tag value to a more recent pinned version you can run a helm update to roll out the change to your Firebolt Core cluster: 
helm update helm/ core-demo --namespace firebolt-core

​
Removing the deployment

You can use: 
helm uninstall core-demo --namespace firebolt-core
This will however leave behind the created PVCs which contain data/metadata; you can list them using: 
$ helm get pvc --namespace firebolt-core
NAME                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
firebolt-core-data-nr-core-demo-firebolt-core-0   Bound    pvc-e234440a-e389-4470-85cc-b0069c397148   1Gi        RWO            gp3            <unset>                 19s
firebolt-core-data-nr-core-demo-firebolt-core-1   Bound    pvc-f33d05ba-3788-44e9-be16-c5362b359221   1Gi        RWO            gp3            <unset>                 19s
Remove them using kubectl delete and make sure you are deleting only those whose name prefix matches your Helm deployment. NOTE: this is a non-reversible operation, you must not delete the PVCs if you need the data/metadata of your Core cluster.

​
Additional Resources