Self-host overview
Run the Dibbla platform on your own Kubernetes cluster.
The Dibbla platform is distributed as a Helm chart that installs onto any conformant Kubernetes cluster. After installation, your users get the same dibbla deploy workflow they’d use against the hosted service, but pointed at your cluster.
The Self-hosting guide walks you through cluster
choice, auth mode, and data plane decisions interactively, then generates a
tailored values.yaml. The reference pages in this section are the
authoritative per-component docs the guide links into.
What you’re installing
Six platform services plus a turnkey data + observability stack:
- API Gateway — HTTP entry point. Routes traffic to the platform services and to deployed apps.
- Auth Service — OAuth (Google + Microsoft Entra) and JWT-based authentication, organization and user management.
- Deploy API — deployment lifecycle: receives uploaded archives, builds images, manages app workloads, manages app DNS routing.
- Workflow Server — orchestrates workflows, persists state, and manages OAuth tokens for tools.
- Go Toolserver — runs the workflow tools (Anthropic + OpenAI-backed) for
function-servercalls. - Feedback Service — captures user feedback and crash reports.
- PostgreSQL — bundled single-pod local subchart (
pgvector/pgvector:pg17). Holdsauth_db,agent_db,workflows,feedback_db. Bring your own (CloudNativePG, RDS, etc.) viaglobal.externalPostgresql. - Redis — sessions, caching, and workflow event broadcast. Bring your own via
global.externalRedis. - MinIO — object storage for workflow artifacts (S3-compatible). Bring your own via
global.externalMinio. - Loki + Grafana Alloy — log storage + DaemonSet log shipper, queried by the Deploy API for the live-logs UI. Bring your own Loki via
global.externalLoki. - BuildKit (optional) — container image builds.
- Container registry (optional) — stores built app images. Disable to use an external registry.
Cluster prerequisites
- Kubernetes 1.27+ — vanilla, k3s, microk8s, kubeadm, EKS, GKE, AKS, or any other CNCF-conformant distribution.
- Ingress controller — nginx-ingress or Traefik. Both are supported via
api-gateway.ingress.className. - StorageClass with dynamic PVC provisioning — required for the bundled PostgreSQL StatefulSet and the optional container registry.
- cert-manager — recommended for automatic TLS. The chart does not install it.
- Wildcard DNS for
*.<your-base-domain>— point a wildcard A record (or CNAME) at your ingress IP. Your DNS provider stays your responsibility; Dibbla doesn’t manage records for you. Deployed apps are routed by the in-cluster proxy based on the requestHostheader — the wildcard catches every subdomain. - GitHub PAT with
read:packages— platform images live in private GHCR (ghcr.io/dibbla-agents/*).
Resource footprint
For a small production install:
| Sizing | vCPU | Memory | Disk |
|---|---|---|---|
| Minimum | 4 | 12 GiB | 60 GiB |
| Recommended (3-node) | 6 | 24 GiB | 100 GiB |
Resource requests are not set by default, so plan headroom for BuildKit (which is I/O-heavy) and the Postgres StatefulSet.
Where to next
Service ports, dependencies, and how traffic flows through the platform.
The canonical install path with a minimum values.yaml.
Bring up a greenfield k3s cluster ready to receive helm install.
Same shape, on snap-based MicroK8s.