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’s highly advised to use these tags exclusively and keep them locked with 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 for you.

The self-hosted version is functionally the same as Trigger.dev Cloud with some exceptions, but our managed Cloud infrastructure is designed for high availability, security, and scale.

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.

For more details, carry on reading and follow our guides for instructions on setting up a self-hosted Trigger.dev instance. If you prefer a managed experience, you can sign up for our Cloud offering instead - we have a generous free tier for you to try it out.

Feature comparison

While limits are generally configurable when self-hosting, some features are only available on Trigger.dev Cloud:

FeatureCloudSelf-hostedDescription
Warm startsFaster startups for consecutive runs
Auto-scalingNo need for manual worker node scaling
CheckpointsNon-blocking waits, less resource usage
Dedicated supportDirect access to our support team
Community supportAccess to our Discord community
ARM supportARM-based deployments

Limits

Most of the limits are configurable when self-hosting, with some hardcoded exceptions. You can configure them via environment variables on the webapp container.

LimitConfigurableHardcoded value
Concurrency
Rate limits
Queued tasks
Task payloads
Batch payloads
Task outputs
Batch size
Log size
Machines
Log retentionNever deleted
I/O packet length128KB
Alerts100M
Schedules100M
Team members100M
Preview branches100M

Machine overrides

You can override the machine type for a task by setting the MACHINE_PRESETS_OVERRIDE_PATH environment variable to a JSON file with the following structure.

{
  "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 }
    // ...etc
  }
}

All fields are optional. Partial overrides are supported:

{
  "defaultMachine": "small-2x",
  "machines": {
    "small-1x": { "memory": 2 }
  }
}

Community support

It’s dangerous to go alone! Join the self-hosting channel on our Discord server.