Backpack PermissionManager, a Backpack admin UI over spatie/laravel-permission

A user interface for someone else's permission package

Backpack PermissionManager is described as an admin interface for spatie/laravel-permission, and it allows admins to add, edit and remove users, roles and permissions, using Laravel Backpack.

The README is clear about the division of labour. This package is just a user interface for spatie/laravel-permission. It installs it, and lets you use its API in code, and the README points you at that package's own README for how to use it in code. If you are evaluating PermissionManager, you are really evaluating whether you want the Spatie model plus a Backpack front end for it.

Two behaviours distinguish it from other packages, and the README lists them explicitly. A user can have multiple roles, and a user can have extra permissions in addition to the permissions on the roles they have. The second one matters more than it sounds, because it means a direct permission grant is not overwritten when the role assignment changes.

The repository itself is small. At the root there are composer.json, src/, a CHANGELOG.md, a CONTRIBUTING.md, a LICENSE.md, an .editorconfig and a .scrutinizer.yml. All the application code lives in src/, which is what you would expect from a package that consists of a set of Backpack controllers and configuration rather than a domain layer of its own.

Installation assumes Backpack is already there

The install section is explicit that this package assumes you have already installed Backpack for Laravel, and links to that install guide if you have not.

Then the package itself is a single Composer require:

composer require backpack/permissionmanager

After that, the Spatie package's own installation steps have to be finished, since it has been pulled as a dependency. The README says to run its migrations, publish its config files, and shows the likely commands, which vendor-publish the permission migrations and the permission config, migrate, and then add the HasRoles trait to your User model.

Then you publish the package's own config and migrations, which the README recommends doing in preference to publishing the language files and the routes, and run the migrations again.

The last setup step is the one that decides how the panel behaves. The package assumes it is fine to use the default Backpack user model, most likely App\Models\User, and you can use a different one by changing the user model in `config/backpack/permissionmanager.php`. Whichever model you use has to carry the CrudTrait and the HasRoles traits, and the README shows the model class with both traits in place.

The guard mismatch that breaks @can inside Backpack

This is the part of the documentation that deserves attention, because the failure is quiet.

The optional step 7 exists so you can use the @can handler inside Backpack routes, and the README explains why it is needed. spatie/laravel-permission uses the Auth facade for determining permissions with @can, and the Auth facade uses the default guard defined in config/auth.php, not Backpack's guard.

There are two ways to fix it, and the README gives both. Either change Backpack to use the default web guard instead of its own, by setting the guard option to null in config/backpack/base.php, or add a middleware class to all your Backpack routes so the guard used is Backpack's own.

The consequences differ, and the README spells them out. With the middleware route, auth() returns the same thing as backpack_auth() on Backpack routes. You only need this if you want to use @can, since the alternative is `@if(backpack_user()->can('read'))`, which does the same thing but works 100% of the time. And when you add new roles and permissions, the guard stored in the database differs between the two approaches, web with the first and backpack with the second.

That last difference is the subtle trap. A permissions table populated under one guard configuration and then checked under another will not match, and the symptom is an admin who appears to have roles but cannot use them.

Locking down role and permission editing once the names are in code

Step 8 of the install is optional and easy to overlook, but it protects something that is easy to break.

You can disallow create and update on your roles or permissions after you define them, using the config file at config/backpack/permissionmanager.php. The reason given is that permissions and roles are referenced in code using their name, so if admins are allowed to edit those strings and they do, your permission and role checks stop working.

That is a real coupling between the admin panel and the codebase, and it is worth stating plainly for anyone adopting this. The names in the permissions table are string literals in your controllers, your policies and your Blade templates, and the panel gives an administrator a text field that can rename them. With the config option set, the panel stops offering that.

The menu item step, also optional, adds the three screens to the Backpack navigation. You add a menu dropdown in resources/views/vendor/backpack/ui/inc/menu_items.blade.php with entries linking to backpack_url('user'), backpack_url('role') and backpack_url('permission'), which shows the three CRUD screens the package provides.

Swapping the user controller and using the API from code

If you want extra fields on the user screen, the package lets you bind your own controller in a service provider, in AppServiceProvider for example, so that when the UserCrudController is requested your own controller is served instead of the package one. The README shows the bind call with the package controller and your own controller as arguments.

The API usage section is short, because the API belongs to Spatie. A permission can be given to a user with backpack_user()->givePermissionTo('edit articles'), revoked with revokePermissionTo, and there is a call to test whether the user has a permission. The recommendation is to refer to the Spatie README for the complete API.

One point is worth flagging for anyone writing code against this. The calls shown go through backpack_user() rather than the standard auth() helper, and the guard discussion in the earlier section explains why those two are not always the same object. If your application code checks permissions outside of a Backpack route, the guard that Spatie resolves there is the default one, not Backpack's.

The package also asks you to subscribe to the Backpack newsletter, saying it sends an email every one to two months, so that you hear about security updates, breaking changes and major features. For a package that sits in front of your access control, that is the channel to watch, and the README's own wording puts security updates first in the list.

Editorial conclusion

Adopt Backpack PermissionManager if you run Laravel Backpack and use spatie/laravel-permission, because it saves you writing the user, role and permission CRUD screens yourself, and it inherits the whole API of the underlying package. Do not adopt it as a standalone permission system, since it is explicitly a user interface for spatie/laravel-permission, and do not adopt it without reading the guard configuration section, because Backpack uses its own auth guard while the Spatie package reads the default one. Before you install, decide whether you want the @can handler inside Backpack views, since that determines whether you change the guard or add middleware, and note the release picture, with 7.3.1 published on 2026-01-07 and the last push on 2026-07-31.

Frequently asked questions

Official sources

1. Issues
2. Laravel-Backpack/PermissionManager on GitHub
3. Project website
4. README
5. Releases