Temporal Bundle Laravel Package

Product Decisions This Supports

Build vs. buy for durable execution. Rather than hand-rolling a jobs table, a status enum, cron sweeps, and bespoke retry/backoff logic for every multi-step process, adopting Temporal (via this bundle) replaces that scaffolding with a workflow engine that persists state, retries deterministically, and exposes per-run visibility. The PM decision is: do we invest engineering months in workflow plumbing, or pay in operational complexity + a Temporal cluster?

Concrete feature surfaces this unblocks:

• Sagas with compensation — order fulfillment, refunds, chargeback handling: charge → reserve inventory → ship → settle, with automatic reversal on failure. Compensating transactions are the classic Temporal use case and the single biggest justification here.
• Long-running, human-in-the-loop processes — KYC/onboarding, credit underwriting, approvals that sit waiting days for a reviewer or an external webhook. These are painful with queues and cron; native with durable workflows.
• Scheduled/recurring business logic — dunning, subscription renewals, reconciliation jobs, statement generation — replacing fragile cron + lock tables.
• External API orchestration with flaky third parties — payment processors, KYC vendors, banks. Timeouts and retries become declarative config instead of per-integration code.
• Auditability/compliance requirements — every workflow run has a durable, queryable event history. That is a product/audit feature, not just an engineering convenience, and it materially shortens incident review and regulator-facing explanations.

Roadmap implications. Adopting this commits the team to Temporal as a platform dependency. That should appear explicitly on the roadmap as an infrastructure workstream (cluster or Temporal Cloud, worker deployment topology, observability, on-call runbooks), not be smuggled in as "a library swap." It also changes estimation: workflow-shaped features get cheaper over time, while simple CRUD stays the same.

Buy-side caveat the PM owns. This is a Symfony bundle, not a Laravel package. In a Laravel-first codebase, the realistic options are (a) use the Temporal PHP SDK directly and write a thin service-provider wrapper, or (b) use this bundle as design reference. Budget a spike to confirm which. Do not put this in a Laravel roadmap as a drop-in.

When to Consider This Package

Consider it when:

• The stack is Symfony (or you're comfortable wrapping a Symfony bundle's service definitions for another container). This is the gating criterion — 71 stars and 0 dependents mean you are early, and a framework mismatch is not worth fighting.
• You have at least one workflow that spans minutes to months, crosses multiple services or external APIs, and today lives in a chain of queued jobs, status flags, and cron. One good saga justifies the platform; "it might be useful later" does not.
• You are already running, or have approved, a Temporal cluster (self-hosted or Cloud). The bundle is an integration layer — it is not the engine and delivers nothing without the server.
• You need durable retries, timeouts, and per-run visibility as a product requirement (SLA reporting, customer-facing "where is my order/application?" status).
• You accept early-adopter maintenance: plan to pin a version, read the source, and be prepared to fork or vendor it. Single-maintainer, low-adoption packages are a support liability, and the MIT license is precisely the escape hatch you should intend to use.

Look elsewhere when:

• You're Laravel-native — use the Temporal PHP SDK directly, or a Laravel-oriented integration if one matures.
• Your async work is short, fire-and-forget, or non-durable (send an email, resize an image, invalidate a cache). Symfony Messenger, Redis queues, or a managed queue is cheaper and simpler. Temporal's operational overhead is not a rounding error.
• Nobody wants to own a Temporal cluster. If the org won't fund ops for the engine, the bundle is dead weight. Managed alternatives (Temporal Cloud, or a SaaS workflow product) change the calculus.
• You need vendor SLA and commercial support. This package has none; the underlying Temporal platform does.
• The workflow can be satisfied by a single database transaction plus an outbox. Reach for a workflow engine when you actually leave the transaction boundary.

How to Pitch It (Stakeholders)

For executives (one paragraph): We run several business processes — order fulfillment, payment reconciliation, onboarding/approval flows — that today are stitched together from queued jobs, status columns, and scheduled scripts. That custom plumbing is where most of our reliability incidents and a meaningful share of our maintenance cost come from, and it's invisible to the business when something stalls. Temporal is an industry-standard durable workflow engine that makes these processes resumable, retryable, and fully auditable; this package is a lightweight Symfony integration for it. The ask is approval to adopt Temporal as a platform dependency and to fund the operational setup — not a rewrite. The commercial case is fewer reliability incidents, faster delivery of workflow-shaped features, and an audit trail we currently reconstruct by hand during post-mortems. The package itself is MIT-licensed and small; our exposure is the platform, which we can de-risk by using Temporal Cloud, and the integration layer, which we can vendor if the maintainer walks away.

For engineering leads:

• What it is: a Symfony bundle wiring Temporal's PHP SDK into the container — client/worker configuration, service registration, likely attribute-driven workflow/activity discovery. Verify exact capabilities against source before committing; docs are thin at 71 stars / 0 dependents.
• Cost of entry: Temporal server (Cloud or self-hosted), worker deployment and scaling model, a new failure/retry mental model for the team, and observability integration. Budget a spike and one production workflow as a pilot.
• Risk posture: immature, single-maintainer, zero dependents, release cadence that looks pre-1.0. Mitigations: pin the version, wrap it behind our own interfaces so we depend on Temporal\Client, not on Vanta\TemporalBundle, add integration tests against a local Temporal dev server, and pre-agree that we will fork under MIT rather than block on upstream.
• What we ship first: one high-value saga with compensation (refunds/chargebacks), instrumented end to end. If that doesn't measurably reduce bespoke state-machine code and incident load, stop there — the decision stays reversible.