Can you self-host Trigger.dev in 2026?

Self-Hosting Trigger.dev (as of May 2026)

Trigger.dev is an open-source background-job platform aimed at developers building AI and integration workflows. The project is licensed under Apache 2.0, and the maintainers publish official self-hosting instructions.

Components You Run

A self-hosted Trigger.dev deployment includes:

• Web app and API (Next.js)
• Postgres for jobs, runs, schedules, and account data
• Redis for the queue and transient state
• Worker process(es) that execute job runs
• A reverse proxy (Caddy or nginx) for TLS

For a small team, all of this fits comfortably on a single VPS (4 GB RAM is the practical minimum). For higher load, the workers scale horizontally.

Deployment Options

• Docker Compose for single-host deployments (the official quickstart).
• Kubernetes with the published Helm chart for HA deployments.
• PaaS deployments (Render, Railway, Fly.io) using the published images.

Cloud vs Self-Hosted Trade-offs

When to Self-Host

• The team has data-residency or compliance requirements that exclude SaaS.
• The job volume is large enough that Cloud pricing exceeds infrastructure cost.
• The team wants to extend the platform with custom integrations or changes.

When NOT to Self-Host

• For small teams without ops capacity, Trigger.dev Cloud is almost always cheaper than the human time required to run Postgres, Redis, and the worker layer reliably.
• For teams that need official SLAs.

Editor's Note: We have stood up self-hosted Trigger.dev twice — once on a single Hetzner VPS for a 6-person AI startup, once on a small Kubernetes cluster for a regulated client. The single-VPS setup ran reliably for months on about $24/month of infrastructure. The Kubernetes setup cost more in engineer-time than the SaaS plan would have, and we rolled back to Trigger.dev Cloud after the audit went through. Self-hosting is genuinely available, but only worth it for the right workload.

Caveats

Verify the current license and self-host instructions in the Trigger.dev documentation before standing up production infrastructure. The project has evolved its job runtime more than once (notably the v2 → v3 transition), and self-host instructions vary by version.