Workflow Laravel Package

Technical Evaluation

Architecture fit. durable-workflow/workflow is an embedded durable workflow runtime for Laravel, not a standalone orchestrator. That is a strong fit for Laravel monoliths or modular monoliths where workflow state, queue execution, and business code can remain in-process. Workflows and activities are declarative PHP classes, started through WorkflowStub, with persistence owned by the Laravel application. This maps well to long-running sagas, onboarding flows, approvals, financial transaction coordination, data pipelines, and AI-agent orchestration where all workers are PHP/Laravel. It is a poor fit if the roadmap requires polyglot workers or framework-neutral orchestration; that requires the standalone server plus the separate PHP SDK.

Integration feasibility. Initial integration is straightforward for a Laravel team: Composer package, service provider, migrations, Eloquent models, queue jobs, replay persistence, and optional dedicated storage connection. The dedicated DW_STORAGE_CONNECTION option is useful for isolating workflow tables, backup/retention policy, and tenant or workload isolation without changing the default database. TPM caution: the README’s primary install path is a curl | sh script, which is a supply-chain governance issue. Adoption should require pinned Composer artifacts, lockfile review, and release provenance verification. With 0 dependents and a moderate package score, this should be treated as a pilot candidate, not an assumed platform standard.

Technical risk. The largest risk is version and upgrade maturity. The release history includes many 2.0.0 alpha/RC artifacts, and changelog 2.0.0-alpha.179 explicitly states that upgrade-path migration runtime coverage remains outside the release claim until a versioned migration manifest and published-artifact conformance evidence exist. Release 2.5.12 also warns operators to back up the database and replace old application and worker processes before upgrading, and notes that unsupported stored policies stop migration. That is a material operational constraint. There is also the normal durable-execution risk: non-deterministic workflow code, side effects outside activities, non-idempotent activities, and unversioned workflow definition changes can cause replay divergence or duplicate business actions. The release metadata also shows a future-dated “last release” value, so TPM should reconcile GitHub tags, Packagist metadata, and changelog artifacts before pinning.

Key questions.

• Which exact PHP and Laravel versions are supported and tested in the target release line?
• What is the recommended production-stable version, and what is the support window for 1.x versus 2.x?
• Does the team need embedded Laravel only, or polyglot/remote workers that require the standalone server and durable-workflow/sdk?
• How are workflow definition versioning, replay compatibility, and in-flight workflow upgrades handled?
• Are activity idempotency, retries, timeouts, deadlines, signals, timers, child workflows, and compensation patterns documented and testable?
• What database and queue drivers are officially supported, and what concurrency/throughput limits are known?
• What conformance evidence exists for upgrade migrations, replay, and multi-database shards?
• Is Waterline required for operations, and what is its licensing/support posture?
• What is the security posture of the install script, package publishing, and release signing?
• Who owns workflow runtime operations internally if community support is the only support channel?

Integration Approach

Stack fit. Best fit is a Laravel application with a relational database and Laravel queues, especially with Horizon on Redis. The changelog references MySQL, PostgreSQL, MariaDB, and multiple Laravel upgrade checks, but the exact matrix must be verified against the pinned release. Use a dedicated workflow storage connection when possible, and consider a separate queue for workflow workers so workflow load does not starve transactional jobs. Keep business dashboards on app-owned milestone projections keyed by workflow_id and run_id; Waterline is an operator/runtime UI, not a business reporting layer.

Migration path. Avoid a big-bang migration of critical processes. Start with a bounded, non-critical workflow and use it to validate replay, retries, failure recovery, and operator runbooks. Pin an exact stable release, back up the database, and rehearse migrations on a production-like clone. If upgrading from an earlier major line, do not assume in-place migration safety until the upgrade-path migration evidence is accepted; otherwise use a staged cutover or a new workflow schema/application path. For existing homegrown saga state machines, migrate one process at a time behind feature flags and keep the old path available until the new workflow has demonstrated recovery under failure injection.

Compatibility. Validate PHP/Laravel support, database driver, queue driver, Horizon/Waterline compatibility, and namespace usage (Workflow\V2 in examples). Confirm behavior across deploy boundaries: an in-flight workflow must replay correctly after application code changes. Test multi-tenancy explicitly if required; the dedicated connection helps isolate workflow state, but per-tenant isolation may need a stronger database/schema strategy. Confirm retention, archival, and PII handling for workflow history before production use.

Sequencing.

1. Run a 1–2 week technical spike in staging with a pinned release and a low-risk workflow.
2. Complete governance review of package provenance, install method, license, and release metadata.
3. Provision dedicated workflow storage and, if appropriate, a dedicated queue/worker pool.
4. Implement one workflow with idempotent activities, explicit timeouts, and business milestone projections.
5. Exercise failure modes: worker kill, queue backlog, database interruption, duplicate delivery, deploy during an in-flight run, and replay after code change.
6. Run the package’s replay/conformance commanding where applicable and capture evidence.
7. Add Horizon/Waterline operations visibility plus application-level workflow metrics and alerts.
8. Roll out workflow-by-workflow with feature flags, then formalize upgrade and rollback runbooks.
9. Defer broad platform adoption until the pilot proves upgrade safety, operational support, and database scaling assumptions.

Operational Impact

Maintenance. The package owns Laravel service-provider integration, migrations, Eloquent models, queue jobs, and replay persistence. That reduces custom runtime code but increases coupling to package release cadence and schema changes. Upgrades may require database backups, worker replacement, and migration windows; 2.5.12 explicitly calls this out. TPM should budget recurring upgrade time, maintain a pinned-version policy, and track changelog entries for migration and deadline behavior. Workflow history growth also needs retention and archival planning.

Support. Documentation, changelog, releases, GitHub Discussions, and Discord are present, but support appears community/volunteer-driven with no stated commercial SLA. With 0 dependents, there is limited external production evidence to lean on. The team should assign an internal owner for workflow runtime operations and require a support escalation path before using it for revenue-critical or regulated processes. Waterline is a separate operational UI and should be evaluated as part of the support model.

Scaling. Queue workers can scale horizontally, but the relational workflow state store becomes the critical scaling surface: table growth, indexing, lock contention, retention, and backup/restore time. Use a dedicated connection, monitor history-table growth, and define partitioning/archival early. Keep activities reasonably small and idempotent; avoid long database transactions inside workflows. Use separate queues for workflow orchestration versus high-volume business jobs, and apply rate limits around external services. Business reporting should read projected milestones, not runtime tables or Waterline data.

Failure modes. Expected failure modes include worker crashes during activity execution, duplicate activity delivery, poison workflows, stuck waits/timers, queue backlog, database outage, replay divergence after deployment, migration failure on unsupported stored policies, and timeout/deadline regressions. The 2.5.12 notes indicate service-call deadlines are now retained through retries and duplicate requests, with late results unable to overwrite timed-out outcomes; that is a positive reliability signal but also shows how subtle deadline behavior can be. Mitigations should include idempotency keys, deterministic workflow code, versioned workflow definitions, dead-letter/repair procedures, replay tests before deploy, database backups, and alerts on stuck runs, failure rate, queue depth, and workflow-history growth.

Ramp-up. The team must learn durable-execution semantics, not just Laravel queues: determinism, activity boundaries, idempotency, replay-safe code, workflow versioning, and operator repair. TPM should fund training, a code-review checklist, failure-injection exercises, and on-call runbooks. A staged adoption model is appropriate: one pilot workflow, then a second workflow with human approval or compensation logic, then broader platform use only after upgrade and recovery evidence is acceptable.