Why self-host Trigger.dev on a VPS
Trigger.dev replaces homemade queues (BullMQ, fragile crons, Lambdas that time out) with a unified platform: durable tasks, automatic retries, concurrency management and a real-time dashboard. The SaaS version bills by the number of executions and limits job duration, which quickly becomes constraining for ETL processing, mass email sending or slow API calls. Self-hosted on a VPS, you keep your workers on your side: your third-party API keys (OpenAI, Stripe, Resend) never pass through a third party, and your jobs can run for 10 minutes or several hours without being cut off. The stack relies on PostgreSQL, Redis and a Docker orchestrator, which makes it reproducible and easy to back up.
What you gain by self-hosting
- No limit on the duration or number of executions of your background tasks.
- Your secrets (API keys, tokens) stay in your infrastructure, never on a third-party SaaS.
- Predictable fixed cost: a single VPS instead of a bill that climbs with volume.
- Reduced latency if your workers run next to your database and your application.
- Full control over versions, environment variables and log retention.
- The ability to trigger jobs from your internal webhooks without exposing any external service.
Hardware and software requirements
Trigger.dev is a relatively resource-hungry stack because it combines the web application, workers, PostgreSQL and Redis. Plan for a VPS with at least 4 GB of RAM and 2 vCPU for light production use; aim for 8 GB of RAM and 4 vCPU if you run many concurrent jobs or heavy processing. Allow 40 GB of SSD disk for the database, the logs and the Docker images. On the software side: Docker Engine 24+ and the Docker Compose v2 plugin, a domain name (for example trigger.mydomain.com) pointing to the VPS IP, and port 443 open for HTTPS. A MAGIC_LINK_SECRET key and an ENCRYPTION_KEY (32 hexadecimal characters) are essential to encrypt the projects' environment variables.
Deploy Trigger.dev with Docker in 5 steps
Prepare the VPS and Docker
Connect over SSH, update the system then install Docker and Compose: curl -fsSL https://get.docker.com | sh. Create a dedicated user and a /opt/trigger folder to host the configuration. Check with docker compose version.
Fetch the official self-hosting stack
Clone the deployment repository: git clone https://github.com/triggerdotdev/trigger.dev. The docker/ folder contains the docker-compose.yml that groups the web app, the workers, PostgreSQL and Redis. Copy .env.example to .env.
Generate the secrets and configure the domain
Generate your keys with openssl rand -hex 16 for ENCRYPTION_KEY and MAGIC_LINK_SECRET. Set LOGIN_ORIGIN and APP_ORIGIN to https://trigger.mydomain.com. Define the PostgreSQL credentials and the internal Redis URL.
Launch the stack
Start the whole thing with docker compose up -d. Follow the initialization of the migrations via docker compose logs -f webapp. Once the app is accessible on the internal port (3030 by default), create your first admin account via the magic link displayed in the logs.
Expose via an HTTPS reverse proxy
Place Caddy or Traefik in front of the app to handle TLS automatically. With Caddy: a single line trigger.mydomain.com { reverse_proxy localhost:3030 } is enough to obtain a Let's Encrypt certificate and enable HTTPS. Then connect your local project with npx trigger.dev@latest login --api-url https://trigger.mydomain.com.
Isolate the workers from the web application on separate containers and limit their concurrency via the WORKER_CONCURRENCY variable. For very CPU-hungry jobs, add a second VPS dedicated to the workers pointing to the same PostgreSQL and Redis: you scale horizontally without touching the dashboard. Also consider a daily pg_dump cron to external storage, because all the logic of your tasks and their history live in PostgreSQL.
