Anass Ez-zouaine — Senior Backend Engineer · Software Architect · AI Engineer — Laravel

Laravel Octane: making PHP scream on high-traffic apps

Fri, 29 May 2026 00:00:00 GMT

Standard PHP is a bit like a restaurant that fires its entire staff and rebuilds the kitchen from scratch for every single customer order. You walk in, they hire a chef, buy a stove, cook your meal, and then demolish the building as soon as you leave. It's consistent and safe, but it's a massive waste of energy when you're trying to serve thousands of people at once.

This is the PHP-FPM lifecycle. Every request boots the entire Laravel framework, loads your service providers, parses your config, and instantiates your objects. For low-traffic sites, it's fine. But when you hit real scale, those milliseconds of "boot time" become a wall you can't climb without throwing excessive amounts of expensive hardware at the problem. Horizontal scaling buys you room, but it doesn't fix the underlying latency.

The solution is to stop rebuilding the kitchen. Laravel Octane changes the game by booting your application once, keeping it in memory, and then feeding requests to it through a high-performance worker pool. It transforms PHP from a "short-lived script" language into a "long-lived process" powerhouse.

Why your app feels heavy

The overhead of traditional PHP isn't just about speed; it's about efficiency. In a standard request, your CPU spends a significant chunk of time just getting the application ready to do work. Once it finally starts execution, it does the database query, renders the view, and then dies.

If you're running a complex Laravel monolith with dozens of packages and custom service providers, your boot time might be 30ms to 50ms before a single line of your actual business logic even runs. Under high traffic, this leads to CPU thrashing. You're paying for the "setup" over and over again.

Laravel Octane removes this boot cycle. By using high-performance application servers like Swoole or RoadRunner, your app stays resident in memory. The first request boots the framework, and subsequent requests hit a "warm" application. We're talking about moving from 50ms responses to sub-10ms responses just by changing how the process is managed.

Swoole vs RoadRunner: choosing your engine

When you drop Octane into your project, you have to choose between two primary engines: Swoole and RoadRunner. I've used both in production, and while they both solve the "persistent state" problem, they do it differently.

Swoole

Swoole is a C++ extension for PHP. It's essentially a high-performance networking engine that allows PHP to handle asynchronous tasks, coroutines, and long-lived connections.

Pros — it is incredibly fast. Because it lives as an extension, it has deep access to PHP's internals. It also gives you access to the "Octane cache," an in-memory store that's significantly faster than Redis for local data.
Cons — it can be a bit of a nightmare to install and debug. Because it's a binary extension, you have to compile it or find the right package for your OS. Xdebug doesn't always play nice with it, and it can be picky about your environment.

RoadRunner

RoadRunner is written in Go. It acts as a load balancer and process manager that communicates with your PHP workers via a high-speed binary protocol (Goridge).

Pros — no extensions required. It's a single binary you drop into your project. It's much easier to set up in a Docker container and generally feels more "cloud-native."
Cons — it's slightly slower than Swoole because of the communication overhead between the Go binary and the PHP processes, though for 99% of apps, this difference is negligible.

For most developers starting out with Octane, I recommend RoadRunner for the ease of use. If you are chasing every last millisecond and need features like async task workers, go with Swoole.

Tuning your worker pool

The secret sauce of Octane is the "worker pool." Instead of one process per request, you have a fixed number of workers waiting to handle incoming traffic. If you misconfigure this, you'll either leave performance on the table or crash your server.

A general rule of thumb for sizing your worker pool depends on whether your app is CPU-bound or I/O-bound.

CPU-bound apps — if you're doing heavy data processing or image manipulation, set your worker count to the number of CPU cores you have. Adding more workers will just cause context switching and slow things down.
I/O-bound apps — most web apps spend 90% of their time waiting for a database, Redis, or an external API. In this case, you can scale your workers to 2x or even 4x your core count. This allows one worker to wait for the DB while another handles a new request.

# Starting Octane with 16 workers for an I/O-heavy app
php artisan octane:start --server=swoole --workers=16

Don't forget about task workers if you're using Swoole. These are separate from your HTTP workers and are perfect for offloading slow tasks like sending emails or processing webhooks without blocking the main request cycle.

The danger of persistent state

The biggest hurdle when moving to Octane is the shift in mindset. In traditional PHP, "leaky" code doesn't matter much because the process dies after 100ms. In Octane, a memory leak is a ticking time bomb.

If you have a static array in a service provider that you append to on every request, that array will grow until your server runs out of RAM. You have to be extremely careful with:

Static properties — avoid using them for request-specific data.
Singletons — if you register a singleton in your app container, it stays alive. If that singleton caches data, you need to make sure that data is cleared or managed properly between requests.
Global state — avoid global variables at all costs (which you should be doing anyway).

Laravel helps you by "resetting" some core services between requests, but it can't catch everything. If you're migrating an old codebase from monolith to microservices, you'll want to audit your service providers for any long-lived state.

Protecting yourself with max-requests

The best insurance policy against memory leaks is the --max-requests flag. This tells Octane to kill and restart a worker after it has handled a certain number of requests.

# Restart workers every 1000 requests to prevent memory bloat
php artisan octane:start --max-requests=1000

This keeps your memory usage predictable while still giving you the performance benefits of a warm application.

Real-world optimization tips

Once you have Octane running, there are a few technical levers you can pull to squeeze out even more performance.

Connection pooling — ensure your database connections are persistent. In Octane, your workers stay alive, so they can hold onto their DB connections instead of reconnecting every time. Check your database.php config and ensure you aren't hitting the max connection limit on your DB server.
Octane cache — if you're using Swoole, use Octane::cache(). It's an in-memory table that's blistering fast. Use it for frequently accessed configuration or small datasets that don't change often.
Bytecode caching — make sure OPcache is enabled and tuned. Set opcache.validate_timestamps=0 in production since your code won't be changing while the server is running.
Graceful reloads — when you deploy new code, use php artisan octane:reload. This will gracefully restart the workers without dropping current connections. It's essential for zero-downtime deployments.

Takeaways for the high-traffic dev

Transitioning to Octane isn't just about installing a package; it's about maturing your infrastructure.

Identify the bottleneck — only use Octane if your boot time is the problem. If your database queries take 2 seconds, Octane won't help you.
Test for leaks — watch how your app behaves under sustained load and profile its memory growth over time.
Monitor workers — keep an eye on your CPU and RAM usage to find the "sweet spot" for your worker count.
Leverage concurrency — use Octane::concurrently() to execute multiple tasks at once and return their results, cutting down total response time for complex pages.

Octane takes PHP to a level where it can compete with Node.js and Go for high-concurrency applications while keeping the developer experience of Laravel intact. If you're building a SaaS that expects a lot of noise, this is your jet engine.

Are you running Octane in production yet, or is the fear of memory leaks keeping you on PHP-FPM? Drop a note via contact — let's talk worker counts. 🤘

Laravel multi-tenancy: how I built a scalable SaaS architecture

Sun, 08 Feb 2026 00:00:00 GMT

I still remember the panic of my first SaaS launch. I was watching the logs as the third customer signed up. Suddenly I realized I had no idea if customer A could see customer B's data. That realization is a rite of passage for every developer.

Building a software-as-a-service (SaaS) platform is a massive technical challenge. The biggest hurdle is almost always data isolation. You need to ensure that every tenant feels like they have the whole application to themselves. If you get this wrong early on, it will haunt you forever.

I have spent years refining a scalable architecture using Laravel. It is the most robust way to handle multiple customers on a single codebase. Here is how I approach the architecture to ensure security and scalability.

Why simple database structures fail SaaS

Most developers start with a single database. They add a user_id or team_id to every table. It works fine for the first ten users. Then the complexity grows.

You start adding more relationships. You forget to add a where clause in one obscure controller. Suddenly one customer is seeing another customer's private invoices. This is a catastrophic failure. It kills trust and can end your business overnight.

Performance also becomes a nightmare. As your database grows to millions of rows the queries get slower. Indexing helps, but it does not solve the fundamental problem of data bloat. You need a strategy that isolates data while keeping your infrastructure manageable.

Choosing your isolation strategy

When I build custom web solutions I always start by choosing between two main paths. You either go with a single database or a multi-database setup.

The single database approach uses a shared schema. Every row has a tenant_id. It is cheap to run and easy to update. I recommend this for startups where costs need to stay low. You can manage thousands of small tenants on a single server this way.

The multi-database approach is the gold standard for enterprise. Every customer gets their own database. This offers the best security and makes backups easy. If one database crashes the others stay online. I use this for high-value clients who have strict compliance needs.

I often use the stancl/tenancy package for Laravel. It is the most flexible tool in the ecosystem. It allows you to switch between these strategies as your business grows. You can find out more about how I handle these complex technical challenges on the Ansezz work page.

Building with global scopes

The secret to sleeping well at night is automation. I never rely on my memory to filter data. Instead I use Laravel global scopes.

A global scope automatically adds a filter to every query on a model. It ensures that Customer::all() only returns customers for the current tenant. It happens behind the scenes so you cannot forget it.

I create a BelongsToTenant trait. I apply this trait to every model that needs isolation. It handles the filtering and automatically sets the tenant_id when a new record is created. It is a simple solution that prevents 99 percent of data leaks.

Here's what that trait looks like in practice:

<?php

namespace App\Concerns;

use App\Models\Tenant;
use App\Scopes\TenantScope;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

trait BelongsToTenant
{
    protected static function bootBelongsToTenant(): void
    {
        static::addGlobalScope(new TenantScope());

        static::creating(function ($model): void {
            if (! $model->tenant_id && app()->bound('tenant')) {
                $model->tenant_id = app('tenant')->id;
            }
        });
    }

    public function tenant(): BelongsTo
    {
        return $this->belongsTo(Tenant::class);
    }
}

You also need to isolate your cache and your file storage. If two tenants upload a file named logo.png they should not overwrite each other. I configure Laravel to use tenant-specific prefixes for all storage paths. This creates a true "sandbox" environment for every user.

Scaling on the cloud

Your architecture is only as good as the infrastructure it runs on. I usually deploy my Laravel apps using Docker and cloud providers like Google Cloud or AWS.

Containerization is key. It allows me to scale the application horizontally. When traffic spikes I can spin up more instances of the web server. Because the multi-tenancy logic is handled at the application level, the infrastructure stays clean.

I use managed database services like Google Cloud SQL. They handle the heavy lifting of backups and scaling. For multi-database setups I use automated scripts to provision new databases whenever a customer signs up. This "infrastructure as code" approach ensures that scaling is a button click away.

If you are looking to modernize your digital presence with a scalable cloud setup you can see my full range of services at ansezz.com.

The tenant switcher experience

The final piece of the puzzle is the user interface. Customers need a seamless way to move between different accounts if they own multiple businesses.

I build clean dashboards using Vue. The frontend communicates with the Laravel backend via GraphQL APIs. This setup allows for a very fast and reactive user experience. The tenant switcher is always accessible and shows the user exactly which context they are working in.

I focus on making the transition between tenants feel instant. I cache the tenant configuration in the frontend to avoid unnecessary API calls. It is these small details that separate a basic app from a high-quality pro solution.

My SaaS architecture checklist

If you are starting a new project today, here are the steps I recommend you follow.

Choose your package early. I prefer stancl/tenancy because of its flexibility. It handles subdomain routing and database switching out of the box.
Implement global scopes immediately. Do not wait until you have ten models. Add the trait to your base model and make it a standard part of your workflow.
Automate your deployment. Use Docker from day one. It makes local development identical to production. This avoids the "it works on my machine" bugs that plague SaaS launches.
Plan for data migration. As you update your schema you need a way to run migrations across hundreds of databases. Tools like stancl/tenancy have built-in commands for this.
Keep it simple. Don't build a multi-database setup if you only have five users. Start small and scale as the revenue grows. My goal is always to deliver exceptional results without over-complicating the technical stack.

Are you building a SaaS or looking to migrate your current app to a multi-tenant structure? What is the biggest technical hurdle you are facing right now? Get in touch — I'd love to hear about it. 🤙