Skip to main content
A self-managed Firebolt engine can have a web UI for running queries from a browser. The UI is a single-page application served by nginx from the ghcr.io/firebolt-db/firebolt-core-ui Docker image. It listens on port 9100 and forwards the queries the browser submits to one engine node’s HTTP endpoint. Query execution stays on the engine, so the machine running the UI needs HTTP access to that endpoint and nothing else: no object-storage access and no connectivity to the other nodes. Run it in one of two ways:
  • As a sidecar container in each engine pod, on Kubernetes with the Helm chart or the Firebolt Operator. Off by default.
  • As a standalone container on any machine with Docker, pointed at an engine’s HTTP endpoint. This is the way to get the UI for an engine running from the standalone binaries.

​
Run as a Kubernetes sidecar

​
Helm chart

Set uiSidecar on the engine spec in your values file and upgrade the release:
The chart adds the UI container to each engine pod and publishes port 9100 (named web-ui) on the engine Service.

​
Firebolt Operator

Set uiSidecar: true on a FireboltEngine, or on a FireboltEngineClass to apply it to every engine that references the class:
The operator injects its built-in engine-web container into each engine pod. The sidecar points at the engine in the same pod over loopback (http://localhost:3473). An engine value overrides the class value, which overrides the default (false). See the uiSidecar field in the CRD reference.

​
Open the UI

The UI listens on port 9100 inside the engine pod. Forward that port from a pod to your workstation, then open http://localhost:9100:
With the Helm chart, port 9100 is also published on the engine Service, so you can forward the Service instead:

​
Run the Docker image directly

The standalone container works against any engine endpoint, wherever the engine runs. FIREBOLT_CORE_URL, the URL the UI forwards queries to, is the only required setting. On the machine that runs a firebolt node:
Then open http://localhost:9100. With --network=host the container shares the host’s network namespace, so localhost is the host itself and port 9100 is served without a port mapping. The flag behaves this way on Linux, which is what engine hosts run. The UI does not have to run next to the engine. Run it on any machine that can reach a node’s HTTP port, including your workstation:
Use a plain HTTP URL for FIREBOLT_CORE_URL. Point it at a firebolt node’s HTTP endpoint directly (http://<node>:3473), not at a subpath: the UI forwards each query as a POST /query, and a node accepts SQL over POST on any path. If you cannot expose the node directly and put a proxy in front, the proxy must satisfy what the UI sends, because it forwards requests unchanged:
  • Serve the engine at the path /query. The UI always posts to /query, so a proxy that exposes the engine under any other prefix never reaches it.
  • Accept plain HTTP without SNI or Host-based routing. The forwarded request keeps the browser’s Host header (the UI’s own origin), so an HTTPS proxy that routes by hostname does not match.
  • Enforce access by network, not by credentials. The UI cannot attach an auth header or client certificate, so restrict the proxy with network controls instead.

​
Configuration

​
Security

The UI adds no authentication on top of the engine’s HTTP endpoint, which has none. Anyone who can reach port 9100 can run queries with full access to the engine. Treat network reachability as the security boundary, exactly as for the engine endpoint itself: keep the port on loopback or a private network, and reach it from elsewhere through kubectl port-forward or an SSH tunnel.