turbo-laravel: Laravel conventions for Hotwire without building a SPA

A conventions package, not a rendering engine

The package describes itself in one sentence: it gives you a set of conventions to make the most out of Hotwire in Laravel. That wording is deliberate and it is the thing to hold on to during evaluation. Turbo Laravel does not implement Turbo. Turbo itself is the browser-side library from Hotwire, and this package is the Laravel-side half that makes those conventions idiomatic in a Laravel codebase. What that means in practice is that the package supplies the routes, the view helpers, the broadcast integration and the test scaffolding, and the application is still a Laravel application rendering Blade views on the server. The repository topics list turbo-drive, turbo-frame and turbo-stream, which are the three mechanisms the package exists to support. A team evaluating this is really deciding whether the Hotwire model fits their product, and this package is the amount of work that decision saves you.

The Turbo Rails gem is the reference implementation

The package documentation states plainly that it was inspired by the Turbo Rails gem, which is the equivalent for Ruby on Rails. That is the fastest way to understand the shape of the design, and it is a useful comparison because Rails developers have had a version of these conventions for long enough to have settled some arguments. Where the two ecosystems differ, in routing, in broadcasting, in the ORM, the Laravel package had to make its own choices, and the source tree shows what it chose. There is a routes/ directory, which is where the Turbo-specific endpoints live, a config/ directory for the package configuration, and resources/ for the shipped views. The src/ directory holds the PHP implementation, and stubs/ holds the publishable files, which is the Laravel convention for letting an application override a package's default templates rather than editing vendor code.

Broadcasting is where Turbo Streams earn their keep

Among the three Turbo mechanisms, Turbo Streams is the one that most often needs server-side help, and it is the one that requires the least front-end work from a Laravel developer. A Turbo Stream is a snippet of HTML that instructs the browser to append, prepend, replace or remove a piece of the page, and it is delivered over a channel. Laravel already has broadcasting built in, so the work is in the conventions: how a model event becomes a stream, how the stream is rendered as a view, and how the client is subscribed. The package's topic list includes turbo-stream, and the presence of a routes/ directory suggests the package registers endpoints for the stream subscription that Turbo needs. For an application with notifications, live dashboards, comments or collaborative editing, this is the part of Hotwire that a Laravel team would otherwise write by hand, and it is the clearest justification for installing the package rather than adding Turbo's script tags yourself.

The package ships tests, a testbench and a workbench

The repository layout suggests this is maintained as a package in the modern Laravel sense rather than a loose set of helpers. There is a phpunit.xml.dist for the test configuration, a psalm.xml.dist for static analysis, a rector.php for automated refactoring, and a .php-cs-fixer.dist.php for code style. The testbench.yaml file is the piece that tells you the most, because a testbench is how a Laravel package provides an application skeleton to run its own tests against, and the presence of one means the package is exercised inside a real Laravel application rather than against mocks. There is a tests/ directory and a workbench/ directory, the latter being the newer Laravel convention for a sandbox application you can boot to try the package by hand. docs/ sits in the repository as well as on the website, so the documentation is versioned with the code. That combination of tooling is a reasonable signal about how the package is developed, though it says nothing about whether the conventions suit your project.

Install from Composer, then read the guide rather than the README

The published README does not contain a composer require command, so rather than guess at one, the honest starting point is the documentation. The package is published on Packagist as hotwired-laravel/turbo-laravel, which is linked from the README for the latest stable version, and the full documentation sits on the website at turbo-laravel.com. The documentation also points to a Bootcamp, described as a more hands-on introduction that covers building a multi-platform app in Turbo. That Bootcamp is the better onboarding route for a team, because the conventions only make sense once you have seen them applied across a real application rather than as isolated API entries. The README itself is short by design: it states the intent, names the inspiration, links the documentation site, the Bootcamp, the changelog and the contributing guide, and lists the credits. The CHANGELOG.md is the other file worth opening before you start, because a package in the 2.x line will have accumulated behaviour changes.

MIT licensed, maintained by one person with a community behind it

The licence is the MIT License, with the licence file in the repository root. That is as permissive as it gets, which suits a package whose value is in conventions rather than in a licence barrier. The credits name Tony Messias as the author, along with all contributors, and there is a CONTRIBUTORS.md file in the repository. The security policy is also personal rather than institutional: the project asks that security vulnerabilities be reported by email to [email protected] rather than through a public issue. For a package that ends up sitting in the request path of a Laravel application, that is a reasonable reporting channel, and it is the sort of detail worth knowing before you depend on it. The repository is not archived and the last push was on 2026-05-25, and the default branch is 2.x rather than main, which matches the current major line and tells you where ongoing work happens.

A 2.x line with three releases in the last few months

The release history gives the cadence. Version 2.5.0 came on 2025-11-09, 2.5.1 on 2026-01-30 and 2.6.0 on 2026-02-28, so the line has been moving at roughly a release every one to two months, with a patch release following the 2.5.0 feature release. The most recent listed release, 2.6.0, is from 2026-02-28, while the last push to the repository was on 2026-05-25, so there is work on the branch that post-dates the newest tag. That gap is normal for a package with a 2.x branch, and it is also a reason to read the CHANGELOG rather than assume the newest tag contains everything. A minor version bump inside a 2.x line in a package of this kind can change conventions, which is a behaviour change for your application rather than a bug fix, so a minor upgrade deserves the same reading as a major one. The presence of a hacktoberfest topic tag also suggests the project takes outside contributions during October, which is another reason the changelog will be active around that period.

Editorial conclusion

Adopt turbo-laravel if your Laravel team wants server-rendered pages with Hotwire behaviour and is willing to work in the Turbo model, where the server owns the HTML and the browser only enhances it. Do not adopt it as a substitute for a client-side framework, because the package's whole value is in the server-side conventions, and do not expect the README to answer your questions, since the documentation lives on turbo-laravel.com and in the Bootcamp guide. Before you commit, read the CHANGELOG.md for the 2.x line, check the routes/ and config/ directories in the repository for the conventions you would be inheriting, and pin the exact version, since the last push was on 2026-05-25 and the 2.6.0 release is from 2026-02-28.

Frequently asked questions

Official sources

1. hotwired-laravel/turbo-laravel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases