Collaboration Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a Statamic Pro control-panel addon. There is no meaningful integration path in a stock Laravel application. The only viable architecture fit is: Statamic Pro as the CMS, editors working in the Control Panel, and an operable broadcasting layer (Laravel Reverb self-hosted, Pusher, or Ably) underneath. If any of those three are absent, the evaluation ends at the prerequisite gate. Treat "we run Laravel" as irrelevant; the qualifying question is "we run Statamic Pro and can operate websockets."

The functional scope is narrower than the marketing reads. What ships is advisory presence: live avatars, "someone else is editing" warnings, conflict prompts before save. It is not hard locking, not character-level co-editing, not merge resolution. That distinction is the single most important thing to get right before it reaches a stakeholder deck — "co-editing" oversells it and will set expectations the package cannot meet.

Integration feasibility. Installation itself is cheap: composer require, publish config, wire BROADCAST_CONNECTION, run install:broadcasting, start Reverb, rebuild assets. The real work is not the install, it is the four things around it:

1. License/procurement — Statamic Pro is a hard requirement. Clear it before any engineering time is spent.
2. Broadcast infrastructure — someone must own websocket uptime. Reverb self-hosted means a supervised process, TLS, reverse-proxy Upgrade header handling, and CSP connect-src entries. Pusher/Ably converts this into a vendor line item. Either way it is a real cost that is not on the composer receipt.
3. Channel authorization vs. Statamic permissions — the presence channel auth path must be read in routes/ and src/ to confirm it inherits Statamic's permission model. If it doesn't, users without edit rights can see who is editing, or presence attaches to the wrong entry across sites. This is an unverified assumption until someone reads the code.
4. Storage concurrency — Statamic stores content as flat files. On shared/NFS/network storage, file-level locking semantics are unreliable. This is the most likely source of actual data loss and the one failure mode the addon cannot insulate against.

Technical risk. Ranked by probability × impact:

• Flat-file concurrency on network storage — high impact, moderate probability, entirely outside the package's control. Must be validated on production-equivalent storage, not a laptop SSD.
• Broadcast infrastructure ownership gap — high probability of becoming an unowned production dependency. Reverb is shipped by Laravel, but presence, reconnection, and stale cleanup are the package's problem — websocket uptime is yours.
• Stale presence / ghosting — certain to occur. Editors will occasionally see phantom collaborators after hard disconnects until timeout. Low severity, guaranteed ticket volume.
• CSP and proxy blocking the websocket upgrade — high frequency, low severity, but it consumes senior time because it presents as "collaboration is broken" at the app layer when the cause is infra.
• Version boundary (1.x → 2.x) — a discrete work item with its own test pass if you are upgrading rather than greenfielding.
• Thin adoption signal — 36 stars, 0 dependents. There is effectively no public troubleshooting trail. When something breaks, you escalate to the vendor; you do not find a Stack Overflow answer. That is a support-model cost, not a code-quality judgment.
• Multi-site — fixed in 2.0.1 (#115), but a fix is not a proven matrix. Your topology needs its own regression pass per site, including cross-site entries.
• Metadata anomaly — the listed last release (2026-04-27) is future-dated. Validate against the repo's real release history and compatibility matrix before treating cadence as a signal of anything.

Key questions to answer before committing engineering time.

• Is the Statamic Pro license cleared, and do we intend to stay on Statamic for the life of this content estate?
• Who owns websocket uptime in production — a named team, not a role?
• Do our editors actually collide, or do they work sequentially by convention? Presence indicators buy nothing if the latter.
• Does our reverse proxy and CSP already permit websocket upgrades to the broadcast host?
• Does our production storage backend have defensible file-locking semantics for simultaneous saves?
• Does channel authorization inherit Statamic's permission model, and has anyone read that code path?
• What is the degraded-mode behavior when the broadcast server is down — quiet fallback to plain Statamic, or a hard CP break?
• What are the kill criteria, written into the ticket before the pilot starts?

Integration Approach

Stack fit. Only one shape qualifies: Statamic Pro + Laravel with a broadcasting driver you can operate + PHP/Statamic versions pinned in composer.json. There is no broadly published compatibility matrix, so the composer.json is the contract. Pin statamic/collaboration >=2.0.1 — below that, multi-site is disqualifying rather than merely risky.

The dependency footprint is unusually clean for a real-time feature: presence tracking, channel authorization, reconnection and state reconciliation, and stale-presence cleanup are all deceptively expensive to build well on Laravel. Building it internally is an open-ended project; buying it converts that into a license line plus an infrastructure dependency. Name that trade explicitly in the decision log so it doesn't get relitigated in month three.

Migration path. Greenfield is straightforward — no existing state to reconcile. The two paths that need their own work item:

• 1.x → 2.x upgrade. Treat as a discrete project with a full test pass. If the upgrade path isn't documented, that is a scoping risk, not a footnote.
• Non-Statamic or pre-Pro. There is no migration path. Stop and reassess whether the real requirement is Statamic Pro at all, because adopting this package deepens Statamic commitment for the life of the content estate. That is a platform-standardization decision, not a plugin purchase, and it should be made deliberately rather than as the side effect of one project.

Compatibility. Three compatibility surfaces to validate independently:

1. Version pins — Statamic Pro, Laravel, PHP against the package's real constraints.
2. Multi-site topology — v2.0.1 fixes the known defect, but validate your own layout: same entry/same locale with two editors, same handle/different locale, and cross-site access to a shared entry.
3. Custom fieldtypes — Bard/ProseMirror customizations and bespoke fieldtypes against the CP editing surface are undocumented territory. Scope a validation pass as its own task, not a test-suite footnote.

Sequencing. Order matters; each step gates the next.

1. License and procurement check — Statamic Pro cleared, budget owner named.
2. Confirm 2.x baseline — pin >=2.0.1; scope 1.x → 2.x separately if applicable.
3. Broadcast infrastructure decision — Reverb (own the ops) vs. Pusher/Ably (own the invoice). Then stand it up with TLS, auth, and CSP configured before the app layer.
4. Staging install — role/permission mapping validated against channel authorization, plus a dedicated multi-site pass on the real topology.
5. Bounded pilot — config-gated enablement: staging → one collection → one site → all editors. Never switch on globally on day one.
6. Degraded-mode and rollback definition — stop the broadcast server and confirm the CP degrades quietly rather than hard-failing. Wire the kill switch.
7. Progressive rollout with the two-window test automated in Dusk or Playwright against a staging build with two authenticated sessions.

The two-window test — two different users in two browsers, not two incognito tabs of one user — exercises roughly 80% of what goes wrong in production. Assert on the visible presence affordance, not internal state; presence is timing-sensitive and unit tests won't touch the failure modes that matter.

Operational Impact

Maintenance. The package is maintained by Statamic core maintainers (jackmcdade, jasonvarga), which shifts the support posture from community-first to vendor-first. That is the reason to trust it — provenance, not popularity. The practical consequence is that there is almost no public troubleshooting trail, so on-call capacity should be budgeted for vendor escalation rather than forum archaeology.

Support. Two support surfaces, not one:

• The addon — vendor-supported, thin adoption, escalate directly.
• The broadcast layer — yours if Reverb, a vendor SLA if Pusher/Ably. Reverb needs a Supervisor/systemd unit, process monitoring, and a documented restart procedure. This is the piece most likely to be under-resourced because it isn't on the purchase order.

Scaling. Presence scales with concurrent editors in the CP, not with site traffic — a small number relative to public traffic. The scaling constraints that actually bite are:

• Concurrent editors per entry — presence fan-out is per-entry; campaign and homepage surfaces with many editors are the stress case.
• Websocket connection count — modest, but connection durability matters more than peak. Reconnection storms after deploys are the realistic incident.
• Storage contention — this scales with simultaneous saves, and on network storage it degrades badly. Validate against the storage you will actually run in production.

Failure modes. Document each of these and their expected behavior before the pilot, so tickets route to the right team:

Do not build automation — auto-save gates, publish blocks — on presence state until the staleness window has been measured empirically. Use the improved debugging output from #114 as the first diagnostic before reaching for Redis or Echo inspection.

Ramp-up. Editor-facing ramp-up is small but not zero: presence affordances, the conflict warning, and the expectation that phantom collaborators are a known artifact rather than a bug. Plan a short comms note rather than training. Engineering ramp-up is moderate — the install is trivial, the surrounding infrastructure and authorization validation is where the calendar time goes.

Strategic posture. Treat this as a pilot candidate, not a default. It is a table-stakes checkbox for enterprise editorial teams and rarely the highest-value item for a two-person content team. It competes for the same budget as approvals, scheduled publishing, localization workflows, and audit trails — and it does not solve any of those. Extension points are limited; it is a closed, opinionated CP feature. If the real gap is workflow rather than presence, extending this package to cover it is a build project wearing a vendor costume. Buy presence here; build workflow elsewhere.

Kill criteria, written into the ticket not the retro. Two candidates: no measurable drop in overwritten-revision incidents after 60 days, or websocket ops burden exceeding the collaboration value delivered. A config-flag rollback is what makes the kill cheap — that is the primary architectural insurance this package offers, and it should be wired before the pilot opens, not after it stalls.