Workflow orchestration / Trigger.dev Durable Agents and Workflows alternative

A Trigger.dev alternative for the agent’s complete Linux system

Trigger.dev runs durable TypeScript tasks and AI agents, with real process checkpoint/restore during waits and no fixed platform run-duration ceiling. Waiting runs can release compute and later continue in the same process. Compare the deployment model, whole writable filesystem lifecycle and paused-file access required by your agent.

Start buildingCompare capabilities ↓

Reviewed 2026-10-19 · Published by the Sandbox0 team

When Trigger.dev Durable Agents and Workflows fits

Trigger.dev fits teams implementing durable task and agent logic in its SDK, with queues, retries, waits, realtime output and managed execution. Its memory checkpoint-resume and long-running conversation support are substantive capabilities.

When to consider Sandbox0

Consider Sandbox0 for compatible Linux agents that need a general-purpose durable computer across tasks, including installed system tools and configuration over the complete writable RootFS, enabled automatic growth and supported paused files.

Capabilities

Trigger.dev Durable Agents and Workflows and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeTrigger.dev Durable Agents and WorkflowsThe per-attempt maxDuration is configurable, and timeout.None disables it for a task or run. Supported waits do not consume that compute-time budget.View evidence ↗Sandbox0ttl and hard_ttl default to 0 (disabled). Configure idle pause and deletion policies for the same persistent sandbox identity; an idle running sandbox still accrues compute charges.Read documentation →
Persistent filesTrigger.dev Durable Agents and WorkflowsTask machine disk and checkpointed process state are documented, but a general independently retained writable guest disk across separate runs is not established.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSTrigger.dev Durable Agents and WorkflowsProcess checkpoints and built deployment images do not establish a general complete mutable OS persistence contract across tasks and deployments.View evidence ↗Sandbox0Persistence extends beyond /workspace to paths such as /usr/local, /etc, and /home. Runtime tmpfs and virtual filesystems are excluded.Read documentation →
Release compute, keep stateTrigger.dev Durable Agents and WorkflowsSupported waits checkpoint and later resume execution, with compute billing and concurrency release governed by distinct thresholds.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateTrigger.dev Durable Agents and WorkflowsCRIU checkpoints explicitly capture process memory, CPU registers and open file descriptors; idle agents can restore the same process.View evidence ↗Sandbox0Experimental memory checkpoints can preserve compatible process state. Use memory: true on both pause and resume on a compatible deployment. A filesystem checkpoint alone does not preserve running processes.Read documentation →

Online RootFS growth

On growth-enabled images, Sandbox0 automatically expands the writable RootFS as free space runs low, within a configured sparse logical ceiling up to 64 TiB. Agent processes keep running. Growth is enabled in the qualified Cloud region; confirm activation for other regions. Existing images and snapshots retain their captured storage geometry. The ceiling is logical capacity, not preallocated host disk.

The machine table lists 10 GB disk for the published presets. Selecting compute or installing build-time packages does not establish automatic online growth of a durable whole-agent RootFS. Do not confuse a task machine’s disk with the platform’s own backing database size.

Files while compute is paused

Sandbox0's Files API reads persistent files without resuming compute. Filesystem-only pauses also permit edits; retained-memory pauses are read-only and reject mutations with 409. SSH, SFTP, file watching, and runtime-only mounts require running compute.

Trigger.dev streams and application records can remain available while a task waits. The reviewed docs do not establish a direct whole-RootFS file API against that stopped task machine. Sandbox0 supports paused RootFS files with writes for filesystem-only generations and reads for retained-memory generations.

See paused file operations →

Checkpoint-resume preserves a waiting process

Trigger.dev describes CRIU checkpoints including memory, CPU registers and open file descriptors. The AI Agents SDK can suspend an idle conversation and restore the same JS process, including in-memory caches and promises. A crash or clean run exit has different continuation behavior and must not be confused with a successful idle checkpoint restore.

Source 1 ↗Source 2 ↗

Free wait compute and released concurrency have different thresholds

Waiting for subtasks checkpoints the parent and excludes its waiting time from compute usage. For timed waits, the current Wait guide says a wait longer than five seconds is not charged compute, while the checkpoint and concurrency-slot release occur at sixty seconds. A shorter timed wait can therefore be compute-free yet still occupy concurrency.

Source 1 ↗Source 2 ↗

A deployed task image and a persistent agent OS are distinct contracts

Trigger.dev can install system packages through build extensions and selects task machines with documented disk sizes. Those features and process checkpoints do not by themselves establish independently persistent arbitrary runtime changes across separate tasks, retries and deployments, or direct file operations on a stopped whole-root generation.

Source 1 ↗Source 2 ↗

Usage adds invocation and compute to the selected plan

Every run that starts on managed workers has an invocation charge in addition to active compute. Development runs are not charged. Hobby and Pro include usage credits equal to their monthly price; additional usage follows the compute/run meters, with plan-specific concurrency and feature limits.

Source 1 ↗

Configure maximum compute time independently

Trigger.dev requires a default maxDuration in task configuration. It limits compute time per attempt rather than elapsed time spent in supported waits. Tasks and individual runs can override it, including timeout.None to disable the limit. Long-running workflow support therefore still needs deliberate timeout, retry and cleanup policy.

Source 1 ↗

Pricing

Compare billing models, then price your workload

CPU allocation, memory, billing minimums, disk, plan fees, and supported workload differ. These meters are not equal-performance machine quotes. Confirm region, resource units, and included allowances before estimating a total.

Trigger.dev Durable Agents and Workflows

Pricing reviewed 2026-10-19

Small 1x active compute
$0.0000338 per second
0.5 vCPU and 0.5 GB RAM.
Rate source ↗
Medium 1x active compute
$0.0000850 per second
1 vCPU and 2 GB RAM.
Rate source ↗
Run invocation
$0.000025 per started managed run
Equivalent to $0.25 per 10,000 runs; active compute is additional.
Rate source ↗
Hobby
$10/month with $10 usage credits
Rate source ↗
Pro
$50/month with $50 usage credits
Additional concurrency, seats and other extensions have separate fees.
Rate source ↗

Free includes $5 monthly credits and limited concurrency; paid-plan usage beyond included credits continues billing at the applicable rates. Compute-free wait time does not automatically mean an immediately released concurrency slot. These are task-machine and invocation meters, not equal-performance quotes for a general Linux VM.

Check current Trigger.dev Durable Agents and Workflows pricing ↗

Sandbox0

$0.015/GiB-hour compute (billed by the second at approximately $0.000004167/GiB-second), plus $0.02/GiB-month of retained incremental RootFS and memory checkpoint data. Shared base images and platform recovery retention are excluded; paused sandboxes accrue storage charges only.

Compute / GiB-hour
$0.015
Retained data / GiB-month
$0.02
Paused compute
$0.00

A 4 GiB agent, 100 running hours

$6.00 compute

4 GiB × 100 hours, billed by the second. Keeping 20 GiB of billable incremental data for a full billing month adds $0.40. CPU is derived from memory by the platform; choose a tier that fits your workload.

Understand storage billing →

Before migrating from Trigger.dev Durable Agents and Workflows

  1. Inventory TypeScript tasks, agent waits, retry/idempotency behavior, queues, package build extensions and external data stores.
  2. Keep durable workflow services where useful and port compatible Linux agent execution with verified tools and state.
  3. Test idle memory continuation, retry behavior and workflow correctness separately from full-system retention, growth, paused files and combined invocation/compute costs.

Common questions

Is Sandbox0 a drop-in Trigger.dev Durable Agents and Workflows replacement?

Evaluate API compatibility and product scope. These products serve different core workflows, so a change may require a different architecture.

Does keeping files also keep a running agent?

Filesystem state and volatile process state are separate. Sandbox0 requires explicit compatible memory checkpoints to preserve running processes; its default filesystem resume starts fresh processes.

Sources and review scope

The Boat team's Battleships directory is the discovery source. References below describe the product and plan discussed on this page. Check current availability, regional terms and billing units before migrating. Where the cited material does not establish a capability or price, the comparison identifies that uncertainty.

Battleships research record ↗trigger.dev/docs/how-it-works.md ↗trigger.dev/docs/ai-chat/how-it-works.md ↗trigger.dev/docs/wait.md ↗trigger.dev/pricing ↗trigger.dev/docs/machines.md ↗trigger.dev/docs/config/extensions/aptGet.md ↗trigger.dev/docs/runs/max-duration ↗Sandbox0 RootFS capacity →

Related comparisons

Expanse Cluster Intelligence vs Sandbox0 →Google Agent Runtime vs Sandbox0 →Hatchet vs Sandbox0 →Hyrex vs Sandbox0 →Mastra vs Sandbox0 →Microsoft Foundry hosted agents vs Sandbox0 →