cmgmyr/laravel-messenger: a messaging package for Laravel

The gap cmgmyr/laravel-messenger fills in a Laravel app

Laravel gives you authentication, a query builder and Eloquent relations. It does not give you a place to store a conversation. If you want a user to open a thread, add someone else to it, and see an unread count on a navigation bar, you either build three tables and the relations around them, or you install something that already did.

cmgmyr/laravel-messenger is that something. The README describes it as a package that will "allow you to add a full user messaging system into your Laravel application", and the feature list is deliberately narrow: multiple conversations per user, optionally looping in additional users with each new message, viewing the last message for each thread, returning messages scoped to the whole system, to a user, or to a user's unread set, and returning a user's unread count.

The audience is a Laravel developer who already has a users table and wants messaging as a feature of an existing product, not as a standalone chat application. The README lists three shapes the same primitives can take: open threads where everyone sees everything, group messaging where only participants see their threads, and one-to-one private or direct threads. That flexibility is the point. The package stores relationships and hands back query results. It does not decide who is allowed to read what.

Threads, participants and the Messagable trait

The repository layout tells most of the story: config/, migrations/, src/, examples/, tests/. There is no assets directory and no views directory at the top level, only examples/views/ as a reference. The package is a data layer plus a trait.

Three tables carry the state. The config file names them with the keys messages_table, participants_table and threads_table, defaulting to messenger_messages, messenger_participants and messenger_threads. A thread row represents a conversation. A participant row ties a user to a thread. A message row belongs to a thread and to its sender.

Your user model joins the system through one line: use Cmgmyr\Messenger\Traits\Messagable. That trait is what gives a user object the messaging relations and helpers the README refers to, including the unread count. Because the trait sits on your own model, the package never assumes a table name or a primary key for users beyond what you configure.

The README's stated design goal is that usage is "very flexible so you can implement your own access control". That is an honest description of a real boundary. The package will happily return messages; whether the current user should see them is a question your controller has to answer. If you skip that step, participants in one thread can be shown another thread's contents by any endpoint you write loosely.

Installing cmgmyr/laravel-messenger and sending a first message

Installation is Composer plus three artisan steps. The README gives the package name as cmgmyr/messenger, not the repository name.

composer require cmgmyr/messenger

On Laravel 5.5 and later the README states that the service provider step is unnecessary because the package supports Package Discovery. On older 5.x releases you register Cmgmyr\Messenger\MessengerServiceProvider::class in the providers array of config/app.php.

Next, publish the configuration and point it at your user model. The config file lands at config/messenger.php.

php artisan vendor:publish --provider="Cmgmyr\Messenger\MessengerServiceProvider" --tag="config"

If you would rather not use the default table names, the README shows the keys to override:

'messages_table' => 'messenger_messages',
'participants_table' => 'messenger_participants',
'threads_table' => 'messenger_threads',

Then publish and run the migrations. The README notes that you need a users table first, and that the default Laravel migration is satisfactory if you do not already have one.

php artisan vendor:publish --provider="Cmgmyr\Messenger\MessengerServiceProvider" --tag="migrations"
php artisan migrate

Finally, add the trait to your user model:

use Cmgmyr\Messenger\Traits\Messagable;

class User extends Authenticatable {
    use Messagable;
}

For the controller, routes and views, the README points at examples/MessagesController.php, examples/routes.php and examples/views/ in the repository rather than reproducing them. Start there: those files are the fastest way to see how a thread is created and how the trait's methods are called. After php artisan migrate you should see the three messenger tables in your database, and a user model with the trait should respond to the unread-count helper described in the feature list.

What you have to build yourself, and where this is the wrong tool

The package ships no user interface. There is no Blade component, no chat widget, no JavaScript, and no route file in src/. Everything a person actually sees is your work. The examples/ directory is a starting point, not a product.

There is also no real-time layer. The feature list describes reading the last message for each thread and returning unread counts. It does not describe broadcasting, websockets or push. If your users expect a message to appear without a page refresh, you are adding that on top, and the README does not document how. The repository links two example projects, a Pusher demo and a Lumen API, but both are marked WIP in the README itself, so treat them as sketches rather than supported integrations.

Attachments, message editing, deletion semantics, typing indicators and read receipts beyond the unread count are not in the feature list. The README is silent on rollback: there is no documented down path for the published migrations, so plan the schema change as a one-way step in production.

Version support is another boundary. The Laravel compatibility table maps 4.* to messenger 1.*, 5.0 through 5.4 to 2.16.2 and below, and 5.5+ to 2.*. The README labels Laravel 4.x installation "no longer actively supported" and links to the v1 tree. If you are on Laravel 4, this is the wrong tool. If you are on a modern Laravel release, the 2.* line is the one the README points you to.

How it compares with Chatify and other Laravel chat packages

The closest thing to a category neighbour in the related searches is Chatify, a Laravel chat package. The difference is where the line between package and application sits. A chat package of that kind typically arrives with views, routes, an asset pipeline and a defined look. You install it and you have a chat screen, then you bend it toward your product.

cmgmyr/laravel-messenger goes the other way. It gives you the schema, the relations and the trait, and leaves the interface entirely to you. That is worse if you want something working this afternoon and better if the messaging has to look and behave like the rest of your application, or if you need access rules that no off-the-shelf chat screen would guess.

The trade is maintenance surface. With a UI-bearing package you inherit its front end and its opinions. With this one you inherit three tables and a trait, and you own every screen, every authorization check and every real-time decision. Choose based on whether your bottleneck is design work or plumbing work.

The repository also credits AndreasHeiberg/laravel-messenger as the starting point for this package, which is worth knowing if you find older references to that name in tutorials. It is the ancestor, not a parallel option.

Maintenance, licensing and upgrade cost

The last push to the default branch was on 2026-03-18, the same day as the 2.32.0 release. The release before that, 2.31.0, is dated 2025-03-09, and 2.30.0 is dated 2024-03-18. The pattern is roughly one tagged release per year, so expect to run a version that is months old rather than weeks old. Plan upgrades as an annual event, not a continuous stream.

The CI configuration visible in the README runs the test suite against SQLite, MySQL and PostgreSQL through three separate GitHub Actions workflows. That matters for a package whose job is migrations and queries: it tells you the three supported databases are exercised, and it tells you which ones are not mentioned.

Licensing is MIT, per the LICENSE file and the badge in the README. In practical terms that is a permissive licence with minimal obligation, but it is not legal advice and you should read the file if your organisation has rules about attribution.

The upgrade cost lives in the migrations and the config. Because the package publishes its migrations into your application, an upstream schema change does not reach you automatically; you either re-publish and reconcile, or hand-write the change. The config file is similarly yours after publishing, so a new config key added upstream will not appear in your copy. Both are normal for Laravel packages and both mean the upgrade is a manual diff, not a composer update alone.

Editorial conclusion

Adopt cmgmyr/laravel-messenger when you want thread, participant and unread-count storage inside an existing Laravel app and you are prepared to write the controllers, routes and views yourself. Do not adopt it if you need a ready-made chat interface, real-time delivery, attachments, or a maintained Laravel 4 branch. Before committing, check the published config/messenger.php against your user model, confirm the three migrations run on your database, and make sure your Laravel version maps to a supported messenger line.

Frequently asked questions

Official sources

1. cmgmyr/laravel-messenger on GitHub
2. Issues
3. License: MIT
4. README
5. Releases