fletchThree images. Your cluster. One Helm release.
Fletch ships as plain containers that read their configuration from the environment. The same images run under the Helm chart on AKS, EKS, GKE or any Kubernetes, and under Docker Compose on a developer machine. Deploys are deliberate: only the service that changed is rolled, and the served bytes are verified against the merged source before a roll is recorded.
fletch-console
Node. The REST API, the single-page console, governance, the vault and Administration. The image also carries the Rust toolchain binaries, so validate, plan and run never leave the pod.
lib/ · public/ · server.js · fletch-irc · fletch-planc · fletch-oprunner
fletch-engine
Rust on DataFusion. Federated query execution with optional spill to disk. Reads the sources the console scopes for it.
engine/ · engine-mpp/
fletch-flight
Rust. An Arrow Flight SQL service that fans a query out through the console's governed source routes and streams the exact Arrow batches on, for engine-to-engine transfer.
flight/
A Helm chart that pins each service on its own.
The chart templates the console, engine and Flight deployments, the ingress and the secret pointer. CockroachDB and object storage are prerequisites you already run. Secrets live in an operator-managed Kubernetes secret, not in release values, so a release can be re-applied without re-supplying them.
- Per-service image tags, so a console-only change rolls the console only
- ingress-nginx and cert-manager for TLS; an IP allowlist on the ingress
- Entra ID OIDC wired for sign-in
The whole stack with one command.
Compose brings up CockroachDB, Azurite for Fletch-managed blob storage, an S3-compatible target, the engine, the console and Flight. Open the console, create the first administrator, and add a source.
- Every environment variable is documented in one configuration contract
- The master key, session secret and share token are the only values you must set
- The Python SDK and the OpenAPI specification ship in the same repository
A built tag is not a deployed tag.
An image in the registry proves a build happened and nothing else. The chain that holds, and the one we follow for every production roll: merged source, to the file hashes inside the image, to the image digest, to the digest the pod reports running, to the byte count the console actually serves.
Merged main
The tree that was built is compared to the merged commit right before the upgrade. Any difference means a rebuild.
Image digest
The registry's manifest digest for the tag, read from the registry, not from a build log line.
Running digest
The pod's reported image id must equal the pushed digest, and the old pod must be gone before anything is recorded.
Served bytes
The single-page console served over the ingress is byte-identical to the file in the image, with new markers present and removed ones absent.
Seven required checks before a change reaches main.
| Check | What it proves |
|---|---|
| Unit tests | The console's pure-JavaScript suite, drivers mocked, no network |
| Rust unit tests | Fletch IR, planner, operators, importer and scheduler crates, with the exact compiler pinned in the repository |
| Protocol and auth suites | Sign-in paths and the protocol surfaces, end to end |
| REST API suite | Authorisation, validation and idempotency of every documented route |
| Console Playwright | Every console area, both viewports, including the keyboard-only canvas path |
| Software composition analysis | Zero copyleft dependencies |
| Integration | Real sources and sinks in a live stack, plus query-builder oracles |
Branch protection is server-side. Direct pushes to main are refused, force-pushes are refused, and a merge blocked by a required check names the check in its refusal. A mistake on main is fixed forward, never by rewriting history.
Stand it up in your subscription.
We will walk your platform team through the chart, the secrets layout and the first roll.