Weave Code
Laravel Governor Laravel Package
genealabs/laravel-governor
Laravel Governor adds flexible role- and permission-based authorization to Laravel apps. Define roles and abilities, assign them to users, and protect routes and views with middleware and Blade helpers for simpler access control.
Managing policy and control in Laravel.
Frequently asked questions about Laravel Governor
- How do I install genealabs/laravel-governor in a Laravel app?
- Require the package with Composer, then publish its config and migrations and run them against your database. Add the package's roles trait to your Eloquent user model, seed a baseline role and ability matrix, and register the middleware. Optionally wire a Gate::before hook for a super-admin bypass and either enable the bundled admin dashboard or build a custom management screen. A realistic first integration in a mid-sized app is roughly 3 to 5 engineer-days.
- Which Laravel and PHP versions does Laravel Governor support?
- Version 0.22.0 adds Laravel 13 support via PR #101 with no announced deprecations or removals, but the real support window is whatever Laravel majors the maintainer tests in CI. Because this is a 0.x package, a minor bump can widen or raise the illuminate/* and php constraints, silently dropping older versions. Check composer.json at the tagged commit to confirm exactly which Laravel and PHP versions are still in the supported set, and verify that Laravel 13 is GA rather than pre-release before planning an upgrade.
- How is Laravel Governor different from spatie/laravel-permission?
- Laravel Governor is designed around Laravel's native Gate and policy system rather than replacing it. You keep defining abilities with standard Laravel policies, then assign those abilities to roles and users through Eloquent-backed models and a bundled management dashboard. That makes it a fit when a non-engineer, such as a customer admin or support team, needs to edit the permission matrix at runtime.
- Does Laravel Governor work with existing Laravel policies and Gate checks?
- Yes. It plugs directly into Laravel's Gate and authorization policies, so your existing policy classes and ability definitions stay where they are and the package layers role and permission assignments on top. It works alongside your existing authorization code rather than requiring a rewrite. A common pattern is a Gate::before hook so super-admins bypass role checks entirely.
- Can I protect routes and Blade views with Laravel Governor middleware and helpers?
- Yes. The package ships middleware for route protection and Blade helpers for conditional rendering in views, so you can gate controllers and UI elements without writing custom checks at every call site. Register the middleware in your HTTP kernel or route groups after publishing the config. Keep in mind that view-level helpers are a convenience, not a security boundary, so enforce the real checks in middleware, policies, or form requests.
- How does Laravel Governor handle permission caching across multiple servers?
- Permission caching is both the performance mechanism and the primary correctness hazard in this package, and it assumes a shared cache store across your nodes. A missed invalidation in a multi-node deployment can produce a privilege-escalation or lockout bug that is hard to reproduce and expensive to diagnose. Ask the maintainer for the documented invalidation strategy, and confirm what happens on a cache or lookup miss so the system fails closed rather than permitting access.
- Is the bundled Laravel Governor admin dashboard safe to enable in production?
- Any bundled management screen is an admin-privileged attack surface, so treat it as low-to-medium risk you must actively manage. Restrict it behind strong authentication and network controls, audit access to it, or disable it entirely in favor of a custom screen scoped to your own authorization rules. Do not expose it on a public route without additional protection.
- Is it safe to use a 0.x package like Laravel Governor for authorization in production?
- Treat it as a low-traction dependency rather than an emerging standard. It is a single-maintainer package on a security-critical path with around 200 stars and zero dependents, meaning little downstream production validation, and the repository URL does not cleanly match the maintainer namespace. Because it is pre-1.0 semver, pin the exact version and treat every bump as a potential migration with a full regression pass. Also confirm there is a SECURITY.md with a private disclosure channel and a stated response SLA.
- How should I test role and permission authorization with Laravel Governor?
- Budget 2 to 3 engineer-days for an authorization test harness and CI coverage on top of the initial integration. Cover the full role-ability matrix, the super-admin bypass, middleware and Blade helper behavior, and the deny path on a lookup or cache miss. Also test cache invalidation behavior, since that is where correctness bugs in this kind of RBAC layer usually surface. Run these tests on every framework upgrade, because the package's support window is tied to whatever majors its CI covers.
- When is Laravel Governor the wrong choice for authorization?
- It is the wrong shape when your access model is genuinely policy- or attribute-shaped, such as row-level conditional rules or decisions driven by time and request context. Layering runtime roles on top of that creates two sources of truth and a class of bugs where the Gate says yes and the package says no. It is also a poor fit if you do not use Eloquent user models, a relational database with migrations, and a shared cache store, since the package assumes all three.
Weaver
How can I help you explore Laravel packages today?