Temporal Bundle Laravel Package

Technical Evaluation

Framing correction (blocking issue). The request scopes this as a "Laravel/PHP package," but vanta/temporal-bundle is explicitly a Symfony bundle. Bundles register via Bundle classes, DependencyInjection extensions, and Symfony service tags — none of which Laravel's container consumes. For a Laravel-first organization, this package is not directly installable — not "low fit," but structurally inapplicable without an impractical Symfony-kernel bridge. Every downstream conclusion below follows from that.

Architecture fit. Temporal is a durable-execution workflow engine. Its PHP SDK does not run workflows in a normal PHP-FPM request lifecycle; workflows execute inside RoadRunner, a Go-based application server that hosts long-lived PHP worker processes and handles deterministic replay. That means adopting this package means adopting three runtime components, not one:

1. A Temporal cluster (Cloud or self-hosted) with a persistence store and history shards.
2. RoadRunner workers (spiral/roadrunner, .rr.yaml config, plugin builds).
3. The bundle itself, which is a thin DI/configuration layer — client factory, worker factory, workflow/activity service tagging, connection config (address, namespace, mTLS), and likely console commands to start workers.

The bundle's genuine value is Symfony-idiomatic wiring: tagged workflow/activity registration, autowired WorkflowClientInterface, config-driven TLS. That is real but shallow — a few hundred lines of glue. It does not abstract Temporal's core constraints: deterministic workflow code, no direct I/O in workflows, versioned workflow definitions, payload size limits.

Integration feasibility. For a Symfony shop: moderate. For a Laravel shop: effectively zero out of the box; the viable path is the underlying temporal/sdk plus a first-party worker bootstrap, consuming the bundle only as a reference implementation to copy patterns from.

Technical risk — the dominant factor. The composite score of ~22.5 is directionally correct and I would not argue with it:

• 71 stars, 0 dependents. Zero dependents is the sharpest signal: no downstream user is running this in production in any way the ecosystem can observe. No canary, no upstream bug reports, no Stack Overflow corpus, no third-party tutorials. Every operational problem you hit, you own alone.
• Single-vendor provenance. VantaFinance is a fintech; this reads as an extracted internal tool published under MIT. That is not disqualifying — many good packages start this way — but it means the API surface reflects their needs and the maintenance cadence reflects their release cycle, not a community's.
• Data anomaly to verify. "Last release: 2026-10-25" is a future date. Either metadata is synthetic/skewed or the registry record is unreliable. Confirm actual release history, SemVer discipline, and whether releases track temporal/sdk minor versions or pin them; a stale pin is the most common way a thin wrapper becomes a liability.
• SDK-layer churn is the real risk, not the bundle. The Temporal PHP SDK is materially less mature than the Go/Java/TypeScript SDKs. Feature gaps (worker versioning, certain search-attribute and Nexus capabilities) surface late. Forking a 500-line bundle is cheap; forking the SDK is not.

Key questions to resolve before any commitment

• Confirm no Laravel intent, and confirm Symfony version support matrix (5.4/6.x/7.x) and PHP floor.
• What temporal/sdk and spiral/roadrunner versions are pinned, and what is the lag behind upstream?
• Is workflow versioning/patching surfaced anywhere, or left entirely to the developer?
• Does it ship a test harness (time-skipping test server wiring), or must teams build that?
• Bus factor: commit history, contributor count, issue-response latency, last non-release commit.
• Does Vanta run this in production, and would they accept PRs / provide a security contact?

Integration Approach

Stack fit

Recommended shape. Decouple orchestration from the HTTP application. Keep Laravel (or Symfony) as the API/admin surface. Run Temporal workers as a separate deployable — a RoadRunner-hosted PHP worker that bootstraps only the container it needs (DB, queue, HTTP clients), not the full web kernel. This lets the web tier scale on request volume and workers scale on task-queue backlog, which are unrelated curves. If the team is Symfony-native, adopt the bundle inside that worker only; if Laravel-native, copy its wiring patterns into ~200 lines of your own service provider — a cheaper and more honest dependency than a bridge.

Migration path (phased, each phase independently abandonable)

1. Local proof of concept (1–2 weeks). temporal server start-dev, one workflow with 2–3 activities wrapping existing service classes. Validate determinism constraints against real code. No production surface.
2. Non-critical workflow in production (3–4 weeks). Pick something with retry semantics you already want — webhook fan-out, onboarding email sequencing, nightly reconciliation — and something whose failure is recoverable. Run against Temporal Cloud to avoid operating Cassandra/PostgreSQL + history shards yourself.
3. Operational hardening. Worker deployment manifest, task-queue naming convention, alerting on schedule_to_start latency and workflow task timeouts, runbook for stuck workflows.
4. Expand only after phase 3 has run clean for a quarter.

Compatibility and sequencing. Lock the version matrix up front — PHP minor, RoadRunner, temporal/sdk, Temporal server, and (if used) the bundle — and pin all five. Treat any one of them as a coordinated upgrade, because they are. Establish a policy before the first production workflow that workflow code is versioned via patching, and that workflow definitions are never edited in place while executions are open. Retrofitting that discipline is the single most expensive mistake in Temporal adoption.

Operational Impact

Maintenance. Bundle maintenance cost is low — it is thin, and forking is realistic if it stalls. The maintenance burden that actually lands on the team is the SDK and RoadRunner: two additional dependency graphs with their own release cadence, both outside the normal Composer-update habit. Budget a recurring line item for upgrade evaluation, not just initial integration.

Support. No vendor backing for the bundle. Temporal's commercial support covers the platform, not this community wrapper; SDK-level PHP questions route to community Slack and GitHub. With zero dependents, expect to be the first to encounter most issues. Assume self-support and price it in.

Scaling. Three independent axes, each with a distinct bottleneck:

• Workers: scale horizontally on task-queue depth. PHP worker memory per process is the practical limit; RoadRunner pool size must be tuned against container memory, not CPU.
• Temporal server: history shard count and persistence throughput. Do not self-host until you have a concrete reason — this is real Cassandra/PostgreSQL operational work.
• Payloads: Temporal's blob size limits push large payloads to external storage (claim-check pattern). Design for this early; retrofitting is invasive.

Failure modes to instrument from day one

• Non-deterministic workflow code — replay fails, workflow task retries indefinitely, executions wedge. Most common and most confusing failure; needs a determinism check in CI.
• Activity retry storms — a misconfigured retry policy against a degraded downstream turns into a self-inflicted DoS.
• RoadRunner worker crash / OOM — in-flight activity lost, retried per policy; only safe if activities are genuinely idempotent.
• Task queue starvation — workers up but not polling the right queue; workflows sit in schedule_to_start with no errors anywhere.
• Sticky cache eviction — full replay per workflow task; latency spikes without obvious cause.
• Version skew — worker fleet mid-deploy on mismatched SDK/bundle versions.
• Namespace/TLS misconfiguration — silent connection failures, especially with mTLS on Cloud.

Ramp-up. Realistically 4–8 weeks before a competent PHP team is productive and safe, and that estimate assumes a team already fluent in Symfony or Laravel DI. The learning curve is not the API — it is the mental model: durable execution, determinism, replay, at-least-once activity semantics, and idempotency by design. Those are architectural habits, not library knowledge, and they will change how the team writes ordinary service code. Treat Temporal as a platform decision with a headcount/training implication, not as a Composer dependency.

Bottom line. Score ~22.5 is fair. The package is a competent thin wrapper with no adoption evidence and a hard Symfony constraint that disqualifies it for a Laravel estate. If the organization genuinely needs durable execution, the recommendation is: adopt temporal/sdk with Temporal Cloud, run workers as a separate RoadRunner deployable, and mine this bundle for wiring patterns. If durable execution is a "nice to have," the honest answer is to defer — the operational surface added is disproportionate to a 71-star, zero-dependent dependency.