SimpleQ vs Trigger.dev
Different tools for different needs. SimpleQ is transport — it delivers jobs to your webhook with a three-signal ack protocol, backpressure that never burns retries, and queue templates tuned for AI workloads. You run the code in your own infrastructure. Trigger.dev is task orchestration — it runs your code in a managed environment with integrations, scheduling, and durable execution.
| Feature | SimpleQ | Trigger.dev |
|---|---|---|
| Category | Managed queue (transport) | Task orchestration (managed execution) |
| Runs your code? | No — delivers to your webhook. You own the execution. | Yes — runs your tasks in managed infra |
| Delivery model | Push (webhook POST) | Push (executes your task code) |
| Durable execution | No | Yes — resumable, long-running tasks |
| Retries | Configurable per queue | Configurable per task |
| Rate limiting | Per-queue fixed-window, built-in | Concurrency control per task |
| Ack mode | Three-signal protocol: ack (success), nack (failure with retryable flag), defer (backpressure — redelivers without burning attempts) | N/A — execution is managed |
| Backpressure | 429/503/529 auto-defers with Retry-After relay. A job can ride out 100 consecutive 429s and still complete — no attempt burned. | Task-level retry with backoff (counts against retry budget) |
| Queue templates | template: "anthropic" or "openai" — one field configures ack mode, timeout, and backoff tuned for each provider's API | None |
| Idempotency | Publish-boundary dedup — returns existing job ID on duplicate | Idempotency key |
| Per-job audit trail | Full attempt history: status, error, HTTP code, timestamp per attempt | Per-task execution logs |
| Webhook signing | HMAC-SHA256 with per-queue secret | N/A (managed execution) |
| Integrations | None — HTTP endpoint agnostic, works with any framework | Built-in integrations (OpenAI, Resend, etc.) |
| Cron / scheduling | Not yet | Yes — scheduled triggers |
| Self-hostable | No | Yes (open-source) |
When to choose SimpleQ
- You want to run your code in your own infrastructure — not hand execution to a third-party runtime. Your workers are plain HTTP endpoints, deployable anywhere, in any framework, on any cloud.
- Your LLM calls return 429s and you need explicit backpressure control. SimpleQ's defer mechanism holds the job and redelivers after the Retry-After delay — no attempt burned. A job can ride out a sustained outage and still complete.
- Your workload is "queue a job, deliver it to my endpoint" — not multi-step orchestration. SimpleQ's publish-deliver-ack model is simpler than a task orchestration framework.
- You want one POST to configure a production-ready AI queue.
template: "anthropic"or"openai"sets ack mode, timeout, and backoff tuned for each provider's API. - You need per-job audit trails with full attempt history — status, error, HTTP code, timestamp per attempt.
- Different teams own different queues. SimpleQ's HMAC signing secrets are per-queue — a leaked secret affects one queue, not the org.
When to choose Trigger.dev
- You want managed execution — no webhook endpoint to deploy, scale, or keep alive. Trigger.dev runs your code for you.
- You need long-running, resumable tasks with checkpoint-based durability and scheduled triggers.
Can you use both?
Yes. Some teams use Trigger.dev for complex orchestration tasks that benefit from managed execution, and SimpleQ for high-throughput delivery where they want ownership of the worker, explicit backpressure signals, and per-queue rate limiting. SimpleQ handles the transport; Trigger.dev handles the orchestration. If your LLM call is a single job that needs reliable delivery with backpressure control, SimpleQ is the simpler path — especially with template: "anthropic" or "openai".