Skip to main content
Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, deployment process, and the URLs you expose the service on. You are responsible for provisioning resources, handling updates, and managing any security, scaling, or reliability challenges that arise.
We provide version-tagged releases for self-hosted deployments. It is highly advised to use specific version tags and keep them locked to your CLI version.

​
Should you self-host?

Trigger.dev Cloud is fully managed, scalable, and comes with dedicated support. For most users, it offers the best experience. However, if you have specific requirements around data residency, compliance, or infrastructure control, self-hosting may be the right choice. The self-hosted version is functionally equivalent to Cloud with some exceptions. Because we don’t manage self-hosted instances, we cannot guarantee how Trigger.dev will perform on your infrastructure. You assume all responsibility and risk for your deployment, including security, uptime, and data integrity.

​
Architecture

The self-hosted stack is a set of containers running on your own infrastructure, split into two independently scalable parts:
  • Webapp — the dashboard, API, and supporting services (Redis, Postgres, ClickHouse, object storage, container registry).
  • Worker — the supervisor and the runners that execute your tasks.
Both parts can run on the same machine for development and testing, or on separate machines to scale workers independently.

​
Feature comparison

While most limits are configurable when self-hosting, some platform features are only available on Trigger.dev Cloud:
FeatureCloudSelf-hostedNotes
Warm starts✅❌Faster startups for consecutive runs
Auto-scaling✅❌No manual worker node scaling needed
Checkpoints✅❌Non-blocking waits, less resource usage
Dedicated support✅❌Direct access to the support team
Community support✅✅Access to Discord community
ARM support✅✅ARM-based deployments

​
Limits

Most limits (configurable via environment variables) are configurable via environment variables on the webapp container. A few are hardcoded:
LimitConfigurableHardcoded value
Concurrency✅—
Rate limits✅—
Queued tasks✅—
Task payloads✅—
Batch payloads✅—
Task outputs✅—
Batch size✅—
Log size✅—
Machines✅—
OTel limits✅—
Log retention—Never deleted
I/O packet length❌128 KB
Alerts❌100M
Schedules❌100M
Team members❌100M
Preview branches❌100M

​
Machine overrides

Override machine preset definitions by setting MACHINE_PRESETS_OVERRIDE_PATH to a JSON file: 
{
  "defaultMachine": "small-1x",
  "machines": {
    "micro": { "cpu": 0.25, "memory": 0.25 },
    "small-1x": { "cpu": 0.5, "memory": 0.5 },
    "small-2x": { "cpu": 1, "memory": 1 }
  }
}
Partial overrides are supported — omit any fields you want to keep at their defaults.

​
Community support

Join the #self-hosting channel on our Discord server for community help and discussion.

​
Next steps

Docker Compose

Self-host Trigger.dev using Docker Compose on a single machine or across multiple machines.

Kubernetes

Deploy Trigger.dev to a Kubernetes cluster using the official Helm chart.

Build docs developers (and LLMs) love

Get started for freeTalk to us