- Is rappasoft/vault still maintained?
- No. The repository is archived, so there are no security patches, no new releases, and no maintainer accountable for fixes. For an authorization package, that is a standing audit finding rather than a minor inconvenience. Treat it as legacy code only.
- Which Laravel and PHP versions does rappasoft/vault support?
- It is a Laravel 5-era package built for PHP 7.0 through 7.1. Its Composer constraints will almost certainly reject Laravel 6+ and PHP 7.3+, so verify the exact illuminate/* and php requirements in composer.json before planning anything. Do not assume compatibility will be tested late and work out.
- Can I use rappasoft/vault with Laravel 10, 11, or 12?
- No, not as a normal Composer adoption. Making it work on a current Laravel release is effectively a fork-and-rewrite exercise because middleware registration, auth guard resolution, and Blade compilation have changed materially since Laravel 5.x. Use an actively maintained authorization package instead.
- How do I install rappasoft/vault in a Laravel 5 application?
- The package follows the conventional Laravel 5 flow: require it via Composer, register its service provider, publish and run the migrations for roles, permissions, and pivot tables, and apply the VaultUser trait to your User model. You then use its middleware and Blade directives for role and permission checks. This is only viable for a legacy Laravel 5.x app on PHP 7.0-7.1.
- How do I check roles and permissions with rappasoft/vault?
- Vault exposes role and permission checks through the VaultUser trait, route middleware, and Blade directives such as role and permission checks. To limit coupling, define Laravel Gate::define calls or Policy classes as the single authorization entry point and delegate to Vault inside them. Then call $this->authorize(...) in controllers and use @can in views instead of Vault-specific directives.
- Does rappasoft/vault support multiple guards or multi-tenancy?
- No, not out of the box. Vault has no multi-guard or multi-tenant awareness, and its guard handling predates mature multi-auth patterns; the schema is a flat role-to-permission model that cannot express teams or per-resource scoping by itself. If you need admin, customer, and API authorization separated, expect custom work or a fork.
- Is rappasoft/vault safe for production?
- It is risky for any new production work. The repository is archived, the authorization layer gets no security patches, and Laravel 5.x with PHP 7.0/7.1 is end-of-life, so you would stack three unsupported layers. It is only defensible in a contained legacy app with a named internal fork owner and a clear migration plan.
- What are the best alternatives to rappasoft/vault?
- Use spatie/laravel-permission as the baseline for ordinary roles and permissions; it is actively maintained, conceptually similar, and widely supported. Choose JosephSilber/bouncer if you need resource-scoped abilities rather than flat role-to-permission checks. Both avoid the archived and end-of-life risk of Vault.
- How do I migrate from rappasoft/vault to spatie/laravel-permission?
- Vault's schema is close enough to spatie's that the data migration is mechanical: roles, permissions, and the two pivot tables map across. The real work is at the authorization call sites, so first define Gate::define calls or Policies as a package-agnostic entry point and replace Vault middleware and Blade directives with authorize and @can. Then move the data and remove Vault.
- How should I test authorization in a legacy app that uses rappasoft/vault?
- Test through Laravel's authorization layer, not through Vault directly. Wrap Vault checks in Gates or Policies, use factories to create users with known roles and permissions, and assert HTTP responses and Gate decisions with actingAs and Laravel's authorization assertions. That keeps tests package-agnostic and makes a later migration to spatie/laravel-permission much less painful.