- How do I install durable-workflow/workflow in a Laravel application?
- Install it with Composer using composer require durable-workflow/workflow, then register the service provider and publish the package config and migrations. Run the migrations against the dedicated storage connection the package uses, and start workflows through the WorkflowStub entry point. After that, workflows are dispatched to your existing queue workers with no external service to deploy.
- Do I need Temporal, Cadence, or an external orchestrator to use Durable Workflow?
- No. Durable Workflow is an embedded durable-execution engine, so there is no Temporal or Cadence cluster, no sidecar, and no external orchestrator to operate. Workflow state lives in a relational database you control, using a dedicated storage connection. Deployment stays limited to Composer, config, and migrations, and in-flight state remains queryable from your own application.
- Which Laravel versions does Durable Workflow support?
- The current non-alpha 2.5.x line is actively maintained, and its CI includes five Laravel upgrade checks plus MySQL, PostgreSQL, and MariaDB shards. Exact version constraints are declared in the package composer.json, so check that file or the installation documentation before a major Laravel upgrade. Running the package test suite on your target Laravel version is the safest confirmation.
- How do I set a timeout or deadline for an activity or service call?
- Deadline policies accept either a positive integer timeout_seconds or an explicit-offset RFC3339 deadline_at value with up to six fractional digits, and call views retain UTC microsecond acceptance and deadline timestamps. Configure the policy per call instead of hand-tuning a client timeout, because the original deadline is retained from admission through retries and duplicate requests. A late result cannot replace a timed-out outcome, which is exactly what you want for downstream APIs with an SLA. Keep deadline configuration in policy or config rather than inside workflow code.
- Why can't I write to the database, call HTTP, or use now() and random() inside a workflow?
- Workflow bodies must stay deterministic so they can be replayed and resumed reliably, so they should not perform DB writes, make HTTP calls, or use now() and random(). All side effects belong in activities, which the engine executes, retries, and records. The same discipline applies to time-sensitive logic: deadline evaluation belongs in a policy or config, not inline in the workflow.
- What happens to a running workflow if a queue worker crashes or dies?
- Durable execution persists workflow state, so a workflow resumes from where it left off after worker death instead of restarting from scratch. Activities are retried according to your retry configuration, and parallel branches continue independently. That is the payoff of the generator-based programming model: retries, resumption, and long-running persistence without a bespoke state machine.
- Can Durable Workflow run on my existing Laravel queue workers and Horizon setup?
- Yes. Workflows and activities are dispatched through Laravel's queue and event systems and run asynchronously on normal worker servers, so existing Horizon-style supervision carries over. You do not need separate worker binaries or a second queue backend. Just restart worker processes when you deploy a new package version.
- What should I check before upgrading to a release that changes how deadlines are stored?
- Back up the database first, then inventory the deadline policies already stored in your workflow tables before running the migration. The migration derives existing deadlines from the original acceptance time and policy, and it halts with the affected call ID when it hits an unsupported stored policy, so a partial migration would be a production incident. Rehearse the upgrade against a production-shaped copy rather than a dev seed, and replace old application and worker processes after deploying.
- Is there a stable, non-alpha release of durable-workflow/workflow?
- Yes. A versioned, non-alpha 2.5.x line exists and is current, and the earlier 2.0.0-alpha track should now be treated as historical. Recent releases ship structured notes covering behavioral changes, value formats, migration semantics, failure handling, and CI evidence. Pin to a specific 2.5.x release rather than an old alpha tag.
- How does Durable Workflow compare to plain Laravel queue jobs or Temporal for long-running processes?
- Compared with plain Laravel queue jobs, workflows keep state in a relational database instead of opaque job payloads, so in-flight process state is queryable and joinable against your application data. That matters for anything with a business-visible lifecycle such as onboarding, order fulfillment, KYC, payouts, or multi-step approvals. Compared with Temporal or Cadence, it avoids an external cluster and sidecars, but it is scoped to PHP and Laravel applications.