Self-Hosting Trigger.dev

Run Trigger.dev on your own infrastructure for full control over data residency, compliance, and deployment.

Consider Trigger.dev Cloud first

Trigger.dev Cloud is fully managed, scalable, and comes with dedicated support. Self-hosting is recommended only when you have specific compliance or infrastructure requirements.

Architecture

Self-hosted Trigger.dev consists of two independently scalable components:

• Webapp — dashboard, API, Redis, Postgres
• Worker — supervisor + runners that execute tasks

Cloud vs Self-hosted Feature Comparison

Feature	Cloud	Self-hosted
Warm starts	Yes	No
Auto-scaling	Yes	No
Checkpoints	Yes	No
Dedicated support	Yes	No
Community support	Yes	Yes
ARM support	Yes	Yes

Configurable Limits

Most limits are configurable via environment variables on the webapp container:

Limit	Configurable
Concurrency	Yes
Rate limits	Yes
Task payloads	Yes
Batch payloads	Yes
Task outputs	Yes
Batch size	Yes
Log size	Yes
Log retention	Never deleted
I/O packet length	No (128KB)

Machine Preset Overrides

Set 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 }
  }
}

Deployment Options

• Docker Compose — quickest way to get started
• Kubernetes — production-grade orchestration

Important Notes

• Use version-tagged releases — keep CLI version in sync with self-hosted version
• You are responsible for security, uptime, data integrity, and upgrades
• For help: join the #self-hosting channel on Discord