- What is Tyro and how is it different from other Laravel role and permission packages?
- Tyro is a role-based access control and ACL package for Laravel 12 and 13, built on top of Laravel Sanctum and shipped with an Artisan CLI that manages roles, permissions, and privileges for you. Unlike a simple HasRoles trait, it separates roles, permissions, and system-level privileges, and adds suspensions, inheritance, and multi-tenancy support. That makes it a better fit for teams outgrowing ad-hoc Gate and Policy sprawl than for small apps that only need a single role column.
- Which Laravel versions does Tyro support?
- Tyro targets Laravel 12 and 13 only, and it assumes Laravel Sanctum for authentication. That is ahead of the wider ecosystem, which is great if you upgrade aggressively but a real constraint for teams still on Laravel 10 or 11. Check the package's composer.json before planning an upgrade, since support for older versions is not advertised.
- How do I install Tyro in a Laravel application?
- Install it with Composer using hasinhayder/tyro, then run the package's install command to publish its config, migrations, and seeders. You need a Laravel 12 or 13 app with Sanctum already configured, because Tyro consumes the authenticated user rather than issuing tokens itself. After migrating, use the Tyro CLI to create roles and permissions instead of hand-editing database rows.
- How do I protect routes with Tyro middleware?
- Tyro registers middleware that lets you gate routes by role or privilege, so you can attach it to route groups and individual routes just like Laravel's built-in auth or can middleware. Because the package builds on Sanctum, the authenticated user must already be resolved by Sanctum's guard before the check runs. That separation keeps authorization distinct from token issuance and avoids maintaining a parallel auth stack.
- How do I check roles and permissions in Blade templates with Tyro?
- Tyro ships Blade directives for conditionally rendering UI based on the current user's roles or privileges, so navigation items, buttons, and admin panels can be hidden without writing if blocks around Gate calls. The directives read from the same resolution layer as the middleware, which keeps them consistent with server-side enforcement. Always keep the middleware check in place as well, since hiding a link is not authorization.
- How does Tyro cache roles and privileges, and how do I avoid stale permissions after a role change?
- Tyro caches each user's roles and privileges under keys such as tyro:user-{userId}:roles so repeated authorization checks do not hit the database on every request. That cache is correctness-critical: a stale entry after a role change becomes either a silent privilege escalation or a bogus access denial. Audit every code path that mutates roles or permissions, including admin UIs, support tooling, and direct database writes, and confirm a cache flush happens on each one.
- Does Tyro support multi-tenancy and tenant-scoped permissions?
- Tyro offers tenant-scoped permissions, but tenant isolation bugs are catastrophic and rarely surface in local development. Treat cross-tenant permission leakage as a dedicated test class rather than a manual QA item, and cover the cache layer too, since tenant-scoped entries can leak if keys are not tenant-aware. If you add custom resolvers or drivers, review them against the same isolation invariants.
- Can I customize Tyro's table names, model classes, or drivers?
- Tyro lets you override table names, model classes, drivers, resolvers, and service providers through configuration, which is the clearest sign it was designed for substitution rather than forking. Use these extension points when you need to work with an existing users table or a custom permission source. Be aware that Tyro still enforces its own naming conventions for cache keys, audit events, and Artisan commands, so bending it to an existing convention set will be a fight.
- How do I test Tyro roles and permissions in my Laravel test suite?
- Because roles and permissions resolve through Sanctum's authenticated user, your existing feature tests can assign a role, act as that user, and assert the route response or Blade output. Clear Tyro's authorization cache between tests so a role granted in one test cannot leak into the next. Run your suite against the same cache driver you use in production, since a mismatch can hide invalidation bugs.
- Is Tyro production-ready, and what risks should I evaluate first?
- Treat it as usable but evaluate it seriously before committing. The package is maintained by a single author with a few hundred GitHub stars, so bus factor and release cadence are the dominant risks, and there is no published long-term versioning commitment beyond the repository docs. Verify audit-log immutability yourself, because a table with UPDATE and DELETE grants is not an audit log. Before rollout, add explicit tests for cache invalidation, privilege escalation, and tenant isolation.