Sentinel pairs a version matrix with schema migrations and a security inbox

The version matrix is the adoption document

The first thing in the README is a table mapping Sentinel major versions to Laravel and PHP versions, and it is the single most useful thing in the file.

Sentinel 10.x targets Laravel 13.0 on PHP 8.3 or newer. 9.x targets Laravel 12.0 on PHP 8.3. 8.x targets Laravel 11.0 on PHP 8.2. 7.x targets Laravel 10.0 on PHP 8.1. 6.x targets Laravel 9.0 on PHP 8.0. 5.x targets Laravel 8.0 on PHP 7.3. 4.x targets Laravel 7.0 on PHP 7.2.5. 3.x targets Laravel 6.0 on PHP 7.2, and 2.x and 1.x target Laravel 5.0 and 4.1 to 5.0 respectively, both on PHP 5.4.

Two things follow. The current line tracks the current generation of both frameworks, so using Sentinel does not mean living on an abandoned stack. And the matrix implies a coupling you should confirm before committing: each major line is stated against one Laravel version, so a Sentinel major upgrade is not independent of a Laravel upgrade. If you are planning to jump two Laravel majors, plan two Sentinel majors.

The default branch is `10.x`, which matches the top row of the table. That is a small signal about where the work is going.

The package declares itself framework agnostic and the PHP floor of the current line is 8.3. The README says documentation is available from the Cartalyst manual, which is where the framework-specific guidance lives, and it does not publish a compatibility table for non-Laravel frameworks.

What is actually in the package

The README describes Sentinel as a fully-featured authentication and authorization system providing user roles and additional security features, and the repository layout is small enough to read.

The root contains `composer.json`, `phpunit.xml`, a `.php_cs.php` style configuration, `.travis.yml`, a `CHANGELOG.md` and the `LICENSE` file, with `src/`, `tests/` and a `schema/` directory as the substantive parts.

That `schema/` directory is the item worth pausing on. A `schema/` directory next to `src/` is where a package that owns database structure keeps its migrations, which means Sentinel installs tables rather than only validating a model. That is the first design decision to check against your application, because if you already have a users table, the question becomes whether you run the migration, adapt it, or point Sentinel at an existing repository implementation. The README does not describe the schema files, so read them before running any migration against a database that already holds users.

The `tests/` directory with a `phpunit.xml` at the root means the package ships its own test suite, which is worth something when you are inheriting an authentication dependency rather than writing one. A `.travis.yml` and the Travis badge in the README are older signals and should not by themselves establish the current build; the badge URL points at the `10.x` branch.

The README also carries badges for the latest Packagist version and total downloads, both served by a badge endpoint rather than computed locally, and a licence badge whose link target is an MIT URL while the README body says BSD 3-Clause. That mismatch is a badge artefact, and the README body plus the `LICENSE` file are the authoritative statement.

Framework agnostic in the label, Laravel-shaped in practice

It would be fair to read the framework agnostic claim with a caveat, and the caveat is about the ecosystem rather than the code.

The topic list for the repository names Laravel alongside auth, permissions, roles, security and PHP, and every row of the version matrix names a Laravel version. The project is published by Cartalyst, a vendor whose other packages are known within the Laravel community, and the documentation is hosted on a Cartalyst manual rather than in the repository. A package can absolutely be written without framework dependencies and still be, practically, tested and documented against one framework.

The claim is not worthless. Writing your own authentication layer against an ORM and your own user model is exactly the work packages like this exist to remove, and Sentinel's abstraction lets you swap storage and the surrounding framework pieces. The point is narrower than the label: the risk is not that it will refuse to run outside Laravel, it is that the paths you will not find documented are the non-Laravel ones.

A second structural consideration is who owns the user table. If Sentinel ships migrations, it wants to own the schema. Projects that already have users, and most production systems do, will be integrating with something rather than installing it. Plan for that: read the `schema/` directory, decide whether you are running the migration, and only then look at the roles and permissions layer.

Neither the README nor the repository root offers documentation on this, which is exactly the gap that makes reading the manual worthwhile before you choose.

Security reporting and the licensing details

Two operational details matter more in an authentication package than in most.

First, security disclosure. The README asks that any security related issues be emailed to [email protected] rather than filed on the issue tracker, which is the correct practice and a signal that the project treats security reports as a distinct channel. It also means your process should treat that address as the vendor contact for advisories, because an authentication package that ships a vulnerability affects every application using it at once.

Second, licensing. The README states BSD 3-Clause with the LICENSE file in the repository root. That is a permissive licence with a mild requirement: redistributions must retain the copyright notice, the condition clause and the disclaimer. It places no obligation on your own application's code and no network copyleft requirement, so embedding it in a closed-source commercial product is unproblematic as long as the notice travels with the code.

Note again that the README's licence badge links to an MIT licence URL. Read the `LICENSE` file rather than the badge; a discrepancy like this in an auth package is worth resolving from the file itself.

Contribution routes are a contributing guide and a code of conduct under `.github/`, and for usage problems the README asks you to open an issue on GitHub with the promise to address it as soon as possible. For a dependency that handles credentials, that responsiveness matters as much as the code, and it is worth checking the CHANGELOG and recent commits on the `10.x` branch to gauge it before you upgrade.

Where Sentinel is the wrong choice

Four situations argue against it, and two of them are about age rather than design.

The first is Laravel's own auth scaffolding. Choosing Sentinel over the built-in system means owning the parts the framework would have handled, and the justification has to be more than preferring the API.

The second is a project outside Laravel that already has an auth story. The framework agnostic label is real, but the documentation, the tests and the topic focus all sit in Laravel's world. If you are on Symfony or Slim and your team is comfortable writing the user repository, the value Sentinel adds shrinks and the unsupported combinations grow.

The third is a new application on an older Laravel version. The matrix is one line per Laravel major, so a project still on Laravel 10 is on Sentinel 7.x, whose PHP floor is 8.1. That is a working combination, but you are choosing the oldest line the table lists when starting fresh, and the older lines receive proportionally less attention.

The fourth is a compliance-driven project with a strict requirement about where credentials and sessions live. Sentinel is a package, not an audited identity provider, and nothing in the repository indicates an external audit, a published threat model or a security statement page. If your reviewer asks for those, they are not in this repository and you will have to obtain them elsewhere.

The comparison that does hold up is against writing the layer yourself. Sentinel earns its place when roles, permissions, activation, throttling and the upgrade path across major versions are worth more than the freedom of owning those few hundred lines.

Editorial conclusion

Sentinel fits a team on a modern Laravel release that wants role and permission checks without the opinionated user model a full auth package imposes, and the schema directory makes an existing user table a plausible starting point. Do not adopt it for a non-Laravel project on the strength of the framework agnostic label without reading the manual, since the documentation lives on a vendor site and no compatibility table is published for that case. Verify first which major line matches your Laravel and PHP versions, because the matrix shows every line is pinned to exactly one of each.

Frequently asked questions

Official sources

1. cartalyst/sentinel on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases