munafio/chatify: a Laravel chat package with a bundled messenger UI

What Chatify solves, and who it is aimed at

Building chat into a Laravel application from scratch means writing message models, conversation membership, read receipts, typing indicators, attachment handling, and a frontend that renders all of it. Chatify packages that work as a composer dependency. The README describes it as "a real-time chat package for Laravel" with direct messages, group conversations, typing indicators, and attachments, installable with a single Artisan command.

The intended user is a Laravel developer who already has authentication and wants a messenger inside the existing application rather than a separate product. Two delivery modes are offered: a bundled messenger UI built with Vue 3, Pinia, and Tailwind CSS, served at /chatify, and a headless JSON API for teams that want to write their own SPA or mobile frontend. That split is the most useful design decision in the package, because it lets you start with the shipped interface and replace it later without rewriting the backend.

The feature list is long and specific: saved messages described as a "Telegram-style self-chat", reply, edit, delete and forward, voice notes, favorites, blocking, in-conversation message search, Giphy stickers, link previews, user-configurable themes, fonts, colors and wallpaper, localization with RTL support in English and Arabic, and Gravatar avatars. None of this is unusual for a messenger, but having it in one package is what the project is selling.

How the pieces fit together in a Laravel app

The repository layout shows the shape of the thing. There is src/ for the PHP package code, resources/ for views and assets, frontend/ for the Vue 3 application, lang/ for translations, dist/ for built assets, and tests/ with a phpunit.xml at the root. The README points to chatifyphp.com/docs for installation, configuration, groups, API reference, broadcasting setup, and customization, so the detailed wiring lives outside the repository itself.

Real-time behaviour is not self-contained. The requirements table lists broadcasting as "Pusher, Laravel Reverb, or compatible WebSocket server", which means presence, typing indicators, and read receipts depend on an external service or a self-hosted Reverb instance. Chatify does not ship its own WebSocket server. If you have never configured broadcasting in Laravel, that is the part of the setup that will take the longest, and the package documentation is where the project says the steps are.

The bundled UI is served at /chatify, and the headless JSON API is the alternative for teams that do not want the Vue frontend. Because the frontend lives in its own directory with a build step, you should expect to run a Node build to change the interface rather than editing PHP views. The README does not describe the API's authentication scheme or endpoint list; that detail is deferred to the documentation site.

Installing Chatify and opening the messenger

The README states that installation is a single Artisan command, and it gives the composer command for the v2 beta line. The requirements table sets PHP 8.2+ and Laravel 11+ as the floor, so check those before starting.

For the beta release line, the README gives this exact command:

composer require munafio/chatify:^2.0@beta

If you want the stable line instead, the README says v1 "remains stable on ^1.6". The package documentation at chatifyphp.com/docs covers the Artisan install step, configuration, and broadcasting setup; the README itself does not reproduce those commands, so follow the documentation for the install and publish steps rather than guessing at flags.

Once installed and configured, the bundled messenger UI is served at /chatify according to the README. Open that path in a browser while authenticated and you should see the messenger interface. Real-time features such as typing indicators and presence will not work until broadcasting is configured with Pusher, Laravel Reverb, or a compatible WebSocket server. If messages send but nothing updates live, broadcasting is the first thing to check.

The beta line and the version you pin

The README's most consequential line is the note that v2 is in beta, with the instruction to install it via the @beta stability flag. The latest tagged releases listed are v1.6.3 from 2024-03-17, v1.6.2 from 2023-07-27, and v1.6.1 from 2023-03-03. So the stable release history sits on the 1.6 line while the feature list in the README, including groups, saved messages, and the Vue 3 frontend, describes v2.

That creates a real decision. If you install ^2.0@beta you get the features the README advertises, on a stability flag that tells composer the dependency is not stable. If you install ^1.6 you get the stable line, and you should check the documentation to see which features are present there rather than assuming the README's list applies. The README links an Upgrading Guide at chatifyphp.com/docs/upgrading for moving between the two, which suggests the migration is non-trivial enough to warrant its own page.

A beta flag is not a reason to avoid a package, but it is a reason to pin an exact version in composer.json and to read the changelog before updating. The repository has a CHANGELOG.md at the top level, so the history is available to read before you commit to an upgrade.

What Chatify does not do, and where it is the wrong tool

Video calling is the clearest gap. The related searches show people looking for "chatify video call", but the README's feature list contains no video or voice call capability. Voice notes are listed, which is recording and playback of audio messages, not live calling. If calling is a requirement, Chatify is not the package for it and no configuration will change that.

The second constraint is the framework. This is a Laravel package with a documented floor of Laravel 11+ and PHP 8.2+. Symfony, Django, Rails, or Node applications cannot use it. The headless JSON API does not change this, because the backend is still PHP running inside Laravel.

The third is broadcasting. Because the README requires Pusher, Laravel Reverb, or a compatible WebSocket server, a deployment with no WebSocket infrastructure will need one added, and that is an operational cost that does not appear in the composer require line. Teams that want polling-only chat, or that cannot run a persistent WebSocket service, should look elsewhere. The README also does not document rollback or uninstall steps, so plan your database migrations before installing rather than after.

How Chatify differs from building on a general real-time service

The obvious alternative is not another Laravel chat package but a hosted real-time backend such as Pusher Channels or a self-hosted Reverb instance used directly, with your own message models and UI on top. The difference in approach is where the work sits. With a raw broadcasting service you define the channels, the event payloads, the persistence layer, and the interface yourself; the service only moves events between clients. Chatify assumes all of that and ships it, including the database schema, the Vue 3 frontend, and the JSON API.

That trade is the same one every opinionated package makes. You give up control over the data model and the markup in exchange for not writing them. If your chat needs to match an existing design system exactly, or if your message schema must integrate with an existing events table, the bundled UI and models become something to work around rather than something to use. The headless API softens this, since you can keep the backend and replace the frontend, but the persistence layer is still Chatify's.

Note also that Chatify itself depends on a broadcasting service rather than replacing one. Choosing Chatify does not remove the Pusher or Reverb decision; it adds a layer on top of it.

Maintenance, licensing, and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-09, which is recent relative to the release history. That matters because the newest tagged release, v1.6.3, is dated 2024-03-17, so the main branch has moved since the last stable tag. The activity is on the v2 line that the README labels beta.

Upgrade cost is concentrated in the v1 to v2 transition. The README links a dedicated Upgrading Guide, which is a signal that the move involves more than a composer update. Because v2 is beta, expect the API surface to change between beta releases; pinning an exact version and reading CHANGELOG.md before each bump is the practical approach. There is no published support window or long-term support commitment in the README.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows commercial use, modification, and redistribution provided the copyright notice and permission notice are kept. This is a description of the licence text, not legal advice; if your organisation has specific obligations around attribution or distribution, have someone review the LICENSE file directly. The README also directs security reports to the GitHub Security Policy rather than public issues, which is worth noting if you fork and maintain your own copy.

Editorial conclusion

Chatify fits a Laravel 11+ application on PHP 8.2 or newer that needs a working messenger interface quickly and can accept the beta status of v2 or pin to the stable ^1.6 line. It is the wrong choice if you need video calling, since the README lists no such feature, or if your stack is not Laravel. Before installing, confirm your broadcasting setup (Pusher, Laravel Reverb, or a compatible WebSocket server) and read the upgrading guide before moving from v1 to v2.

Frequently asked questions

Official sources

1. License: MIT
2. munafio/chatify on GitHub
3. Project website
4. README
5. Releases