Pusher Chatkit Server Laravel Package

Product Decisions This Supports

• Build vs. buy for chat/messaging. This SDK sits on the server-side admin plane of a hosted chat product — provisioning users, creating rooms, managing membership/roles, and minting auth tokens, while clients talk to the vendor's real-time service directly. That split (thin server SDK + vendor-hosted realtime + client SDKs) is the canonical "buy" shape for chat. It is the decision this package most directly informs, even though the answer today is "don't buy this."
• Requirements checklist for a chat roadmap. If messaging, presence, typing indicators, read cursors, or room permissions are on the roadmap, the surface area this SDK exposes is a decent enumeration of the primitives a chat vendor must provide. Useful as a scoring rubric when evaluating alternatives.
• Vendor risk assessment / deprecation triage. Archived repo, 35 stars, 0 dependents, and a service (Pusher Chatkit) that Pusher has discontinued. This is a clean worked example of vendor-lifecycle risk on a managed dependency — worth citing when setting internal policy on hosted-service SDKs (exit plans, abstraction layers, data-export clauses).
• Legacy maintenance and migration scoping. If any Laravel codebase still references this package, the decision is a migration one: audit call sites (user sync, room creation, token issuance), estimate a replacement, and confirm whether stored chat data needs exporting.
• Architecture signal for the "don't couple to the vendor" argument. Because the SDK is thin and the state lived in the vendor's system, a migration means re-provisioning users and rooms elsewhere — a concrete argument for keeping a local users/rooms/messages schema of record even when buying.

When to Consider This Package

Adoption criteria, stated plainly:

• Vendor is active and the service is still sold. Chatkit fails this outright. Do not evaluate this package for new work in any scenario.
• Repository health signals. Archived, 35 stars, 0 dependents, no upstream maintenance. Treat archived + zero dependents as a hard stop for anything customer-facing; it means no security patching, no PHP/Laravel version compatibility work, and no community debugging.
• You need the SDK to outlive your integration. A dependency you cannot upgrade is a ceiling on your framework upgrade path. In a Laravel app that's a direct constraint on future Laravel major upgrades.

When to look elsewhere — i.e., always, for new builds. Consider:

• Transport-only: Pusher Channels (still supported) or Laravel Reverb + Echo if you want to own the domain model and only buy the socket layer.
• Managed chat: Stream Chat, Sendbird, Ably, Twilio Conversations — all with maintained PHP server SDKs.
• Self-hosted: Laravel broadcasting + a messages/rooms schema, or Matrix/Rocket.Chat if you want a product rather than a library.

The one narrow case for looking at (not depending on) this package: as reference code. Its structure — Composer package, service provider, config file, typed request/response wrappers around a REST admin API — is a reasonable template if you're writing your own SDK wrapper around a chat vendor, and it's a useful guide for what to abstract so a future swap doesn't touch application code.

How to Pitch It (Stakeholders)

To executives: We evaluated the Pusher Chatkit PHP SDK as a shortcut to shipping chat. Recommendation is to reject it. The underlying service has been discontinued and the SDK repository is archived — meaning no security patches, no support, and no vendor with an incentive to keep it running. The integration cost looks low (it's a standard Composer package for Laravel), but the real cost is a forced re-platforming of our messaging feature on someone else's timeline, plus a data migration out of a system nobody is maintaining. The package's own signal set — 35 stars, zero dependent projects, archived — confirms no one else is betting on it either.

To engineering: Standard Laravel ergonomics (service provider, config publish, facade-style client), so it would take days, not weeks, to wire up. But the API endpoints it calls are gone, and the archived state means no compatibility work for future PHP or Laravel majors. Treat it as a reference implementation for how to wrap a chat vendor's admin API — particularly its separation of server-side provisioning from client-side realtime — not as a dependency.

Recommendation: Kill the Chatkit path. If chat stays on the roadmap, run a fresh vendor evaluation against criteria this package conveniently illustrates (user/room provisioning, roles and permissions, presence, webhooks, data export). Budget the decision on total cost of ownership and exit cost, not on integration speed — and require a data-export story and an abstraction boundary in whatever we pick.