Long jobs that survive
crashes, deploys and restarts.

The workflow is one PHP method

On every resume the code re-runs from the start, but each step already recorded returns its recorded result instead of running again.

You declare no state machine and no transition table, because the process is the method. The environment is injected in the constructor, and activities are typed stubs, so your IDE and your static analyser already understand every call the workflow makes.

A worker can be redeployed mid-process and the execution continues where it stopped.

Run two steps at once, and keep both results

Calling an activity returns an awaitable. all() combines two of them into one, and the execution waits at await().

Bound a wait in time, without writing the race

The deadline is the second argument to await(). When the deadline elapses, you get a failure instead of an ambiguous null. To wait for the clock alone, call sleep().

Stop waiting once enough answers are in

Three quotes out of eight are enough to decide; the other five cost only their latency. Results come back indexed by declaration position, so every price still points at the provider that gave it.

Declare what a failure means, once

Retry limits, non-retryable exceptions and per-attempt timeouts are options on the activity stub. You no longer spread a counter, a dead-letter table and a runbook across your codebase.

Send input to a running process, and read its state

A signal delivers input to an execution already in flight; a query reads its state without disturbing it; an update is validated and answers back. Approval steps and manual holds need no separate infrastructure.

Undo what already happened when a process is cancelled

Cancellation arrives inside the workflow as a catchable failure, so the process can compensate, refunding the charge and releasing the stock, and then stop.

Messenger and cron can do all of this. You build it with status columns, locks and guards against double processing, and you watch over them. This comparison counts the code you write and keep.

Durable does not orchestrate Symfony AI’s inner loop; Agent::call() runs its own tool round-trips. Durable bounds each turn: one decision, its effects, an optional approval, then the next turn.

Checkout calls Billing and waits. The connection gives up at thirty seconds; the charge takes four minutes. So Checkout retries, and Billing charges twice. Both teams then write the same three things by hand, each on their own side: an idempotency key, a reconciliation job, and a status column that means maybe.

The caller waits without holding anything open, for four minutes or for six hours alike. A failure comes back typed, so you can write the compensation that matches it. Cancelling the caller cancels the work on the other side. And neither team ever sees the other's workflows.

$billing = $env->nexusStub(
    BillingContract::class,
    endpoint: 'payments',
);

$receipt = $env->await(
    $billing->charge($order, 1200),
);

#[AsNexusServiceHandler(
    contract: BillingServed::class,
)]
final class Billing implements BillingServed
{
    public function verify(Order $o): Verdict
    { /* … */ }
}

Symfony 6.4, 7 or 8. Autoconfiguration, Messenger transports, profiler panel.

The dashboard only reads runs, so any backend above works.

Durable is on its beta line. First run composer config minimum-stability beta and composer config prefer-stable true. Otherwise the install fails, because Composer's default minimum stability is stable.

Everything it depends on comes transitively, so the command names one package only.

No persistence between requests: this is the one option that does not go to production.