Spatie Laravel Permission puts roles in the database and checks on the gate

Permissions live in the database and land on the gate

The package stores roles and permissions in your application's database, then registers every permission on Laravel's gate. Two ways of attaching them to a user are enough to show the whole model:

// Adding permissions to a user
$user->givePermissionTo('edit articles');

// Adding permissions via a role
$user->assignRole('writer');

$role->givePermissionTo('edit articles');

A permission can sit on a user directly or arrive through a role, and a role collects permissions in turn, so `edit articles` can belong to one person and to everyone holding the writer role at the same time. Nothing in that example is scoped, versioned or time-bound. The strings are the identifiers, and `givePermissionTo` and `assignRole` are the calls your application makes.

can() is the entire read side

Checking is not a separate API. Because every permission is registered on the gate, a check is the framework's own call:

$user->can('edit articles');

That choice cuts both ways. In your favour, a permission check is indistinguishable from any other gate check, so existing `can` calls, policies and middleware keep working and you are not learning a second authorization vocabulary. Against you, the README documents nothing beyond that one call: no listing helper, no way to ask for every permission a user holds, no wildcard syntax. An administration screen listing roles, or a check against a permission that may not exist yet, is code you write against the models yourself.

The README names no column, no migration, no config key

Everything about storage sits outside the README. It lists no table name, no column, no migration and not one config key, and the repository root has `config/` and `database/` directories whose contents it never mentions. That leaves the questions a team asks first unanswered at the source: where the pivot records go, what happens when a user record is deleted, whether an existing users table can be pointed at.

The tooling around them is visible even so. `phpstan.neon.dist` and `phpstan-baseline.neon`, `phpunit.xml.dist` and `pint.json` sit at the root, next to `src/`, `resources/`, `docs/` and `tests/`. Static analysis, a test runner and a code style tool are wired up. The shape of your data is not.

Install and upgrade guidance lives on a company site

The README carries no `composer require` line. Installation and upgrade instructions are delegated to the documentation at spatie.be/docs/laravel-permission, and the only command in the whole file is for the tests:

composer test

Two consequences. An upgrade is a documentation-site task rather than a repository one: CHANGELOG.md in the root records what changed, but the upgrade steps themselves are published elsewhere and can move without a commit landing here. And that site belongs to a company that also sells paid products, so the instructions you depend on sit next to the funding page rather than inside the versioned tree you are installing.

Two 8.x releases landed fifteen hours apart

The recent tags are tightly packed. Version 8.3.0 was published on 2026-07-03 at 15:37, then 8.3.1 and 8.3.2 on 2026-10-19 at 12:22 and 16:31. The last push to the repository was on 2026-10-22 and it is not archived, and the two patch releases landed about four hours apart.

The step for an adopter is to pin the exact version you tested and read CHANGELOG.md before moving to another. Releases landing on one day are where a surprise ships cheaply and disappears into a deploy log, and the README does not tell you which tag a given feature first appeared in.

The alternatives differ on teams, wildcards and archives

The README runs its own comparison, and the differences are concrete. `santigarcor/laratrust` implements team support. `zizaco/entrust` offers wildcard pattern matching, so one permission string can stand in for a family of checks. `ultraware/roles` is marked archived and described as taking a slightly different approach, with no detail offered about how. `JosephSilber/bouncer` is called an excellent package in the README's own words, and Povilas Korop compared the two in an article on Laravel News.

Choose by the gap rather than by preference. Teams send you to laratrust, wildcard matching to entrust, and everything else keeps you on this package, reading the docs site for the upgrade steps.

The code descends from a Laravel 5.1 tutorial demo

Credits in the README trace the package to Jeffrey Way's Laracasts lessons on permissions and roles and point at the original demo code in the laracasts/laravel-5-roles-and-permissions-demo repository. Alex Vanderbist is thanked for his help with v2, Chris Brown and Freek Van der Herten carry the maintenance credit, and the logo is by Caneco.

That lineage explains the documentation shape. The API shown in the README is still three calls and a `can` check, while the package sits at version 8. Decisions made along the way, model names, schema changes, framework upgrades, accumulated in the CHANGELOG and on the docs site. A package carried since the Laravel 5.1 era keeps a long memory of older framework versions, and the upgrade notes rather than the README are where you will find it.

MIT, with a postcard request attached

The license is MIT. Alongside it, the README asks anyone whose production environment runs the package to send a postcard from their hometown, gives a street address in Antwerp, and links to a wall where received postcards are published. The same file asks readers to consider buying one of Spatie's paid products.

Neither request changes what the MIT license permits, and neither is a service commitment. What the file does describe is where support comes from: a commercial operation funding open source this way, security issues handled by email at [email protected] instead of the issue tracker, and general questions deferred to a contribution guide on GitHub. The package is free, and no response time is promised anywhere in it.

Editorial conclusion

Adopt spatie/laravel-permission when your Laravel application already keeps users in a database and you want permission checks to run through Laravel's gate instead of a second authorization system. If team support or wildcard matching is what you are shopping for, the README names laratrust and entrust as alternatives offering them. Verify first: pin one 8.x tag and read CHANGELOG.md, because 8.3.1 and 8.3.2 were published about four hours apart on 2026-10-19.

Frequently asked questions

Official sources

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