Dibbla Docs Get started Guides Workflows Changelog
Open Console
Self-host

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.

New here? Start with the guided walkthrough

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-server calls.
  • Feedback Service — captures user feedback and crash reports.
  • PostgreSQL — bundled single-pod local subchart (pgvector/pgvector:pg17). Holds auth_db, agent_db, workflows, feedback_db. Bring your own (CloudNativePG, RDS, etc.) via global.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 request Host header — 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:

SizingvCPUMemoryDisk
Minimum412 GiB60 GiB
Recommended (3-node)624 GiB100 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