Deployment
Ship Ductor with Docker, Dokploy, or Helm/Kubernetes — and the production concerns that apply to all three.
Ductor is a single statically-linked Go binary that needs two backing services:
PostgreSQL (TimescaleDB recommended) and Redis or Dragonfly. Everything
else — the API, the routing engine, the workflow coordinator, the workers — runs
inside that one binary, selected by server.role. There is no separate scheduler,
broker, or executor image to operate; you scale by running more copies of the same
binary and, if you want, splitting roles across fleets.
Pick the path that matches your platform:
Docker & Compose
The container image, its ports and user, and the compose stack for local and
small deployments. Prefer make up / make up-full so you never run a stale
image.
Dokploy
Deploy the Traefik-fronted production compose stack on Dokploy — the setup pattern that runs api.ductor.io.
Kubernetes (Helm)
The deploy/helm/ductor chart — replicas, autoscaling, the migration hook,
secrets, and the fail-closed enterprise production gate.
Workflow release pinning
Bind public triggers to their live caller release and drain compatible worker sets safely through rollout and rollback.
Production concerns
Migrations, auth lockdown, the master key, egress enforcement, resource sizing, and scaling the coordinator/worker model.
The shape of a deployment
| Component | Purpose | Required |
|---|---|---|
| Ductor binary | API + routing + workflow runtime + workers | Yes |
| PostgreSQL | Durable state — runs, attempts, pools, rules, idempotency | Yes |
| Redis / Dragonfly | Cache, flow control, tiered queue, pub/sub | Yes |
| VictoriaMetrics stack | Metrics, logs, traces, alerting, Grafana | Optional |
Configuration is uniform
However you deploy, configuration follows one rule: a YAML key becomes an env var
by uppercasing and swapping dots for underscores (database.url →
DUCTOR_DATABASE_URL). See the
Configuration reference. In Kubernetes the Helm
chart also supports injecting a whole YAML document via the DUCTOR_CONFIG
Secret — the surface for enterprise-only settings that shouldn't live in
individual env vars.
Because the same binary runs everywhere, the difference between a laptop and a production cluster is entirely configuration: which backing services it points at, which security controls are enabled, and how many replicas run. The deployment paths above differ only in how they deliver that configuration.
Two Helm postures
The Helm chart ships one switch that draws the line between the two worlds:
| Posture | production | What it means |
|---|---|---|
| Development | false (default) | Chart-managed database/cache Secrets, development runtime profile, permissive defaults. For local and internal installs. |
| Enterprise | true | Fail-closed gate: rendering fails unless the environment is production, the security profile is enterprise, and every credential comes from pre-provisioned Kubernetes Secrets. |
Flipping production=true is not a tuning knob — it turns on a hard guard rail
that refuses to render a chart that isn't fully hardened. See
Kubernetes (Helm) for the exact requirements
and Production concerns for the config that backs
them.
After you ship
Getting Ductor running is day one. The day-two concerns — migrations you run on every upgrade, backups you rehearse, metrics and alerts you watch, key rotation you plan for — live in Operations:
Database migrations
Running ductor migrate up deliberately, and why auto-migrate stays off in
production.
Backup & restore
What to back up (Postgres is the source of truth), and rehearsing restores.
Observability
Metrics, logs, traces, and the alerts to wire before you need them.
Security & auth
Locking down authentication and the API host allowlist.