Scaling Laravel 12 with Octane and FrankenPHP: A Production Performance Guide

PHP-FPM has served us well for fifteen years, but it boots Laravel from scratch on every request 50 to 150ms wasted before your first line of business logic runs.

Octane keeps the framework in memory and serves requests from a long-running worker process; FrankenPHP is the modern app server that makes Octane production-ready without the operational baggage of Swoole or RoadRunner. This guide is the recipe my team used to cut p95 latency by more than half.

1. Why FrankenPHP is the right Octane backend in 2026

2. Installing on a fresh Laravel 12 app

composer require laravel/octane

php artisan octane:install --server=frankenphp

# Local dev
php artisan octane:frankenphp --workers=auto --max-requests=500

# Production (Forge or Vapor handles this; for raw VPS:)
php artisan octane:frankenphp --host=0.0.0.0 --port=8000 --workers=8 --max-requests=1000

3. The stateful container: where Octane bites you

Under PHP-FPM, every request gets a fresh container. Under Octane, the container persists. Anything you bind as a singleton including authenticated user, current request, locale is reused across requests unless you reset it. This is the source of the most surprising Octane bugs.

// BAD: this singleton survives across requests
$this->app->singleton(ReportBuilder::class, function ($app) {
    return new ReportBuilder($app['request']->user());
});
// First request: built with User A. Every subsequent request: still User A.

// GOOD: bind as scoped, reset between requests
$this->app->scoped(ReportBuilder::class, function ($app) {
    return new ReportBuilder($app['request']->user());
});

4. Concurrent dispatch with the Concurrency facade

Octane unlocks parallel work that simply does not exist under PHP-FPM. The Concurrency facade dispatches multiple closures and waits for all of them.

use Illuminate\Support\Facades\Concurrency;

[$user, $orders, $tickets] = Concurrency::run([
    fn () => User::with('profile')->find($id),
    fn () => Order::where('user_id', $id)->latest()->take(10)->get(),
    fn () => SupportTicket::where('user_id', $id)->open()->get(),
]);

return view('dashboard', compact('user', 'orders', 'tickets'));

The three queries run in parallel, the dashboard total time is the slowest one, not the sum. This pattern collapses three 80ms queries (240ms serial) into roughly 90ms.

5. Caching things that should never be re-resolved

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    if (app()->runningInConsole()) {
        return;
    }

    // Cache the merged config tree across all workers, populated once at boot.
    Octane::tick('refresh-feature-flags', function () {
        Cache::forever('feature_flags', FeatureFlag::all()->keyBy('key'));
    })->seconds(60)->immediate();
}

6. Real benchmarks (Forge, $40 Hetzner CX31, 4 vCPU / 8GB RAM)

Endpoint: GET /api/dashboard (auth + 4 queries)

PHP-FPM (php-fpm 8.3, 16 workers):
  Requests/sec:   712
  p50 latency:    18ms
  p95 latency:    98ms
  p99 latency:    188ms

FrankenPHP + Octane (8 workers, max-requests=1000):
  Requests/sec:   3,184
  p50 latency:    4ms
  p95 latency:    32ms
  p99 latency:    71ms

7. Production checklist

When NOT to use Octane

For everyone else: Octane + FrankenPHP is the new default for production Laravel. Install it, audit your singletons, set --max-requests, ship it.