Laravel Octane: speeding up your application several times over

Any application built with Laravel grows over time, and as the number of requests it handles increases, response speed becomes a genuinely critical concern. In a traditional PHP environment, every incoming HTTP request starts the entire framework from scratch: the autoloader is read, service providers are registered, configuration files are parsed and the dependency container is filled. Although this process stays invisible to the end user, it repeats on every single request and places unnecessary load on the server. Laravel Octane was created precisely to eliminate this repetitive work and to deliver a dramatic improvement in performance.

What Octane is and the problem it solves

Laravel Octane boots your application as a long-running, in-memory process using high-performance application servers such as Swoole or RoadRunner. Put simply, the framework loads only once and then stays resident in memory, after which every incoming request is served by that already prepared instance of the application. Thanks to this approach the bootstrap stage runs not on every request but only once, and as a result the number of requests the server can handle per second rises noticeably. In many projects throughput climbs to between two and four times higher than before, while average response time shrinks down to just a few milliseconds.

The core difference from PHP-FPM

In the traditional PHP-FPM model each request has its own complete life cycle: it begins, executes and ends, after which everything held in memory is fully cleared away. That model is reliable because one request physically cannot affect another, yet it is slow because everything has to be reconstructed from nothing on each call. Octane, by contrast, keeps the worker process alive, which means the application state persists between requests. The following example shows how to start the server through Octane:

composer require laravel/octane
php artisan octane:install --server=swoole
php artisan octane:start --workers=4 --max-requests=500

Here the --workers parameter defines how many processes run simultaneously, while --max-requests controls how many requests each worker handles before it is restarted. That last parameter matters a great deal, because it softens the memory leak problem and prevents any single process from growing without bound.

What you must be careful about

Because Octane keeps the application alive, things that were never a problem in classic PHP now demand your attention. The greatest danger lies in global variables and static properties, since they can carry over from one request into the next and cause data to bleed across different users. In the same way, if an application accumulates objects that are never cleaned up over time, a memory leak develops and the worker gradually starts consuming more and more resources. The code below illustrates exactly this kind of problematic situation:

class StatsCollector
{
    public static array $events = [];

    public static function add(string $name): void
    {
        self::$events[] = $name; // grows on every request
    }
}

This array is never cleared, so it keeps enlarging on every request and eventually fills all available memory. In cases like this you must reset the state after each request or rely on the flush events that Octane provides. Laravel also lets you, through dedicated configuration, recreate certain singletons on every request, which substantially reduces the risk of these errors occurring.

When you should move to Octane

Octane is by no means necessary for every project. If your site receives a few hundred visitors a day, plain PHP-FPM will handle everything perfectly well, and Octane would only add unwanted complexity to your maintenance burden. However, if your application is a high-traffic API, serves real-time functionality or must process thousands of requests per second, Octane delivers a tangible benefit. In those scenarios it not only increases speed but also lets you serve more users on the very same hardware, which directly lowers your server infrastructure costs.

Server requirements and the sayt.uz context

For Octane to function correctly you need an environment that allows processes to stay running continuously, which is why it shines on a VPS or a dedicated server. Swoole requires installing a PHP extension, while RoadRunner means running a Go-based binary, and both of these typically require root privileges. If you use a VPS service through sayt.uz, you gain the full control needed to install the required extensions and keep the worker processes running permanently. On shared hosting, running Octane is usually restricted, because it depends on persistent processes and system-level settings that such an environment does not offer. For this reason, when a project genuinely needs high speed, the sayt.uz VPS solution turns out to be the most suitable option.