What is Laravel Octane, and what changes when you use it?

Summary

Octane serves the app with a long-running server (FrankenPHP, Swoole or RoadRunner) that boots the framework once and keeps it in memory between requests, which removes bootstrap cost and greatly increases throughput. The catch: state now persists across requests.

Longer Answer

Under PHP-FPM every request starts from scratch. Under Octane the application object, singletons and static properties survive between requests, so:

• A singleton that captured the request, the authenticated user or config at construction time will leak it into later requests. Inject the request where it is used, use scoped bindings, or resolve lazily.
• Static arrays used as caches grow forever: memory leaks.
• Octane resets many first-party services between requests, but not your own state.
• Restart workers on deploy (octane:reload), and use --max-requests to recycle workers as a safety net.

Swoole also offers concurrent tasks and an in-memory table cache. Profile first: if the bottleneck is the database, Octane will not help much.

Key Points

• Framework booted once; kept in memory.
• Singletons and statics leak state across requests.
• Use scoped bindings; recycle workers.
• Only helps if bootstrap cost matters.

Deep dive: Request Lifecycle course: Laravel Octane and Long-Running Workers

What interviewers look for

Understanding of state leakage. Candidates who have run Octane mention the request-in-singleton bug specifically.

Follow-up questions

• How would you find a memory leak in an Octane app?