Forem: Sebastian Cabarcas

laravel-permissions-redis v4.0.0 is now stable

Sebastian Cabarcas — Thu, 14 May 2026 21:31:54 +0000

After three weeks of internal production validation without surfacing new bugs, scabarcas/laravel-permissions-redis ships its first stable 4.x release today. The codebase is identical to v4.0.0-beta.2. What changed is the commitment.

Why "no code changes" is the point

Stable doesn't mean "we added features." Stable means "we stop changing this." For three weeks I ran the beta in my own production workloads, expecting to find something — an edge case, a race condition, a missed invalidation. Nothing surfaced. The Redis contract test suite stayed green, the in-memory test fake matched the real Redis implementation, and the resolver behaved consistently across queue workers, Octane lifecycles, and multi-user-model setups.

When a beta runs long enough to stop producing new bug reports, the right thing is to stop labeling it beta. Three weeks felt like enough.

What you get if you're coming from v3 or earlier

The 4.x line has been collecting features since late March. If you haven't followed the beta releases, the short list:

Permission group metadata in Redis — group names survive the cache layer, so PermissionResolver::getAllPermissions() returns enriched DTOs without falling back to the database.
Multi-user-model support — user_model config accepts an array, Gate::before iterates over every configured type.
Queue-backed warming — WarmUserCacheJob plus --queue flag on warm commands. No more synchronous bulk warming under load.
Guard parameter on every Blade directive — @role('admin', 'api'), @permission('users.read', 'api'), all six directives.
LRU eviction + warm cooldown in the in-memory resolver caches. Long-running workers no longer grow unbounded.
Atomic permission groups + Redis SCAN/HSET fixes — every mutation goes through MULTI/EXEC with consistent rollback semantics.
Migration command from Spatie — php artisan permissions-redis:migrate-from-spatie reads your existing model_has_roles, model_has_permissions, and role_has_permissions tables and warms the equivalent Redis state in one shot.

The full audit-and-fix list is in the CHANGELOG.

Benchmark recap

For new readers — the differentiator stays the same:

Workload	spatie p50	redis p50	Speedup
1 authorization-heavy request	13.76 ms	1.26 ms	10.94x
10 iterations	138.87 ms	13.01 ms	10.68x
50 iterations	696.73 ms	63.79 ms	10.92x

Methodology: 5 warm-up runs + 30 measurement runs per scenario, GC reset between runs, predis client, SQLite + local Redis on Apple Silicon. Reproducible with one Docker command from the benchmark repo.

The 10x is not from a smarter algorithm — it's from doing less work. Spatie hydrates the user-to-roles-to-permissions chain on every request via Eloquent (4 DB queries per authorization-heavy endpoint). This package keeps that chain in Redis SETs and checks membership with SISMEMBER (O(1)). The DB query left is the users lookup itself.

Semver promise from here

Breaking changes will only ship in v5.0.0. The 4.x line gets:

Non-breaking features
Bug fixes
Documentation improvements

Your composer.json constraint ^4.0 is safe to commit. If your test suite passes against v4.0.0, it will keep passing across every 4.x release.

When this package fits

It's not a Spatie replacement for every Laravel app. Use this when:

You make many authorization checks per request (hasPermissionTo, hasRole, Blade directives, Gate::allows)
Redis is already a production dependency (sessions, queues, cache)
The 4 DB queries per request from Spatie's relation hydration show up in your traces
You can absorb the eventual-consistency window of cache invalidation (events trigger rewarming within milliseconds, but it's not strictly synchronous)

Spatie remains the right default for the 95% of apps where authorization isn't on the hot path. Don't switch unless the latency math actually moves your numbers.

Install

composer require scabarcas/laravel-permissions-redis:^4.0

Full README with setup steps · Migrate from Spatie in one command · Benchmark methodology

A Redis-first alternative to spatie/laravel-permission, benchmarked

Sebastian Cabarcas — Tue, 12 May 2026 16:09:23 +0000

TL;DR

I built a Redis-first roles & permissions package for Laravel called scabarcas/laravel-permissions-redis — Spatie-compatible API (hasRole, hasPermissionTo, Blade directives, middleware), but the user→roles→permissions mapping lives in Redis SETs instead of being hydrated from the DB on every request.

Benchmark vs spatie/laravel-permission ^7.2, with 5 warm-up + 30 measurement runs per scenario, GC reset between runs, predis client, SQLite + local Redis on Apple Silicon:

Workload	Spatie p50	Redis p50	Speedup	DB queries reduced
1 authorization-heavy request	13.76 ms	1.26 ms	10.94x	4 → 1 (75%)
10 iterations	138.87 ms	13.01 ms	10.68x	40 → 10 (75%)
50 iterations	696.73 ms	63.79 ms	10.92x	200 → 50 (75%)

The speedup is consistent — Redis lookups are near-constant time; Spatie's per-request relation hydration scales linearly. The whole bench repo is public if you want to reproduce: laravel-permissions-redis-benchmark.

Rest of the post is the why and the when not to use it.

The problem with Spatie isn't the cache — it's relation hydration

If you've used spatie/laravel-permission in a high-traffic app, you've probably noticed that authorization checks cost more than they look. Here's a query log from a single request that calls hasPermissionTo() 27 times, hasRole() 4 times, plus getAllPermissions() and getRoleNames():

-- 1. User lookup
select * from "users" where "users"."id" = 1
-- 2. Roles via pivot
select "roles".*, "model_has_roles"."model_id" as "pivot_model_id", ...
       from "roles" inner join "model_has_roles" on "roles"."id" = "model_has_roles"."role_id"
       where "model_has_roles"."model_id" = 1 and "model_has_roles"."model_type" = 'App\Models\User'
-- 3. Direct permissions via pivot
select "permissions".*, "model_has_permissions"."model_id" as "pivot_model_id", ...
       from "permissions" inner join "model_has_permissions" on "permissions"."id" = "model_has_permissions"."permission_id"
       where "model_has_permissions"."model_id" = 1 and "model_has_permissions"."model_type" = 'App\Models\User'
-- 4. Permissions via roles
select "permissions".*, "role_has_permissions"."role_id" as "pivot_role_id", ...
       from "permissions" inner join "role_has_permissions" on "permissions"."id" = "role_has_permissions"."permission_id"
       where "role_has_permissions"."role_id" in (1, 2)

Four queries. Every request that authorizes anything. Doing 27 permission checks doesn't multiply that — it's still 4 queries, because Spatie loads the user's relations once per User::find() and then runs the membership checks in PHP memory.

But here's the part that surprised me when I first profiled it: Spatie's permission cache doesn't help with those 4 queries. That cache stores the global permission and role registry — "what permissions exist in the system" — using cache.permissions.cache via the Laravel cache facade. The per-user pivot relations (model_has_roles, model_has_permissions, role_has_permissions) are loaded by Eloquent every time you call User::find() followed by a permission check. The global cache only saves you from re-reading the permissions and roles tables themselves.

This is fine for low-traffic apps. It's a tax you stop noticing once you're past the database-side bottleneck.

It's annoying once you start having authorization in every middleware, every gate, every Blade directive on dashboards, every API endpoint.

Why I went Redis-first instead of "Spatie + better cache"

The natural next step is to cache the user's resolved permissions, not just the global registry. You can do that with Spatie by writing a custom decorator that caches getAllPermissions() per user — and people have done this. Two problems show up:

Invalidation gets sharp. When you grant a user a permission, you need to clear that user's cache. When you change a role's permissions, you need to clear every user that has that role. When you delete a permission, you need a broader sweep. Spatie's API is built around forgetCachedPermissions() which nukes everything — fine, but every assignment change forces every active user back into the 4-query path on their next request.
The data structure is wrong for the operation. Even if you cache per-user permissions as a JSON array, checking hasPermissionTo('posts.edit') is an in_array() scan over the deserialized array. Redis SETs do this in O(1) with SISMEMBER. Once you're already in Redis for the data, you might as well use the right operation.

So instead of a Spatie decorator I wrote a separate trait. The wire format in Redis is:

SET  permissions:user:1:permissions   {"posts.view", "posts.edit", "users.view", ...}
SET  permissions:user:1:roles         {"admin", "editor"}
HASH permissions:role:editor          {permissions: ["..."], ...}

hasPermissionTo($perm) becomes SISMEMBER permissions:user:{id}:permissions {$perm}. hasRole($role) is the same against :roles. Wildcard checks (posts.*) use SMEMBERS + fnmatch() in PHP, which is still constant queries.

Cache warm happens on login (or explicitly via AuthorizationCacheManager::warmUser($userId)). After that, every authorization check is a Redis round-trip — no DB queries except the user lookup itself.

The numbers, with methodology

Here's the bench harness in one screen (source):

class BenchmarkRunner
{
    public function execute(int $userId, int $iterations, int $warmUpRuns = 3, int $measurementRuns = 10): array
    {
        foreach ($this->strategies as $strategy) {
            // Flush Spatie cache once so both strategies start from the same baseline
            app(PermissionRegistrar::class)->forgetCachedPermissions();

            for ($w = 0; $w < $warmUpRuns; $w++) {
                $strategy->run($userId, self::PERMISSIONS, self::ROLES, $iterations);
            }

            $times = [];
            for ($m = 0; $m < $measurementRuns; $m++) {
                DB::flushQueryLog();
                gc_collect_cycles();
                $start = microtime(true);
                $strategy->run($userId, self::PERMISSIONS, self::ROLES, $iterations);
                $times[] = (microtime(true) - $start) * 1000;
            }

            // Aggregate into p50, p95, p99, mean, stddev
        }
    }
}

Each "iteration" performs 27 hasPermissionTo() checks + 4 hasRole() checks + getAllPermissions() + getRoleNames(). The bench tests iterations=1, iterations=10, and iterations=50 to see how the cost scales when authorization is called more than once per request (typical for views that gate multiple sections).

Run yourself:

git clone https://github.com/scabarcas17/laravel-permissions-redis-benchmark
cd laravel-permissions-redis-benchmark
composer install
php artisan migrate:fresh --seed --seeder=BenchmarkSeeder
php artisan bench:markdown --warm=5 --runs=30

The full percentile breakdown (also in the bench README):

### 10 Iterations (27 permission checks + 4 role checks + 2 collection calls)

| Metric            | Spatie         | Redis         | Delta            |
|-------------------|----------------|---------------|------------------|
| DB Queries        | 40             | 10            | 75% fewer        |
| Median (p50)      | 138.87 ms      | 13.01 ms      | 10.68x faster    |
| p95               | 140.13 ms      | 13.78 ms      | —                |
| p99               | 159.27 ms      | 13.87 ms      | —                |
| Mean ± StdDev     | 139.42 ± 3.86  | 13.11 ± 0.45  | —                |

A few honest notes about these numbers:

Steady-state, not cold-start. Warm-up runs amortize app bootstrap, Spatie's global registry cache load, Redis connection setup. We're measuring what users see in production, not the first request after a deploy.
SQLite + local Redis. Absolute ms will be different on MySQL or Postgres or remote Redis. The ratio (~10x median) should hold; the constants won't. The bench is reproducible on your hardware in under 30 seconds.
Single user. No concurrent load. The bench doesn't simulate hundreds of simultaneous requests competing for Redis connections — that's a separate exercise (k6, wrk).
Doesn't cover v4-specific features yet. Wildcard permissions, group invalidation, the batch role-check API (userHasAnyRole, userHasAllRoles) aren't in the harness. They'd push the delta wider, not narrower, but the current numbers stop at the basic API.

The 5-line setup

composer require scabarcas/laravel-permissions-redis
php artisan vendor:publish --tag=permissions-redis-config
php artisan migrate

Then on your User model:

use Scabarcas\LaravelPermissionsRedis\Traits\HasRedisPermissions;

class User extends Authenticatable
{
    use HasRedisPermissions;
}

Optional: in your AuthServiceProvider or a listener, warm on login:

Event::listen(Login::class, function (Login $event) {
    app(AuthorizationCacheManager::class)->warmUser($event->user->id);
});

That's it. Same hasRole, hasPermissionTo, assignRole, givePermissionTo, @role, @can, role: middleware as Spatie. The migration adds the same permissions, roles, model_has_permissions, model_has_roles, role_has_permissions tables Spatie uses, so a migration from Spatie is essentially "swap the trait, run warmAll".

When you should NOT use this

The whole pitch falls apart in a couple of cases. Be honest with yourself:

You don't run Redis. Adding Redis as a hard dependency just for permissions is overkill if you're on a single-server SQLite setup with 10 daily users. Use Spatie.
Your authorization is shallow. If you do @can('admin') twice per page and ship 1000 requests/day, the absolute ms savings are tiny and the migration cost isn't worth it. Use Spatie.
You need a cache-driver-agnostic abstraction. This package binds you to Redis. If "we might swap Redis for Memcached / DynamoDB / database cache" is in your near-term plan, this isn't the right call — use Spatie + a custom decorator instead.
You're on Laravel <11. This package targets Laravel 11/12/13 and PHP 8.3+. Spatie supports older versions.

The package is honest about all of this in its README — the goal isn't to "replace Spatie" but to give you a clearly different choice when authorization throughput actually matters in your app.

Where to find it

Package: scabarcas/laravel-permissions-redis (composer require scabarcas/laravel-permissions-redis)
Benchmark harness: laravel-permissions-redis-benchmark — clone, run, see your own numbers
Discussions: open on the package repo if you want to compare design notes, ask about migration from Spatie, or report edge cases

Feedback welcome — especially from people who've already written custom Spatie cache decorators or who'd benchmark this against a different workload.

Redis-backed permissions for high-volume Laravel apps: v4.0.0-beta.1

Sebastian Cabarcas — Thu, 23 Apr 2026 15:36:01 +0000

I just shipped v4.0.0-beta.1 of laravel-permissions-redis, and I want to share both what's in it and the specific problem it exists to solve.

The problem

Spatie's laravel-permission is the de-facto permissions package in the Laravel ecosystem and it's great. But it was designed for the common case: users have roles, roles have permissions, you check them a handful of times per request, you hit the DB, everyone's happy.

What happens when you scale that model?

An admin panel rendering 200+ ACL-gated widgets per page
An API gateway fanning out to 30 microservices, each check needing authorization context
A reporting dashboard pulling user-filtered data with permission checks on every field

At that point, each permission check is a DB roundtrip (even if cached at query level), and your p99 latency is now dominated by authorization.

What this package does

Moves the entire read path to Redis.

Roles and permissions are denormalized into Redis SETs: user:{id}:permissions, user:{id}:roles
Permission checks become SISMEMBER — ~0.1ms vs a DB roundtrip of 5-20ms
Writes (assign/revoke) update the DB, fire events, and rewarm the Redis cache
Cache invalidation is event-driven and automatic

The tradeoff: Redis dependency, cache warming overhead at user login, slightly more complex write path.

What's new in v4.0.0-beta.1

Permission group metadata

Previously PermissionDTO::group was always null because Redis didn't store group data. Now there's a Redis hash (permission_groups) that maps {guard}|{name} → group. getAllPermissions() returns properly enriched DTOs.

Role-level permission checks

Role::hasPermission('posts.create') — direct SISMEMBER on the role's permission set. Useful when you want to know "does the admin role have X?" without loading a user.

Queue-backed cache warming

Warm commands now accept --queue:

php artisan permissions-redis:warm --queue=default
php artisan permissions-redis:warm-user 42 --queue=default

Dispatches WarmAllCacheJob / WarmUserCacheJob instead of running sync. Useful when warming millions of users.

Multi-user-models

Set user_model as an array in config:

'user_model' => [App\Models\User::class, App\Models\Admin::class],

Both types are warmed, both are covered by the Gate::before super-admin callback.

Blade directive guard override

@role('admin', 'api')
    ...
@endrole

Second argument is the guard name. All six directives (@role, @hasanyrole, @hasallroles, @permission, @hasanypermission, @hasallpermissions) accept it.

UUID/ULID role IDs

If your Role model uses non-integer primary keys, v4 handles it. PermissionRepositoryInterface now types role IDs as int|string.

Defensive additions

LRU eviction in the in-memory resolver cache — prevents unbounded memory growth in long-running workers (queue workers, Octane). Default limit: 1000 users.
Warm cooldown — if Redis cache creation keeps failing, the resolver stops hammering the DB with warm attempts (default: 1 second cooldown per user).
TransactionFailedException — Redis EXEC returning null/false now throws observable exceptions instead of silently dropping writes.

Breaking change

PermissionRepositoryInterface gained three methods for permission group metadata:

public function setPermissionGroups(array $groups): void;
public function getPermissionGroups(array $encodedNames): array;
public function deletePermissionGroup(string $encodedName): void;

If you have a custom implementation of the interface (tenant-aware or otherwise), you must implement these. If you only use the built-in RedisPermissionRepository, no code changes — just run php artisan permissions-redis:warm --fresh after upgrade to populate the new hash.

Install the beta

composer require scabarcas/laravel-permissions-redis:^4.0@beta
php artisan vendor:publish --tag=permissions-redis-migrations
php artisan migrate
php artisan permissions-redis:warm --fresh

What I'm looking for

1-2 week beta window before I cut rc.1. Feedback on:

API ergonomics for the new methods
Clarity of the upgrade guide
Anything that breaks in your specific setup (tenancy, custom guards, UUID users)

Release notes · GitHub · Packagist

If you try it, let me know how it goes.

Benchmarking Laravel Permission Checks: Database vs Redis

Sebastian Cabarcas — Wed, 01 Apr 2026 13:41:29 +0000

"How much faster is Redis for permission checks?" is a question I get every time I mention laravel-permissions-redis. The answer depends on your scale, your access patterns, and what you're measuring.

So I built a benchmark application to get real numbers. Here's what I found.

Methodology

The setup

PHP 8.3 with OPcache enabled
Laravel 12 with default configuration
Redis 7.2 running locally (same machine, minimal network latency)
MySQL 8.0 running locally
Packages compared:
- spatie/laravel-permission v6 (database-backed, using Redis as Laravel cache driver)
- scabarcas/laravel-permissions-redis v3 (Redis SETs, dual-layer cache)

The data

1 user with 50 permissions assigned via 3 roles
Permissions structured in groups: posts.*, users.*, settings.*, reports.*
Both packages configured with their recommended defaults

What we measure

Database queries -- the number of queries hitting MySQL per request
Cache architecture -- how each package stores and retrieves permission data
Invalidation cost -- what happens when permissions change
Cold start -- first request after cache flush
Warm state -- steady-state performance

Important note on fairness: Spatie is configured with CACHE_DRIVER=redis to give it the fastest possible cache backend. This comparison is about architecture, not "database vs Redis" in the trivial sense.

Benchmark 1: Database queries per request

A typical request in our test application performs 33 permission checks (middleware + policy + inline checks). Here's how many database queries each package generates:

Scenario	spatie/laravel-permission	laravel-permissions-redis	Reduction
1 request (cold cache)	5 queries	1 query	80%
1 request (warm cache)	0 queries	0 queries	--
10 sequential requests	14 queries	10 queries	~29%
50 sequential requests	54 queries	50 queries	~7%

Why the numbers converge

Both packages cache after the first request. The difference on subsequent requests comes from cache invalidation behavior, which we'll cover next.

The real story isn't in steady-state -- it's in what happens when the cache isn't warm.

Benchmark 2: Cache architecture deep dive

This is where the architectural differences matter most.

How Spatie stores permissions

Cache key: "spatie.permission.cache"
Value: Serialized PHP array of ALL permissions for ALL users

On every hasPermissionTo() call:

Fetch the full serialized blob from Redis (via Laravel Cache)
Deserialize it (unserialize())
Filter permissions for the current user
Scan the resulting array for the requested permission

Time complexity per check: O(n) where n = total permissions in the system

How laravel-permissions-redis stores permissions

Redis key: "auth:user:42:permissions"
Value: Redis SET {"posts.create", "posts.edit", "users.view", ...}

On every hasPermissionTo() call:

Check in-memory PHP array (if already resolved this request) -- zero I/O
If miss: single SISMEMBER auth:user:42:permissions "posts.create" command

Time complexity per check: O(1) -- hash table lookup within the Redis SET

What this means in practice

Aspect	Spatie	laravel-permissions-redis
First check in a request	Deserialize full cache + scan	`SISMEMBER` (1 Redis call)
Second check (same request)	Deserialize full cache + scan	In-memory array (0 I/O)
10th check (same request)	Deserialize full cache + scan	In-memory array (0 I/O)
Memory per check	Full permission array loaded	Only user's permission set

With Spatie, if your application has 10,000 permissions across all users, every single hasPermissionTo() call loads and scans that entire dataset. With Redis SETs, each check only touches the current user's data.

Benchmark 3: Cache invalidation

This is the benchmark that convinced me to build the package.

Scenario: Admin changes a user's permissions

Spatie's approach:

// When any permission changes:
app(PermissionRegistrar::class)->forgetCachedPermissions();
// This calls: Cache::forget('spatie.permission.cache');

Result: Every user's cache is gone. The next request from any user pays the full cold-start cost.

With 50,000 active users and a 200 req/sec API, this means:

~200 concurrent cold-start database queries
Each query rebuilds the full permission cache
Cache stampede risk if multiple users hit simultaneously

laravel-permissions-redis approach:

// When user 42's permissions change:
$repository->warmUserCache(42);
// Only rewarms: auth:user:42:permissions and auth:user:42:roles

Result: Only user 42's cache is rewarmed. Every other user's cache stays untouched.

Invalidation cost comparison

Metric	Spatie	laravel-permissions-redis
Users affected	ALL	1 (the changed user)
DB queries triggered	1 heavy query (all permissions)	2 light queries (1 user's roles + permissions)
Cache stampede risk	High (all users cold)	None (only 1 user rewarmed)
Time to full recovery	Depends on traffic	Instant (proactive rewarm)

Benchmark 4: Cold start and cache warming

Single user cold start

When a user logs in with no cached data:

Spatie:

Query all permissions in the system
Serialize and store in cache
Deserialize and scan on each check

laravel-permissions-redis:

Query this user's roles (1 query)
Query permissions for those roles (1 query)
Write Redis SETs: SADD auth:user:42:permissions "posts.create" "posts.edit" ...
All subsequent checks: SISMEMBER or in-memory

Bulk cache warming (deploy scenario)

After a deploy, you might want to pre-warm the cache for all users:

# laravel-permissions-redis provides this out of the box
php artisan permissions-redis:warm

# Spatie has no equivalent -- cache builds lazily on first request

User count	Warm time (laravel-permissions-redis)	Notes
1,000	~2s	Chunked processing
10,000	~15s	Parallel Redis pipelines
100,000	~120s	Batched with progress bar

With Spatie, there's no warm command. The cache rebuilds on the first request after deploy, meaning your first 100-1000 users experience a slow response.

Benchmark 5: Memory usage

Per-request memory footprint

Package	Memory per request (50 permissions/user)
Spatie (all permissions cached)	~2-5 MB (full permission array deserialized)
laravel-permissions-redis	~50-100 KB (only current user's set)

The difference grows with the total number of permissions in your system. Spatie loads all permissions regardless of which user is making the request. laravel-permissions-redis only loads what's relevant to the current user.

The visualization

Here's how to think about the performance difference at different scales:

Permission checks per request
    |
    |  Spatie (warm)      Redis (warm)
    |  ~~~~~~~~~~~~       ~~~~~~~~~~~~
  5 |  Fast enough        Fast
 15 |  Fine               Fast
 30 |  Noticeable          Fast
 50 |  Slow               Fast
100 |  Very slow           Fast
    |
    +---------------------------------------->

The key insight: Spatie's performance degrades linearly with the number of checks per request. laravel-permissions-redis stays constant because each check is O(1).

When the difference doesn't matter

Let's be honest about when this optimization is irrelevant:

< 50 req/sec with < 10 checks/request: Both packages are fast enough. Choose based on features, not performance.
Read-heavy, rarely-changing permissions: If permissions never change, Spatie's cache stays warm indefinitely. The invalidation advantage disappears.
Single-user CLI or queue jobs: No concurrent cache stampede risk. Cold start cost is a one-time hit.

When the difference is critical

High-traffic APIs: 200+ req/sec where each request checks 10+ permissions
Multi-tenant SaaS: Thousands of users with different permission sets
Real-time applications: WebSocket servers or Octane workers with long-lived processes
Frequent permission changes: Admin panels where roles/permissions are edited regularly
Large permission matrices: 100+ permissions per user across multiple roles

Reproducing these benchmarks

The benchmark application is open source:

git clone https://github.com/scabarcas17/laravel-permissions-redis-benchmark
cd laravel-permissions-redis-benchmark
composer install
php artisan migrate --seed
php artisan benchmark:run

It generates a side-by-side comparison report with your specific hardware. I encourage you to run it yourself -- your numbers will vary based on Redis/MySQL latency, PHP version, and hardware.

Conclusion

The performance difference between database-backed and Redis-backed permission checking comes down to three architectural decisions:

O(1) vs O(n) lookups -- Redis SISMEMBER vs array scanning
Surgical vs nuclear invalidation -- rewarm one user vs flush everything
Dual-layer caching -- in-memory + Redis vs cache driver only

For small applications, these differences are academic. For high-traffic Laravel APIs, they're the difference between adding more servers and optimizing what you have.

The package is free, MIT-licensed, and available on Packagist:

composer require scabarcas/laravel-permissions-redis

Check out the GitHub repo for documentation, migration guides, and the full test suite. Issues and PRs are welcome.

All benchmarks were run on a MacBook Pro M2 with local Redis and MySQL. Production numbers will vary based on network topology and hardware. The benchmark repository includes instructions for reproducing on your own hardware.

Why I Built a Redis-Backed Alternative to Spatie Permissions

Sebastian Cabarcas — Tue, 31 Mar 2026 16:51:50 +0000

If you've worked with Laravel for more than a week, you've probably installed spatie/laravel-permission. It's the default answer to "how do I add roles and permissions to my app?" -- and for good reason. It's well-maintained, well-documented, and battle-tested.

So why did I build laravel-permissions-redis?

Because at scale, the database becomes the bottleneck.

The problem I kept hitting

I was building a multi-tenant SaaS with a Laravel API serving ~200 requests/second. Each request triggered between 5 and 30 permission checks -- middleware, policies, Blade directives, inline gates. With Spatie, every single one of those checks was hitting the cache driver, deserializing a full array of permissions, and scanning it linearly.

On cold cache? Full database reload. On cache invalidation? Forget everything, rebuild from scratch on the next request. With 50,000+ users, that "next request" was painfully slow.

The numbers looked something like this:

Scenario	DB queries (Spatie)	DB queries (Redis approach)
1 request, 33 checks	5	1
10 requests	14	10
50 requests	54	50

After the initial cache warm, all permission checks with Redis resolve with zero additional database queries. Not "fewer queries" -- zero.

Why not just use Redis as a Laravel cache driver?

That was my first thought too. Set CACHE_DRIVER=redis and let Spatie's existing cache layer benefit from Redis speed.

It helps, but it doesn't solve the architectural problems:

O(n) lookups. Spatie serializes all permissions into a single cached array. Each hasPermissionTo() call deserializes that array and scans it. With 200 permissions per user, that's 200 comparisons per check.
Nuclear invalidation. When any permission changes, Spatie calls forgetCachedPermissions() which drops the entire cache. Every user pays the cold-start penalty on their next request.
No in-memory request cache. Even with Redis as the cache driver, Spatie hits Redis on every single check within the same request. If your middleware checks 5 permissions, that's 5 Redis round-trips.

The architecture of laravel-permissions-redis

I took a fundamentally different approach using Redis SET data structures:

auth:user:{userId}:permissions  ->  SET {"posts.create", "posts.edit", "users.view"}
auth:user:{userId}:roles        ->  SET {"admin", "editor"}
auth:role:{roleId}:permissions  ->  SET {"posts.create", "posts.edit"}

Each permission check is a single SISMEMBER command -- O(1) time complexity, regardless of how many permissions exist. No deserialization, no scanning.

The dual-layer cache

Request hits middleware
    -> Check in-memory PHP array (zero I/O)
    -> Miss? Check Redis SET (one SISMEMBER)
    -> Miss? Query database, warm Redis, populate in-memory cache

Within a single request, the first check might hit Redis. Every subsequent check for the same user resolves from a PHP array in memory -- no I/O at all.

Surgical invalidation

When a user's permissions change, we don't flush everything. We rewarm only the affected user's Redis SETs. Everyone else's cache stays warm. No cold-start stampede.

// Spatie: nuke everything
Cache::forget('spatie.permission.cache');

// laravel-permissions-redis: rewarm only what changed
$repository->warmUserCache($userId);

Feature parity (and beyond)

I didn't want this to be a "fast but limited" alternative. The goal was full feature parity with Spatie plus the features I kept needing:

Drop-in API compatibility

// These work exactly the same as Spatie
$user->assignRole('admin');
$user->givePermissionTo('posts.create');
$user->hasPermissionTo('posts.edit');
$user->hasAnyRole('admin', 'editor');

Same method names, same Blade directives (@role, @hasanyrole), same middleware (permission:posts.create). Migrating is mostly swapping a trait and a config file.

Features Spatie doesn't have

Feature	Description
Octane support	Automatic in-memory cache reset between requests in long-lived workers
Multi-tenancy	Redis key isolation per tenant, with built-in Stancl/Tenancy resolver
Wildcard permissions	`posts.*` matches `posts.create`, `posts.edit`, etc. via `fnmatch()`
Super admin role	One config value to make a role bypass all permission checks
Testing trait	`actingAsWithPermissions($user, ['posts.create'])` -- one-liner test setup
Cache warming CLI	`php artisan permissions-redis:warm` to pre-warm all users on deploy
Seed command	`php artisan permissions-redis:seed` reads from config, supports `--fresh`
Migrate from Spatie	`php artisan permissions-redis:migrate-from-spatie` with `--dry-run`
Fluent guard scoping	`$user->forGuard('api')->hasPermissionTo('posts.create')`

Automated migration from Spatie

This was important to me. If you already have Spatie installed with production data, migration needs to be painless:

# See what would happen without changing anything
php artisan permissions-redis:migrate-from-spatie --dry-run

# Run the migration
php artisan permissions-redis:migrate-from-spatie

The command reads Spatie's tables, creates equivalent records in the new schema, and warms the Redis cache. There's a full migration guide with a method equivalence table and behavior differences.

Multi-tenancy without the headache

Spatie's "teams" feature works but adds a team_id column to every pivot table and requires careful query scoping.

With Redis, tenant isolation is simpler -- prefix the keys:

auth:user:t:{tenantId}:{userId}:permissions

Configuration is two lines:

// config/permissions-redis.php
'tenancy' => [
    'enabled'  => true,
    'resolver' => 'stancl', // or any callable
],

Complete data isolation. No query scoping to forget. No cross-tenant leaks.

Octane: the problem nobody talks about

Laravel Octane keeps your application in memory across requests. Great for performance, terrible for anything that caches state in PHP properties.

Spatie caches permissions in static properties. In Octane, User A's permissions can leak into User B's request if they hit the same worker. The Spatie team acknowledges this and suggests workarounds, but there's no built-in solution.

laravel-permissions-redis listens for Octane's RequestReceived event and resets all in-memory state automatically:

// config/permissions-redis.php
'octane' => [
    'reset_on_request' => true,
],

No leaked state. No workarounds. It just works.

The honest trade-offs

This package is not for everyone. Here's when you should not use it:

You don't run Redis. This package requires Redis. If your stack is MySQL + file cache, Spatie is the right choice.
You need getDirectPermissions() vs getPermissionsViaRoles(). This package merges all permissions into a flat set. If you need to distinguish "was this permission assigned directly or via a role?", Spatie handles that better.
You need to support PHP 8.0 or Laravel 8. This package requires PHP 8.3+ and Laravel 11+.
Authorization isn't your bottleneck. If you're doing 10 requests/second with 3 permission checks each, Spatie is fast enough. Don't add Redis complexity for no measurable gain.

Getting started

composer require scabarcas/laravel-permissions-redis

php artisan vendor:publish --provider="Scabarcas\LaravelPermissionsRedis\LaravelPermissionsRedisServiceProvider"

php artisan migrate

# Optional: warm cache for all existing users
php artisan permissions-redis:warm

Add the trait to your User model:

use Scabarcas\LaravelPermissionsRedis\Traits\HasRedisPermissions;

class User extends Authenticatable
{
    use HasRedisPermissions;
}

That's it. The API is intentionally familiar. If you've used Spatie, you already know how to use this.

What's next

The package is at v3.0.0 with full support for PHP 8.3/8.4, Laravel 11/12/13, and Redis 6/7. The test suite covers UUID/ULID models, Octane workers, multi-tenant isolation, and integration tests against real Redis instances in CI.

I'd love feedback, issues, and PRs. The repo is at github.com/scabarcas17/laravel-permissions-redis.

If you're hitting performance walls with database-backed permissions, give it a try. Your Redis server is already sitting there -- might as well put it to work.

How I Solved Multi-Guard Permission Issues in Laravel with Redis

Sebastian Cabarcas — Mon, 30 Mar 2026 16:11:07 +0000

When working with Laravel applications that use multiple guards (web, api, etc.), I ran into a subtle but critical issue:

Permissions were leaking between guards.

At first, everything seemed fine… until it wasn’t.

The Problem

Imagine this scenario:

A user has a permission under the api guard
You check that permission under the web guard
$user->hasPermissionTo('posts.edit');

And it returns true, even though it shouldn’t.

This happens when your permission system doesn’t properly isolate guards — something that can silently introduce security issues in production.

Why This Happens

Most implementations treat permission names as globally unique:

posts.edit

But in reality, permissions should be scoped by guard, meaning:

web: posts.edit
api: posts.edit

Without that separation, collisions are inevitable.

The Solution

In v2.0.0 of my package (laravel-permissions-redis), I redesigned the permission system to be fully guard-aware.

1. Guard-Scoped Permission Checks

All permission and role checks now accept a guard:

$user->hasPermissionTo('posts.edit', 'api');
$user->hasRole('admin', 'web');

Or fluently:

$user->forGuard('api')->hasPermissionTo('posts.edit');

2. Redis Storage Redesign

Permissions are now stored using this format:

guard|permission

Example:

api|posts.edit
web|posts.edit

This completely eliminates collisions between guards.

3. Smarter Caching

I also improved cache control to make the system more scalable:

rewarmAll() → rebuild cache without flushing
warmPermissionAffectedUsers() → only warm impacted users
getUserIdsAffectedByPermission() → precise impact analysis

4. Performance Improvements

No more full table scans when warming users
Redis config is cached internally
Middleware now resolves the correct guard automatically

Breaking Changes

If you're upgrading:

Methods like hasPermission() now accept a $guard
Redis key format changed → you must flush and rewarm cache

Key Takeaway

Authorization bugs are dangerous because they don’t crash your app — they silently give access.

Fixing guard isolation is not just a “nice to have”, it’s essential for any system with:

APIs + Web apps
Multi-auth setups
Scalable architectures

Final Thoughts

This update was focused on one thing:

Making authorization correct, predictable, and scalable.

If you're dealing with complex permission systems in Laravel, this approach might save you from some very tricky bugs.

I’d love to hear your thoughts or how you're handling permissions in your projects.

Reducing Laravel Permission Queries Using Redis (Benchmark Results)

Sebastian Cabarcas — Tue, 24 Mar 2026 16:32:51 +0000

Laravel permissions work great… until your application starts to scale.

If you're using role/permission checks heavily, you might be hitting your database more often than you think.

In this article, I’ll show you a simple benchmark comparing the default behavior vs a Redis-based approach.

The Problem

In many Laravel applications, permission checks look like this:

$user->can('edit-post');

Looks harmless, right?
But under the hood, this can trigger multiple database queries, especially when:

You have many users
Complex role/permission structures
Frequent authorization checks

At small scale, it’s fine.
At large scale… it adds up quickly.

Benchmark Setup

To test this, I created a simple benchmark comparing:

Default Laravel permissions behavior
Redis-cached permissions

Benchmark repo: https://github.com/scabarcas17/laravel-permissions-redis-benchmark

The idea was simple:

Run multiple permission checks
Measure database queries
Compare performance

Results

Default Behavior

Multiple database queries per permission check
Repeated queries for the same permissions
Increased load under high traffic

With Redis

Permissions cached in Redis
Near-zero database queries after first load
Much faster response times

Key Insight

The biggest issue is not the first query…
It’s the repeated queries for the same permissions.
By caching permissions in Redis, we eliminate redundant database access.

The Solution

To test this approach in a real scenario, I built a small package: https://packagist.org/packages/scabarcas/laravel-permissions-redis

GitHub repo:
https://github.com/scabarcas17/laravel-permissions-redis

This package adds a Redis layer on top of Laravel permissions, reducing unnecessary queries.

When Does This Matter?

This approach is especially useful if your app has:

High traffic
Many permission checks per request
Complex role/permission structures
Performance bottlenecks related to authorization

Final Thoughts

Laravel’s default behavior is solid and works well for most applications.

But if you're scaling and noticing performance issues, caching permissions can make a real difference.

This benchmark is just a starting point—but it clearly shows the impact of reducing repeated database queries.

Feedback

I’d love to hear your thoughts:

Have you experienced performance issues with permissions?
How are you handling caching in your apps?

How I Eliminated Repetitive Permission Queries in Laravel Using Redis

Sebastian Cabarcas — Thu, 19 Mar 2026 19:27:35 +0000

One of the most common performance issues I’ve seen in Laravel applications is related to roles and permissions.

At first, everything works fine.

But as the application grows, authorization checks become more frequent — and suddenly, your database is handling a large number of repetitive queries just to validate permissions.

The Problem
Even when using caching strategies, many applications still:

Hit the database frequently for permission checks
Recompute authorization logic on every request
Struggle under high load scenarios

This becomes especially noticeable in systems with:

Complex role structures
Multiple middleware checks
High traffic

The Idea

Instead of relying on the database (even with caching), I explored a different approach:

Move roles and permissions entirely into Redis

The goal:

Keep authorization in-memory
Eliminate repetitive queries
Improve response times

The Approach

The core idea is simple:

Store roles and permissions in Redis
Resolve all authorization checks from memory
Avoid hitting the database during request lifecycle

This allows permission checks to be:

Faster
More scalable
More predictable under load

The Result

I built a package around this idea:

https://github.com/scabarcas17/laravel-permissions-redis
https://packagist.org/packages/scabarcas/laravel-permissions-redis

It’s designed to integrate naturally with Laravel while replacing repetitive database queries with Redis-based resolution.

When Does This Make Sense?

This approach is especially useful if:

Your app performs frequent permission checks
You are scaling and need better performance
You want to reduce database load

Final Thoughts

Laravel is not the problem — architecture is.

Small decisions like how you handle permissions can have a huge impact as your system grows.

I’d love to hear how others are solving this problem or any feedback on this approach.