Wirechat: a Livewire chat package you embed into a Laravel app

It is a package you embed, not a chat service you run

Wirechat is described as a powerful Laravel Livewire chat package that brings real-time private and group communication to your application, with embeddable components that integrate into your project to provide a feature-rich chat experience for your users. The distinction between a package and a service is the whole design. There is no separate deployment to host, no account system to configure and no tenant to provision, because the chat lives inside an application that already has users, and the components are dropped into the views of that application. The topic list names the stack underneath, with Laravel, Livewire, Livewire components, Tailwind CSS, Alpine.js and WebSockets, so the delivery mechanism is a Livewire component talking over a WebSocket connection rather than a hand-rolled JavaScript client. The homepage for the project is at corepine.dev, the documentation is at wirechat.namuio.com, and the repository is MIT licensed with a LICENSE.md file at the top level.

The feature list is group management, not just message sending

The features listed cover more than the transport. Private and group chats come with real-time messaging, customizable groups, admins and permissions, which means the package carries an authorization model rather than leaving you to build one. Smart deletes let you delete messages or chats without affecting others, which is a distinction that only matters once a chat product has a notion of ownership per message. Media sharing covers sending files with previews and attachment management. Search and realtime are paired in one bullet, instant messaging with search capabilities, so the index has to be queryable as well as appendable. Customizable themes match your brand with configurable colours and a dark mode, and message replies work for both messages and attachments. The repository layout backs up that a chat product is a full application surface, with a database directory for migrations, a lang directory for translations, a config directory, a resources directory for views, a routes directory, stubs for publishing, and a tests directory alongside a workbench directory for local development.

Local development runs through a fork and a workbench

The contribution notes tell contributors how to work on the package itself, and the same steps are what you would do to try it inside your own application. Because Wirechat is a Laravel package, contributors are asked to work from a fork and keep each change on a focused branch.

git clone https://github.com/YOUR-USERNAME/wirechat.git
cd wirechat
composer install
cp .env.example .env

The package uses the workbench application for local development and Orchestra Testbench for automated tests, which is the standard Laravel approach for developing a package with a host application standing in for a consuming project. The workbench directory is present in the tree, and so is testbench.yaml, which is the Testbench configuration. The steps are deliberately ordinary Laravel steps, with no build step, no JavaScript toolchain and no container to start, which is a good sign for a package that is meant to sit inside an existing application rather than beside it. The .githooks directory and the AGENTS.md file at the top level suggest the repository enforces some of its conventions automatically rather than relying on reviewers to catch them.

Four checks, and the guidance on which ones you actually need

Before opening a pull request, the readme asks you to run the checks that match your change, and lists the four.

composer test
php vendor/bin/pest
php vendor/bin/pint --test
php vendor/bin/phpstan analyse

That is a test suite, the Pest test runner, Pint in test mode for formatting and PHPStan for static analysis, and the repository carries a phpstan.neon file and a phpunit.xml at the top level to configure them. The composer script wraps the test command so you can run one entry point. The readme also sets expectations about scope, saying that documentation-only changes do not usually require the full test suite, while code changes should include a focused test run and any relevant formatting or static analysis checks. That is a sensible rule for a package with this many contributors, and it also tells you what a maintainer will look for in a pull request. The practical value for a consumer is that the same commands run against the package inside your own project, so you can verify compatibility before you upgrade.

A 0.6 line on a 0.6x branch, with betas before the release

The version picture tells you how settled the package is. The default branch of the repository is 0.6x, and the recent releases are v0.6.0 from 2026-07-19, preceded by v0.6.0-beta2 on the same day and v0.6.0-beta1 on 2026-07-17, which is a fast beta cycle for a single minor release. The last push to the repository was on 2026-10-14, and the repository is not archived, so the work is still going on. A 0.x line in the Laravel ecosystem usually signals that the API is still moving, and here that is reinforced by the default branch being a version branch rather than main. The changelog lives in the repository as CHANGELOG.md, and the readme points at it for the latest changes, which is where you would look before an upgrade. The topics also mention aplinejs, a typo for Alpine.js, which is a small reminder that the README is written quickly and that the documentation site is the more complete reference.

Where the boundary of the package sits

Two limits are worth naming. The first is the WebSocket layer. The topics list WebSockets as part of the stack, and the documentation site is where the server setup for your own deployment would be covered, because a Laravel package cannot decide whether you run Reverb, a container or a managed service. That is a real amount of infrastructure work for a team that assumed chat was a component, and it is the part that decides whether the feature is worth the effort. The second is the messaging semantics themselves. Everything the readme lists is about delivering and organising messages between the users of one application, and nothing about presence indicators, typing notifications, delivery receipts or multi-device sync. If your product needs a Slack-like experience with presence and read state across a phone and a desktop, the package may cover the transport and the data model but leave that behaviour to you. The documentation site is the place to confirm before you commit to the dependency.

Editorial conclusion

Wirechat fits a Laravel application that needs private or group messaging as a feature of its own product, because the components are embeddable and the surrounding permissions, groups and admin model come with the package rather than being yours to build. It does not fit a team that wants a standalone chat service, since this is a package for embedding rather than a product to deploy, and it does not suit a project pinned to a 1.0 or later line, because the default branch is 0.6x and the newest release is v0.6.0. Before you adopt it, read the documentation for the Livewire and Alpine versions it expects, decide how you will run the WebSocket layer in your own deployment, and run the package's own check suite locally with composer test, Pest, Pint and PHPStan before you merge anything into your application.

Frequently asked questions

Official sources

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