A Compose stack to try it, a Helm chart to run it

One machine first

A script in the Compose folder generates the secrets on first run, builds console and agent, brings the stack up and configures the Keycloak realm. After that the platform answers on one address. No Kubernetes needed to find out whether the thing is any good.

gateway     nginx, the only door outward
console     the interface
agent       backend, permissions and tools
keycloak    sign-in, roles
trino       the query engine
nessie      versioned Iceberg catalog
minio       S3-compatible storage
postgres    platform state and vector index
ollama      local embedding model (CPU)

The local embedding model runs alongside and is unloaded when idle so it holds no memory. Semantic search therefore needs no cloud key. The AI assistant does need a backend of your choosing — no model key ships with the platform.

Exactly one door outward

Everything runs behind a reverse proxy, and it knows three routes: the console, the agent interface and Keycloak. Trino, the object store and the platform database are not reachable from outside — not disabled by configuration, simply never published.

What is unreachable needs no hardening. The shortest hardening is a missing route.

That has a consequence worth knowing: BI tools cannot attach to Trino directly. The route there goes through a dedicated read-only feed of the platform, not an open database port.

In production: a Helm chart

For Kubernetes there is a chart that rolls out the platform with its dependencies: three separate PostgreSQL instances for Nessie, Keycloak and platform state, MinIO for storage, Keycloak, Nessie, Trino, an nginx ingress as the single public door, and optionally cert-manager for certificates.

That Keycloak comes from codecentric's chart rather than Bitnami's is not taste: the Bitnami images moved behind a paywall and no longer keep pullable versioned tags. Decisions like that sit in the chart as comments — whoever operates the stack has to know where the images come from.

MinIO and PostgreSQL are dependencies with a switch. If your data center already runs S3-compatible storage and a managed database, point at those instead of operating two more.

What is still missing for enterprise operation

The security core is in place: delegated identity, policies in the engine, a WORM audit chain, an egress guard, encrypted secrets, process-isolated parsing. What sits between “runs as a single instance” and “enterprise-ready” is open — and you should know that before a decision, not after.

• High availability without single points of failureIn development
• Metrics, logs, traces, alerting and SLOsIn development
• Secrets through Vault or External SecretsIn development
• TLS between all servicesIn development
• Air-gapped operation with no outbound connectionsIn development
• Backup and disaster recoveryIn development

These are planned individually rather than as a lump labelled “hardening” — anyone who wants to know what it depends on gets a list, not a shrug.