Sdk Laravel Package

Technical Evaluation

Architecture fit — Unchanged in shape: durable-execution with a client surface (start workflows / send signals from the request path) and a long-lived worker polling task queues. That split mirrors Laravel's web-request vs. queue:work/Horizon topology. Workflow state still lives in an external orchestration server; the Laravel app is producer and consumer, not system of record. New in this release: the notes reference a managed Worker whose startup and registration are handled by the SDK. That is an additional topology option — an SDK-supervised worker rather than a Supervisor-managed queue:work-style process — and it needs to be evaluated explicitly, because it changes who owns process lifecycle, restart policy, and health reporting on the box.

Integration feasibility — Materially better than the prior read. The release notes reference "supported Laravel/Symfony bridges," which contradicts the earlier assumption that no first-party bridge exists. If a Laravel bridge ships, the adapter surface shrinks from "service provider, config, worker command, health check built from scratch" to "install, publish config, wire the provided command into Supervisor, add a health check." Confirm the bridge's actual scope before counting the savings — a bridge that only registers the service provider is not the same as one that ships an Artisan worker command with sane concurrency defaults. The dependency-conflict risk is unchanged (standalone package; still pin-check symfony/* and guzzlehttp/*). The "zero dependents" observation no longer means zero prior art: the release cites a replay corpus and an installed acceptance run against a published Server 2.9.4, so there is a real compatibility test harness upstream even if customer references remain absent.

Technical risk — Still high, but the type of risk is shifting from "unknown quantity" toward "small-team dependency," which is a more manageable problem. Positive signals in this release: explicit statement that public API signatures, runtime dependencies, and protocol floors are unchanged (patch discipline, no surprise semver break); CI qualification spanning PHP 8.1–8.4, the bridges, a replay corpus, packaging, docs, and Sonar; and an end-to-end acceptance test against a named, published server version rather than a mock. That is a credible release-engineering posture for a small project. The unresolved risks remain vendor/open-core lock-in on the server side, thin external adoption, and competition from the mature Temporal PHP SDK.

The bug itself is a genuine integration footgun and worth reading as a signal, not just a patch: PHP silently casts numeric string array keys to integers, so workflows or activities named "0", "17", or "017" were being mangled during worker registration, and keyed registration metadata was serializing as JSON lists instead of objects. Anyone who names handlers by ticket number, order ID, or step index would have hit this. It is fixed, but it is the kind of defect that produces a silent "workflow registered under the wrong name" failure rather than a clean error.

Key questions —

• What exactly do the Laravel and Symfony bridges cover? Service provider only, or config, Artisan worker command, and health/readiness endpoints?
• Is the managed Worker the recommended production path, and if so, what supervises it — the SDK, Supervisor, or nothing? What is its restart and backoff behavior?
• Is the server open source, source-available, or commercial-only, and what is the self-hosted upgrade and support path?
• Is the worker pure PHP, or does it require RoadRunner, Swoole, or pcntl? (A pure-PHP worker remains a genuine differentiator against Temporal.)
• Which Laravel versions are supported? PHP 8.1–8.4 is now evidenced; the framework matrix still is not published.
• Is the "protocol floor" policy documented, and does it guarantee a newer worker can talk to an older server (rolling-deploy safety)?
• What is the determinism and workflow-versioning model for changing code while executions are in flight, and is the replay corpus usable by us to test our own workflow code?
• Does the client accept injected PSR-18/PSR-3 implementations to reuse Laravel's HTTP client and logger?
• What are Cloud pricing, data residency, and egress terms?

Integration Approach

Stack fit — Assume Laravel 10/11 on PHP 8.1+; this release explicitly qualifies 8.1–8.4, which covers the realistic migration window. Prefer the first-party Laravel bridge over a hand-rolled adapter, but audit it first. Worker runs under Supervisor alongside existing queue workers and Octane; the client is called from controllers, jobs, and listeners. If the managed Worker is adopted, decide up front whether it lives in the same Supervisor program group as the queue workers or in its own, so that a crash-loop in one does not mask the other.

Migration path — Unchanged: do not displace the queue system. Move one bounded, long-running, multi-step process (order fulfillment saga, KYC/onboarding, invoice dunning) and wrap all SDK calls behind an internal WorkflowClient interface so a swap to Temporal — or a rollback to chained jobs — stays cheap. Add one new rule to the migration checklist: adopt an explicit naming convention for workflows and activities (namespaced, non-numeric, e.g. orders.fulfill, not 17). The 2.5.1 fix removes the crash, but numeric-keyed names remain a category of bug you do not want to rediscover in your own metadata or tooling.

Compatibility — Improved confidence. "Protocol floors unchanged" plus a passing acceptance run against published Server 2.9.4 means a worker upgrade on this patch does not require a server upgrade — rolling deploys are safe for this release specifically. Still confirm the general policy: does the project commit to N-1 worker/server skew, or was 2.5.1 merely compatible by accident? Verify required PHP extensions and whether the bridge pins a Laravel range.

Sequencing — (1) Spike against a Cloud trial or docker-compose self-hosted instance in non-production, exercising both the Supervisor-managed worker and the managed Worker so the lifecycle difference is concrete; (2) audit and, if needed, thin-wrap the Laravel bridge — service provider, config, worker command, Supervisor template; (3) pilot a single workflow with rigorously idempotent activities and non-numeric handler names; (4) wire logs, metrics, and traces into the existing observability stack, including worker staleness alerts; (5) gate any expansion on roughly 30 days of clean operation and a documented build-vs-Temporal decision.

Operational Impact

Maintenance — You still own the Laravel integration layer, but less of it if the bridge is real. A patch release with an explicit "no API, dependency, or protocol change" statement is exactly the kind of upstream behavior that makes routine upgrades cheap; budget for the opposite case anyway, since a small team will eventually ship something you must fork or vendor-patch. Recurring effort goes to SDK upgrades and re-validating against each server release.

Support — Community-only unless a paid Cloud tier is purchased. Q&A footprint remains effectively nil; escalation is GitHub issues — though issue #180 being fixed and linked to an installed acceptance comment shows the maintainer closes the loop with reproduction evidence, which is better than the prior read suggested. Still not an SLA. The org-level governance references are mildly reassuring but contractual obligations require a paid tier.

Scaling — Workers are stateless and scale horizontally, same as Horizon — that half is easy, and the managed Worker may remove some of the process-management toil. The hard half is unchanged: the server is a new stateful tier. Self-hosting means owning a database-backed orchestration service with HA, backups, and upgrade windows; Cloud removes that burden but puts a third party in the critical path of business transactions.

Failure modes — Worker crashes mid-activity cause duplicate side effects unless activities are idempotent. Non-deterministic workflow code (clock, random, DB, or HTTP calls inside workflow scope) causes replay divergence and permanently stuck executions. SDK/server version skew produces task failures during deploys — a risk this release explicitly mitigates. Server outages fail workflow starts, so decide fail-fast vs. buffering at the Laravel boundary. Bursty load starves task queues if per-queue worker concurrency is not tuned. Newly documented from 2.5.1: handler-name collisions and type coercion — numeric-string workflow or activity names were collapsed or reinterpreted at registration, and keyed metadata serialized as JSON arrays instead of objects. Fixed on 2.5.1, but treat it as a reminder to assert at boot that the expected set of handlers is registered under the expected names, rather than discovering a missing workflow at first dispatch.

Ramp-up — Unchanged at two to three engineer-weeks before the first safely production-grade workflow, driven by the durable-execution mental model (deterministic orchestration, side effects isolated in activities, explicit versioning of in-flight workflows) rather than by the SDK's API surface. The replay corpus is worth investigating as a training and CI asset — if you can run your own workflow code through it, it converts a conceptual hazard into a test. Recommend a time-boxed proof of concept with a written go/no-go against Temporal before any broader commitment.