- How do I install and set up Bouncer in Laravel?
- Install it with Composer using composer require silber/bouncer, publish and run the package migrations, then add the HasRolesAndAbilities trait to your User model. After that you seed abilities and roles and assign them with Bouncer::allow(), Bouncer::assign(), and related calls. No external services, queues, or daemons are required, and existing Gate checks keep working throughout the rollout.
- Does Bouncer support multi-tenancy and scoped roles?
- Yes. Bouncer ships scope support through Bouncer::scope(), onceTo(), and removeOnce(), so permission sets can stay isolated per tenant. The v1.0.1 release fixed scoped grants leaking into the global scope, which is the key correctness milestone for tenant-isolated products. Make sure you are on a version that includes that fix before relying on scoping in production.
- Which Laravel versions does silber/bouncer support?
- Since v1.0.2 the package requires Laravel 11 or newer; v1.0.3 added Laravel 12 and v1.0.4 added Laravel 13. Each Laravel major upgrade therefore becomes a two-step process: upgrade Laravel, then verify a matching Bouncer release. Pin an exact or tilde constraint rather than a floating one, since tag metadata has needed corrections before.
- How does Bouncer interact with Laravel gates and policies?
- Bouncer sits on top of Laravel's native Gate and Policy system rather than replacing it. As of v1.0.0 the default behavior runs Bouncer checks after your policies and gates, so code-defined rules take precedence and Bouncer only fills the gap when a policy returns null. That makes the package additive and lets ownership-style rules such as edit own post versus any post coexist with policy business logic.
- How do I cache Bouncer roles and abilities, and when do I need Bouncer::refresh()?
- Bouncer caches roles and the clipboard, and cross-request caching requires an explicit Bouncer::refresh() after permission changes and after package upgrades. On multi-server deployments you must invalidate a shared cache, or revoked permissions stay live until the TTL expires. Cache invalidation is the most common failure mode, so treat it as part of your deploy and change-management process.
- Can I use Bouncer with a custom role model or an existing roles table?
- Yes, custom role models and custom table names are supported, which helps when you already have a legacy roles table. Note that custom models are auto-registered with the morph map, which historically required a data migration for the entity_type column in v1.0.0-rc.5. Map any pre-existing permission tables deliberately rather than assuming they line up.
- How do I check roles and abilities in Blade templates and middleware?
- Bouncer integrates with gates, middleware, and Blade directives, so you can check access in controllers, routes, and views without duplicating logic. Because checks are cached, calls stay cheap on hot paths. Keep real enforcement on the server side; Blade directives are for presentation, not the security boundary.
- Is Bouncer safe to use in production, and what are the security risks?
- It is MIT-licensed, Composer-installable, has no external dependencies, and has a clean test suite, so the technical risk is manageable. The real risks are operational: this is your enforcement point for access control, so a scope leak, stale cache, or forbid/disallow mistake is a data-exposure incident rather than a bug ticket. There is no admin UI or audit trail, so role management screens, change history, and approval flows are yours to build for SOC 2 or ISO-style controls.
- How do I test authorization with Bouncer in my test suite?
- Bouncer's own suite is rebuilt on PHPUnit 11 with Laravel Workbench, and you can follow the same pattern in your application. Seed abilities and roles in test setup, assign them to users, and assert on gate checks rather than on raw database rows. Call Bouncer::refresh() where tests change permissions mid-run and rely on the cache, and reset the scope between tenant-specific tests.
- What alternatives to Bouncer exist for Laravel roles and permissions?
- Plain Laravel Gates and Policies are cheaper and clearer when your permission surface is small and shaped in code. Bouncer is the better fit when roles and abilities change at runtime, such as admin-configurable roles, plan-tier entitlements, or per-tenant permission sets. Other packages exist in this space, but Bouncer's main differentiator is that it layers onto native gates rather than replacing them, which keeps migration risk low.