LmCast :: Stay tuned in

I built the fastest PHP webserver in the world

Recorded: Sept. 19, 2026, 4:09 p.m.

Original Summarized

Qbix Server — A Web Server in Pure PHP
ServerDocsPerformanceCompatibilitySecurityReal-timeExamplesDashboardGitHub☰

A web server in pure PHP
Faster than Swoole, FrankenPHP, and RoadRunner on unmodified code. No extensions, no adapters, no Docker. One file.
git clone https://github.com/Qbix/webserver
cd webserver
php qbixserver.php

Or grab a self-contained binary

curl -LO https://github.com/Qbix/webserver/releases/latest/download/qbixserver-linux-x86_64
chmod +x qbixserver-linux-x86_64
./qbixserver-linux-x86_64

View on GitHub
See examples

Everything in one process
Replaces nginx + fpm + Node + Redis + supervisor + Docker.

⚡14× ThroughputPersistent workers at 120KB each. 400 workers on 200MB. 1,060 req/s where fpm does 78.Learn more →
🔌WebSocket + RoomsSame port as HTTP. Rooms are forked processes with shared state. Socket.IO protocol. No Node.Learn more →
🧩Unmodified PHPWordPress, Laravel, Symfony, Drupal. 28 functions shimmed. Reads .htaccess. Just works.Learn more →
🔒Microservice IsolationAuthority + sandbox with one config change. Same code, different roles. Secrets never leave the authority.Learn more →
🌐Cluster ReplicationMultiple servers with SQLite. Events replicate. Kill a node, restart — it catches up.Learn more →
📦Six Example AppsChat, kanban, SSE stream, REST API, live counter, distributed swarm. All included.Learn more →
📋Smart Response HeadersX-Cache-Tree for per-component invalidation. X-Accel-Redirect for access-controlled files. ETag generation. Directory listing.Learn more →
📈Auto-Generated API DocsWrite handler files, get OpenAPI 3.1 and MCP specs automatically. Swagger UI, Postman, Redoc — and AI tools can call your app’s API directly.Learn more →
🔐TLS, Cron & LoggingHTTPS auto-starts when certs exist. Built-in cron scheduler. Buffered access logs with daily rotation and gzip archiving.Learn more →

14×vs fpm (50ms I/O)
24×vs fpm (200ms I/O)
120KBper worker (COW)
0.03msstate reset

💡 Why it’s faster than everything else

The vast majority of PHP code — WordPress plugins, Laravel packages, every PDO::query() and file_get_contents() ever written — uses blocking I/O. Swoole’s coroutines can’t help with code that doesn’t yield. FrankenPHP and RoadRunner use the same worker-count-limited model as fpm.
Qbix takes a different approach: run many workers. The server loads your entire framework into a parent process, then calls pcntl_fork() to create workers. The kernel marks the parent’s pages copy-on-write. Workers share every loaded class — they only pay for pages they actually write to during the request.
A WordPress-like request dirties 30 pages = 120KB on Linux. So 200MB doesn’t buy 4 workers (like fpm) — it buys thousands. Each one blocks on its database query, and that’s fine. Blocking I/O doesn’t matter when you have enough workers. COW is what makes “enough workers” cost 47MB instead of 16GB.
This is pure userland PHP. No kernel module, no C extension, no custom allocator. Just pcntl_fork() after loading everything, and the OS does the rest.
We proposed this for PHP core as switch_global_context(). While that works its way through the RFC process, the server does it in userland today.

🔍 Benchmarks vs Swoole, FrankenPHP, and php-fpm

CPU-bound (WordPress-like workload, same 200MB):

Workersreq/svs fpm
php-fpm4~350—
Swoole4~4001.1×
Qbix1002,2946.6×

I/O-bound (50ms database query):

Workersreq/svs fpm
php-fpm478—
Swoole (coroutines*)4~300~4×
Qbix1001,06014×

I/O-bound (200ms — real database load):

Workersreq/svs fpm
php-fpm420—
Swoole (coroutines*)4~200–500~10–25×
Qbix20048824×

* Swoole coroutines require Runtime::enableCoroutine() and coroutine-aware drivers. Unmodified WordPress/Laravel uses blocking I/O and hits fpm’s ceiling.

🛡️ 28 functions shimmed — how state gets reset

Workers are persistent — they handle thousands of requests without restarting. Between each request, a Reflection-based snapshot restores all static properties in 0.03ms. 28 PHP functions are intercepted via source transformation at include time:
header(), session_start(), register_shutdown_function(), ini_set(), set_error_handler(), set_exception_handler(), spl_autoload_register(), putenv(), and 20 others — all tracked per request and cleaned up between requests.
Unmodified WordPress, Laravel, Symfony, and Drupal get shared-nothing safety automatically. No adapters, no code auditing.
Full compatibility details →

📊 How many users can one $30/month machine handle?

Metricphp-fpmQbix
Workers on 4GB~80 (50MB each)400 (120KB each)
Throughput (200ms I/O)~80 req/s~2,000 req/s
Concurrent active users1,60040,000
Registered accounts16K–32K400K–800K
WebSocketNeeds Node.js100K+ built in
DatabaseNeeds PostgresSQLite (50K writes/sec)
Monthly cost$30 + DB server$30 total

One machine. No database server, no Redis, no Node, no Docker. Add a second with DNS failover for redundancy — distributed mode keeps both SQLite copies in sync.

Fork after preload
Load everything once. Fork workers. Each costs 120KB, not 42MB.
Parent Process (30MB)framework · routes · cachesCOWCOWWorker (120KB)Worker (120KB)Worker (120KB)Worker (120KB)php-fpm: 4 × 42MB = 168MBQbix: 400 × 120KB = 47MBSame code. Same RAM. 100× more workers.

Live Dashboard
Built-in at /Q/dashboard. No Grafana, no Prometheus.
localhost:4000/Q/dashboardQbix Server Dashboard2,847Req/min142Connections400Workers23msLatency99.8%Uptime47MBMemory200 GET /api/users 12ms200 POST /api/tasks 34ms304 GET /css/app.css 1ms200 WS /Q/ws upgrade 2ms
Dashboard & control panel docs →

Get started
git clone https://github.com/Qbix/webserver
cd webserver
php qbixserver.php --root=examples/todo/web
View on GitHub → Download binary Examples

Qbix ServerSource on GitHubCompatibilityReleasesQbix PlatformOverviewSourceCommunityLinksExamplesDocumentationv1.1 — Boldly Go

Qbix Server is presented as a web server built entirely in pure PHP, designed to offer superior performance compared to existing solutions like Swoole, FrankenPHP, and RoadRunner, especially when operating on unmodified code without relying on extensions, adapters, or Docker. Its core architectural principle involves managing numerous workers efficiently, fundamentally differing from coroutine-based approaches. Instead of leveraging coroutines to handle blocking I/O, Qbix utilizes a model based on process forking. The server first loads the entire framework into a parent process and then uses pcntl_fork() to create isolated workers. This method leverages the operating system's copy-on-write (COW) mechanism, allowing workers to share the loaded classes while only paying for the memory pages they actively modify during a request, which results in significantly lower overhead per worker.

The system achieves high throughput by running many workers, each consuming only 120 kilobytes of memory, as opposed to the larger memory footprints seen in other systems. This approach allows for handling an extremely large number of concurrent requests, demonstrated by achieving 1,060 requests per second within the framework context, far surpassing the limits of traditional PHP-FPM. This design is highlighted by the fact that blocking I/O, common in many PHP operations such as PDO queries, is mitigated by having sufficient worker capacity, as blocking does not impede the overall system when many processes are active.

Qbix Server provides a comprehensive, integrated operational environment, consolidating functionalities typically managed by separate components like nginx, FPM, Redis, supervisor, and Docker into a single process. It natively supports WebSocket communication through a shared port, enabling the implementation of rooms for forked processes with shared state, adhering to the Socket.IO protocol without requiring a separate Node.js environment. Furthermore, the server maintains compatibility with popular frameworks such as WordPress, Laravel, Symfony, and Drupal by shimming twenty-eight essential functions at the time of inclusion, allowing unmodified PHP code to function seamlessly while ensuring shared-nothing safety and state resets between requests with minimal overhead, typically within 0.03 milliseconds by restoring static properties through reflection-based snapshots.

Security and observability are also intrinsic to the design. The server includes features such as automatic HTTPS initiation when certificates are present, built-in cron scheduling, and buffered access logging with daily rotation and gzip archiving. It also incorporates advanced response header generation, including mechanisms like X-Cache-Tree for invalidation, X-Accel-Redirect for access control, and ETag generation. Automating documentation generation is another key feature, allowing the server to automatically generate OpenAPI 3.1 and MCP specifications, facilitating integration with tools like Swagger UI and Postman.

In terms of scalability, Qbix Server supports cluster replication using SQLite databases, where events replicate between multiple servers, ensuring that performance and state are maintained even if a node fails. This distributed mode allows for redundancy, as the system can automatically synchronize data across nodes. The architecture supports handling substantial user loads, indicating that a single machine can manage up to approximately 40,000 concurrent active users and over 800,000 registered accounts, provided the database handling is managed efficiently. The system allows users to manage and monitor performance via a built-in live dashboard, eliminating the need for external monitoring solutions like Grafana or Prometheus.