Tyro, a Sanctum based RBAC package with over forty Artisan commands attached

Roles, privileges and a superuser seeded by the installer

Tyro is described as a complete authentication, roles and privileges package for Laravel 12 and 13, a modern RBAC and ACL solution built on Laravel Sanctum. The design has two levels. A role is a named grouping such as admin or editor, and a privilege is a granular action such as reports.run or billing.view, and privileges are attached to roles, which are attached to users.

The install command is a single step, and it does the setup work for you:

composer require hasinhayder/tyro
php artisan tyro:install

The README explains that tyro:install sets up Sanctum, prepares your User model, runs migrations, and seeds the default roles and privileges, including a ready-to-use [email protected] superuser with the password tyro. That is convenient and it is also a credential you must change before the application is exposed to anyone.

The requirements are narrow and worth checking before you start: PHP 8.2 or later, Laravel 12 or 13, and Laravel Sanctum 4 or later. There is a separate command, php artisan tyro:postman, that opens the official Postman collection, and the collection is also committed to the repository as Tyro.postman_collection.json, so the API surface can be explored without running anything.

Checking access with six methods and a set of boolean shortcuts

The checking API is the core of the package and it is deliberately layered. A user object exposes hasRole for a single role, hasRoles which requires all of the listed roles, and hasAnyRole which requires any of them. Privileges work the same way with hasPrivilege and hasPrivileges. Then there is can, which is the one to reach for, because it checks a privilege, a role, or a Laravel Gate in that order of meaning:

$user->hasRole('admin');                                // check single role
$user->hasRoles(['admin', 'editor']);                  // must have ALL roles
$user->hasAnyRole(['admin', 'editor']);                // must have ANY role
$user->hasPrivilege('reports.run');                     // check single privilege
$user->hasPrivileges(['reports.run', 'billing.view']); // must have ALL privileges
$user->can('reports.run');                             // check privilege, role, or Laravel Gate

The trait HasTyroRoles adds convenience on top of that. There are quick boolean checks for the built-in roles, isAdmin, isSuperAdmin, isEditor, isCustomer and isUser, and inspection helpers such as hasNoRoles, rolesCount, which counts assigned distinct roles while excluding the super-admin wildcard, and privileges, which returns an Eloquent collection of all unique user privileges.

Writing the helper into a trait rather than a base User model is the right call for adoption, since it means you can attach the package to an existing model without restructuring your application.

Route middleware for both roles and privileges

Tyro registers middleware aliases that you use in route definitions, and there are five of them out of the box:

The role:admin alias requires one specific role, while roles:admin,editor passes for any of the comma-separated roles. Privileges follow the same pattern, with privilege:reports.run for a single privilege and privileges:reports.run,billing.view for any of the comma-separated ones. The fifth alias, tyro.log, logs API requests into Tyro's audit trail.

The distinction between the singular and plural aliases is the interesting part. role:admin requires one specific role, while roles:admin,editor passes for either of them, and the same pairing applies to privileges. That means a route can demand one exact capability or one of several, and reading a route definition tells you which rule applies without a lookup.

The aliases compose with Sanctum authentication in the usual way:

Route::middleware(['auth:sanctum', 'role:admin'])->get('/admin', AdminController::class);
Route::middleware(['auth:sanctum', 'roles:admin,editor'])->get('/dashboard', DashboardController::class);
Route::middleware(['auth:sanctum', 'privilege:reports.run'])->get('/reports', ReportsController::class);
Route::middleware(['auth:sanctum', 'privileges:reports.run,billing.view'])->get('/finance', FinanceController::class);

The tyro.log alias is the one that ties the middleware layer to the audit trail, since it records API requests into the same history the CLI can review.

Suspension that revokes tokens, and an audit trail you can purge

Two features carry most of the operational weight in a real application, and Tyro treats both as first class.

User suspension freezes an account instantly, with an optional reason, and all active tokens are revoked automatically. Users can be restored at any time, and the state is inspectable:

$user->suspend('Pending account review');  // instantly revokes all tokens
$user->isSuspended();                      // true/false
$user->getSuspensionReason();
$user->unsuspend();

Revoking tokens on suspension is the detail that makes the feature useful rather than cosmetic. A suspended account that keeps a valid Sanctum token is not suspended, and the README's security section pairs this with token abilities mirroring roles and privileges, so an API token cannot carry more authority than the user behind it.

The audit trail records every role and privilege assignment, every user suspension and every admin action, and the CLI includes commands to review the history and to purge it. That purge command is worth thinking about before you turn it on, because it means the history is deliberately disposable, and a compliance requirement that demands retained records should be checked against that.

Forty Artisan commands and the REST endpoints behind them

The package's distinguishing feature is the command line surface. The README advertises 40+ Artisan commands covering users, roles, privileges, tokens, suspensions and audit logs, and describes them as suited to automation and CI/CD. That framing matters: a permission model managed only through a web UI needs a running application and a logged-in administrator, while a permission model managed through Artisan can be provisioned from a deploy script.

The same operations are also available over HTTP, since the package ships REST endpoints for auth, user, role and privilege management, plus the Postman collection. The repository layout supports that split: routes/ holds the route definitions, src/ the implementation, config/ the configuration, database/ the migrations and factories, resources/ the views, and tests/ the test suite.

The zero lock-in claim in the README is concrete rather than rhetorical. You can publish the config, migrations and factories, and you can disable the API routes or the CLI commands per environment, which is how you would keep the REST surface out of production while keeping the command line tooling for deploys. The presence of config/ in the tree and the ability to publish those files is what makes that possible.

MIT licensed, tested in CI, and moving faster than its release tags

The licence is MIT, in a LICENSE file at the root, which is about as permissive as it gets for a package you intend to build on. The package is on Packagist as hasinhayder/tyro, with a download badge and a documentation badge pointing at the project site, which hosts the full documentation as a single page.

The development signals in the tree are conventional and healthy. There is a CHANGELOG.md, a CONTRIBUTING.md, a phpunit.xml for the test suite, a pint.json for code style, and a .github directory with a tests workflow whose status badge is in the README. The skills/ directory at the root is an unusual entry, and it suggests the project ships guidance for coding agents alongside the PHP.

The maintenance picture is where the one caveat sits. The repository has no GitHub releases at all, so the version history is in the CHANGELOG and on Packagist rather than in tagged releases. The last push to the main branch was on 2026-08-15, which is recent enough to show the work is ongoing, but the absence of release tags means you should pin your Composer constraint to a specific version and read the changelog before upgrading, because there is no tag to diff against.

The other thing worth settling early is the seeded superuser. [email protected] with the password tyro is convenient for a local environment and indefensible in production, and the installer will happily create it in any environment you run tyro:install in.

Editorial conclusion

Adopt Tyro if you run Laravel 12 or 13 with Sanctum and need an authorization layer that is manageable from the CLI and from REST endpoints, since the package gives you roles, granular privileges, middleware, suspension and an audit trail without writing them. Do not adopt it if you are on Laravel 11 or below, since the package requires Laravel 12 or 13 with PHP 8.2 and Sanctum 4, and do not adopt it if your team needs policy-level per-model authorization that Laravel Gates already cover better. Before you deploy, change the seeded [email protected] account with the password tyro, decide which parts you publish, since the package lets you disable API routes or CLI commands per environment, confirm the audit trail retention policy against your own compliance needs, and note the last push was on 2026-08-15 with no GitHub releases, so pin your Composer constraint deliberately.

Frequently asked questions

Official sources

1. hasinhayder/tyro on GitHub
2. Issues
3. License: MIT
4. Project website
5. README