Workflow Laravel Package

Product Decisions This Supports

• Build vs. buy for orchestration. The core decision this package informs is whether to hand-roll a state machine plus chained queue jobs, or adopt a durable execution runtime. Durable Workflow gives you declarative Workflow and Activity classes, replay persistence, and retry/error handling inside the Laravel app you already run — so the comparison is "buy a library" versus "build and maintain an orchestration subsystem," not "adopt a new platform."
• Which processes deserve durability. Roadmap triage: onboarding/signup flows, billing and subscription sagas, claims/approval flows with human-in-the-loop waits, data pipelines, and AI/agentic tool-call loops are the use cases the package names explicitly. Anything that must survive a deploy, a worker crash, or a multi-hour wait is a candidate; anything that finishes in seconds is not.
• Feature scoping without new headcount. Because the runtime is embedded and queue-backed, you can commit to "long-running, resumable" features without standing up a separate orchestration platform team — a real constraint for mid-size product orgs.
• Operability and support model. The docs are explicit that Waterline is a technical runtime UI for operators (fleet health, waits, retries, repair, history) and that business dashboards should read app-owned milestone projections keyed by workflow_id/run_id rather than runtime tables. That's a PM-level decision about who gets paged, what support sees, and what you expose to customers versus keep internal.
• Data ownership, retention, and tenancy. The dedicated storage connection option (storage.connection) means you can promise workflow state on its own database, with its own backup/retention/scaling policy, or per-tenant isolation. That unlocks deals and compliance conversations that "it's all in the default DB" would block.
• SLA and timeout commitments. Release 2.5.12's deadline semantics — original deadline retained from admission through retries and duplicate requests, late results unable to overwrite a timed-out outcome — let you state timeouts as product guarantees rather than best-effort.
• Polyglot roadmap gating. Embedded Laravel today; the standalone server plus durable-workflow/sdk later if Python/Rust workers appear. This is a staged architecture decision you can pre-commit to, rather than a rewrite trigger.
• Upgrade capacity planning. The release history is dominated by 2.0.0-rc.* and alpha artifacts alongside 1.0.x and 2.5.x lines. Treat "quarterly upgrade and regression work" as a line item in roadmap capacity, not as free.

When to Consider This Package

Adopt when most of these hold:

• The product is a Laravel/PHP application and the workflows genuinely live in-app — no cross-language workers required today.
• You have multi-step processes with external side effects that need retries, compensation, or resumption after failure, and today they're held together by ad-hoc jobs and status columns.
• Support and on-call need visibility into which step failed and what state a run is in, and you're willing to run Waterline alongside Horizon.
• You accept owning the state: schema, migrations, backups, retention, and the choice of default versus dedicated connection.
• You can pin versions and absorb churn, and you have at least one engineer who will own the workflow layer.

Look elsewhere when:

• Non-PHP participants are on the near-term roadmap. Go to the standalone server plus durable-workflow/sdk, or evaluate Temporal, rather than adopting embedded mode and migrating later.
• The work is short-lived and idempotent enough that Laravel's queue, Bus::chain, and Horizon retries already cover it. This package is overhead you don't need.
• You require a managed service. This is self-hosted with no managed offering implied; if the org has no appetite for operating durable state and its UI, that's a disqualifier.
• Procurement is strict. Installation is documented as a curl | sh script rather than composer require; expect security review to ask for the underlying package path and artifact verification. Budget time for that, or scope it out early.
• Vendor-risk tolerance is low. ~1,279 stars, zero dependents listed, sponsor-and-volunteer sustainment, and a 2.x line still shipping release candidates and alphas. That's a legitimate reason to defer, or to pilot rather than standardize.
• Version ambiguity matters. The presence of both 1.0.x, 2.0.0-rc/alpha, and 2.5.x release notes means you must pin deliberately and confirm which line gets security fixes — do not let a team float the constraint.

How to Pitch It (Stakeholders)

For executives: We can ship resumable, multi-step business processes — onboarding, billing sagas, approvals, AI tool loops — without buying or staffing a separate orchestration platform. It's MIT-licensed, runs inside our existing Laravel app and queue workers, and replaces bespoke per-feature orchestration code that currently costs us engineering time and produces half-completed-state incidents. The trade is a new operational surface (a runtime UI alongside Horizon) and a recurring upgrade cadence, plus modest vendor risk given the project's size and its in-progress 2.x line. Recommendation: pilot on one bounded, high-value workflow with pinned versions and a defined exit path, then decide on standardization at the next planning cycle.

For engineering: Declarative Workflow/Activity classes, replay persistence with a conformance command (workflow:v2:replay-conformance), native queue and event integration, retry and deadline semantics that survive duplicate delivery, configurable storage connection, and a separate operator UI. The ask is ownership: one engineer accountable for the workflow layer, version pinning, upgrade testing across MySQL/PostgreSQL, and a documented fallback if the project stalls or the polyglot path becomes necessary.