Skip to main content
This page introduces the firebolt-instance Helm chart and the components it deploys on a Kubernetes cluster.

​
Architecture

        client ── HTTP ──▶  ┌────────────────────┐
                            │       Gateway      │
                            └─────────┬──────────┘
                                      │ routes by X-Firebolt-Engine
                                      ▼
                            ┌────────────────────┐      ┌────────────────┐
                            │      Engine        │ ───▶ │ Object Storage │
                            │  StatefulSet(s)    │      └────────────────┘
                            └─────────┬──────────┘
                                      ▼
                            ┌────────────────────┐
                            │  Metadata Service  │
                            └─────────┬──────────┘
                                      │
                                      ▼
                                  PostgreSQL
Each entry under engines: renders one 1-replica StatefulSet per node, plus a shared headless Service, ClusterIP Service, and ConfigMap.

​
When to use the chart

The chart has no controller loop. Its running state is whatever the standard Kubernetes controllers maintain after helm install. That is enough for many deployments, including production ones, where engine sets are stable and changes go through a normal release cycle. For day-2 operational capabilities such as zero-downtime engine rollouts, autoscaling, drift correction, and reusable per-engine templates, use the Firebolt Kubernetes Operator. The operator manages the same component set through CRDs and a reconciler. The two are complementary and built from the same engine and metadata image lineage.

​
Where to start

  • Prerequisites explains the cluster and tooling requirements.
  • Quickstart installs the chart on a local kind cluster and runs a query, end to end.
  • Object Storage configures the object storage every engine needs to start.
  • Single engine walks through a default install.
  • Monitoring describes the Prometheus metrics surface and the optional PodMonitor resources.
  • Security records the chart’s pod-hardening baseline and the responsibilities it leaves to the platform team.
For a value-by-value reference, see the helm-docs-generated helm/README.md.