Preloop vs Trigger.dev: agent runtime vs agent control plane

Preloop is the open-source AI agent control plane: an MCP firewall, an AI model gateway with budgets, human approvals, runtime observability, and an audit trail in one self-hostable service. Trigger.dev is the open source platform for durable AI agents: a TypeScript SDK and platform for long-running tasks with retries, queues, AI observability, and elastic scaling.

The honest one-liner: Trigger.dev runs the agents you build; Preloop governs the agents you run, including the ones you bought. Trigger.dev is where your own TypeScript agent code executes and survives crashes and redeploys. Preloop sits between any agent and what it reaches (models, MCP tools, and native actions such as shell commands) and decides what is allowed, who approves it, and what it cost. Most teams that use both will find they barely overlap.

At a glance

What Trigger.dev does well

Trigger.dev is a strong, well-run open source project, and it would be odd to pretend otherwise:

• Durability. Its homepage example is a support agent whose run "survives refreshes, redeploys, and crashes", with a tool that pauses for human approval while "the run stays alive" (trigger.dev). Long-running agents without timeouts are hard to build yourself.
• Developer experience. Tasks live in your codebase, the SDK is TypeScript-first, and setup starts with a CLI or a prompt you paste into your coding agent (trigger.dev).
• Operational primitives. Queues and concurrency limits, cron schedules, retries, idempotency, realtime streaming to the frontend, and preview branches, all listed in the docs index.
• Scale and momentum. The company announced a $16M Series A in December 2025 and says it runs "hundreds of millions of agents each month" for "over 30,000 developers". The GitHub repository has more than 16,000 stars.

If your job is "ship a durable TypeScript agent or background workflow without building queue and retry infrastructure," Trigger.dev is a very good answer.

Where Preloop fits

Preloop is not a task runtime and does not try to be one. It answers a different set of questions:

• Governing agents you did not write. Most agent activity in a company is not custom code. It is Claude Code, Codex CLI, Cursor, Copilot, and similar tools on developer machines. preloop agents discover finds local agent configurations (read-only), and preloop agents onboard routes supported agents through the gateway and the MCP firewall, with a dry-run preview and config backups. Trigger.dev cannot see those agents because they do not run on it.
• Approval as policy, not as code. In Trigger.dev, a developer marks a tool with needsApproval and builds the review step. In Preloop, a security or platform owner writes a rule (for example, require approval when a deploy tool targets production) and the reviewer gets the tool, arguments, and agent reasoning on their phone, watch, or Slack. The rule applies to every governed agent with no code change.
• Native actions. With --approvals, Preloop installs native action gates for Claude Code, Codex CLI, Cursor, Copilot CLI, OpenCode, and others, so a shell command or file edit can wait for the same approval as an MCP call.
• Cost in tokens and dollars. The gateway attributes token spend to agent, session, model, flow, and key, with budgets. Trigger.dev bills compute; model spend inside your tasks is between you and the provider.
• Evidence. Every governed action is recorded with the matched policy, the approver, and timestamps, and audit rows are sealed into a per-account hash chain with signed checkpoints. That is material you can hand to a security review. It is evidence that can be used for compliance work, not a compliance certification.

When to choose Trigger.dev

• You are building your own agent or AI workflow in TypeScript and need durable execution, retries, queues, and streaming.
• Your approval needs are a few well-known tools inside your own code, and the developer who owns the code should own the approval step.
• You want a managed runtime with usage-based compute pricing, or a self-hosted runtime you operate.

When to choose Preloop

• Your agents are mostly ones you run rather than ones you build: coding agents on laptops, MCP clients, vendor agents.
• A platform or security team needs one policy and approval layer across vendors, not one per codebase.
• You need model spend per agent and session, budgets that stop runaway cost, and an audit trail of who approved what.

How they combine

They sit at different layers, so the natural setup is both. Two integration points need no product changes. This is a documented pattern, not a certified integration.

1. Route a task's model calls through the Preloop gateway. Most model SDKs read a base URL from an environment variable. Point it at your Preloop gateway ({PRELOOP_URL}/openai/v1 for OpenAI-format clients, {PRELOOP_URL}/anthropic for Anthropic-format clients) with a Preloop API key in the task's environment. The task's model traffic then gets budgets, allowed-model lists, attribution, and a session timeline in Preloop, while Trigger.dev keeps running the task.
2. Satisfy an approval wait with a Preloop decision. Trigger.dev waitpoint tokens can be completed "by making a POST request to the token's URL". Preloop can POST signed outbound events, including "an approval was raised or decided", to a URL you own. A small relay that verifies the Preloop signature and completes the token lets a reviewer approve on a phone or in Slack, with the decision recorded in Preloop's audit trail, while the Trigger.dev run waits.
3. Keep tool calls governed. If the task calls MCP tools, point it at Preloop's MCP endpoint. The firewall applies the same rules it applies to every other agent, and async approval mode returns a request id instead of holding the connection open, which suits a durable run.

FAQ

Is Preloop a Trigger.dev alternative? No. Trigger.dev executes your code; Preloop does not run your TypeScript tasks. Preloop's flows can run governed agents on events, but if you need a durable job runtime for your application, use Trigger.dev or a similar runtime and govern the agent traffic with Preloop.

Does Trigger.dev have human-in-the-loop approvals? Yes, as a developer primitive: needsApproval on a tool and waitpoint tokens that pause a run until completed. Preloop's approvals are policy-driven and apply across agents, with mobile, watch, Slack, Mattermost, email, and webhook delivery.

Are both open source? Yes. Both are Apache 2.0 and self-hostable.

Try Preloop

• Start your free trial
• Book a demo
• Preloop on GitHub

Last reviewed: 2026-10-08.