Camunda Laravel Package

Technical Evaluation

Status: conditional pass, pending diff review. The 2.7.0 release publishes only a 2.6.0...2.7.0 compare link — no feature list, no fix list, no breaking-change callout, no compatibility statement. As TPM, treat 2.7.0 as an unverified minor bump and keep it out of the release train until an engineer reads the actual diff and posts a one-paragraph impact note. Everything below assumes conventional semver-minor behavior, which is an assumption, not a finding.

Architecture fit

• The package is a Laravel-side REST client for Camunda 7, with its most consequential capability being the external task pattern: Camunda owns process state and orchestration; the Laravel app registers workers that fetchAndLock tasks, run PHP business logic, and complete/fail them.
• This is the right shape when BPMN is the intended source of truth for long-running, human-and-system-spanning processes — approvals, onboarding, KYC, claims, order fulfilment. Business logic stays in the framework the team already knows; process definition moves to a diagram operations can read.
• It is the wrong shape when "workflow" means a three-state status column. Laravel queues plus a state-machine library are cheaper to own than an engine plus a client library. The engine's operational cost dwarfs the package's, and a TPM should say so out loud before anyone runs composer require.
• Scope discipline: this is an adapter, not a platform. It does not deliver BPMN modeling standards, process versioning discipline, or operational dashboards. Those are separate organizational commitments that must appear on the roadmap if the dependency is adopted.

Integration feasibility

• Installation is routine: Composer pull, service-provider auto-discovery, published config. A proof of concept against Dockerized Camunda 7 plus a scratch Laravel app is realistically one to two sprints including external-task lifecycle learning.
• The real feasibility questions are semantic, not procedural: lock duration and renewal for long handlers, maxTasks batching, async response timeout, retry/backoff policy, and the distinction between a technical failure (retry) and a BPMN error (business exception routed to an error boundary event). Require explicit answers before any revenue-critical process is committed.
• Verify against source, not README: authentication modes, multi-tenancy (tenant-id on fetch), and multi-engine/multi-environment configuration are the usual gaps in community Camunda clients.

Technical risk

• Platform lifecycle risk — highest. Camunda 7 is in end-of-maintenance, and Camunda 8's Zeebe runtime uses a different worker protocol (gRPC job workers), not the Camunda 7 REST external-task API. A Camunda 7-era adapter carries implicit migration liability. The roadmap must state whether this is a bridge or a destination.
• Bus factor. Single-vendor community package, low star count. Check commit cadence, open-issue age, CI matrix breadth across Laravel/PHP versions, and whether 2.7.0 closed or opened issues.
• Release opacity. No prose changelog means no deprecation signal. In Laravel packages the highest-impact silent changes are minimum PHP/Laravel bumps, config key renames, and changed default lock/timeout values — all of which alter runtime behavior without failing a build.
• Idempotency is a design obligation, not a package feature. External tasks are at-least-once by construction. Any handler with side effects must be idempotent regardless of what the wrapper guarantees.

Key questions to resolve before sign-off

1. What is actually in the 2.7.0 diff — features, config changes, minimum PHP/Laravel versions, new dependencies?
2. Does it still target Camunda 7 REST (/engine-rest) only, and which 7.x minors are tested?
3. Does it support lock extension, and does it expose BPMN-error vs. technical-failure semantics?
4. What is the test/CI and dependency-audit posture?
5. Who is the named internal owner, and would we fork if upstream stalled?

Integration Approach

Stack fit

• Target Laravel 9/10/11 on PHP 8.1+, a queue driver with at-least-once delivery (Redis, SQS, database), Supervisor-managed workers, and Camunda 7.20 self-managed or enterprise-supported. Validate the package's composer.json constraints against the real application matrix — not the README.
• Run Camunda workers in a separate process pool from ordinary application queues. A shared pool lets a slow BPM task starve user-facing jobs and destroys independent scaling and independent on-call signals.

Migration path

• Greenfield: no cutover risk, so the risk is adoption discipline.
• Phase 0 — proof of concept on one low-stakes, read-mostly process (document approval, notification fan-out) to validate the full worker lifecycle.
• Phase 1 — port exactly one existing hand-coded async workflow to BPMN; instrument and compare failure and duplicate rates against the baseline.
• Phase 2 — broaden only after an operational runbook exists. Do not start with money movement, regulatory reporting, or anything finance reconciles monthly.

Compatibility

• Pin to the exact Camunda minor version used in staging; REST behavior differs across 7.x releases.
• Config publishing is the classic Laravel upgrade trap: vendor:publish --force overwrites production config, and config:cache masks newly added keys that were never published. Diffing the published config between 2.6.x and 2.7.0 is a mandatory step, not a nice-to-have.
• Confirm 2.7.0's framework floor before touching the application's Laravel version — never couple those two upgrades in one change window.

Sequencing

1. Engineer reads the 2.6.0→2.7.0 diff and linked issues; writes a one-page impact note. TPM owns the gate.
2. Full test suite plus a staging worker against a real Camunda instance.
3. Canary a single task topic in production with a rollback pin to 2.6.x staged and ready.
4. Deploy through CI with composer.lock committed. Never composer update on a production host.

Operational Impact

Maintenance

• Expect to read library source periodically; documentation for community Camunda clients is thin and version drift is common. Budget roughly 0.1–0.2 FTE for upgrade hygiene, dependency pinning, and compatibility testing, with a spike in any quarter where Laravel or Camunda moves.
• Carry a documented exit plan — fork, vendor, or rewrite the worker layer against the REST API directly. Exit cost is weeks, not quarters, provided business logic lives in application services rather than package callbacks. Make that an architectural review criterion, not a hope.

Support

• Community GitHub issues only: no SLA, no vendor escalation path. Name internal Laravel engineers as the escalation route and pre-agree the fork trigger — e.g. a critical process blocked by an unmerged upstream fix for more than N working days.

Scaling

• Horizontal worker scaling is the lever; Camunda's fetchAndLock with a lock duration is the throttle. Set lock duration above p99 handler latency or you will manufacture duplicate executions under load.
• Watch the engine, not the PHP side: history table growth (aggressive history TTL outside production), Job Executor metrics, and REST call volume. A 200-worker fleet polling an undersized engine is a self-inflicted outage.
• Queue time is process latency. Instrument end-to-end process duration against business SLAs, not just worker throughput — a healthy worker fleet can still breach a customer promise.

Failure modes

• Lock expiry → duplicate execution. The dominant real-world failure. Mitigate with idempotent handlers plus lock-duration headroom.
• Crash after side effect, before complete(). Task retries and the side effect repeats. Same mitigation; additionally log the external task ID as the correlation key on every side-effecting call so finance and support can reconcile.
• Engine unavailability or network partition. Workers idle or retry-storm; in-flight tasks stall until lock timeout. Require backoff with jitter and a circuit breaker, plus a defined degraded-mode behavior per process.

Ramp-up

• Roughly 2–3 weeks for a competent Laravel engineer to be productive: BPMN basics, external-task lifecycle, lock/idempotency discipline, and operating against a real engine. Add a half-day of TPM/BA training on BPMN model reading so the process-ownership pitch is real rather than aspirational.
• Require one happy-path smoke test against a live engine, wired into CI, as the permanent gate for every future bump of this package. That single artifact converts a blind dependency into a managed one — and it is the cheapest risk reduction available on this package today.