🐘 Qbix Server : un serveur web écrit en pur PHP

📚 Introduction

Quand on veut sortir de PHP-FPM, le réflexe en 2026 c’est FrankenPHP, éventuellement Swoole ou RoadRunner via Octane. Tous partagent une caractéristique : le serveur n’est pas écrit en PHP. Go et Caddy pour l’un, une extension C pour l’autre.

Qbix Server prend le chemin inverse. C’est un serveur HTTP écrit en PHP pur, lancé par un simple php qbixserver.php, qui prétend remplacer nginx, php-fpm, supervisor et une partie de Redis ou Node.js par un seul process. Le projet est sous licence MIT, maintenu par Qbix sur GitHub, et vient de sortir en v2.0.0.

L’idée paraît absurde au premier abord. Un serveur web en PHP, plus rapide que FPM ? En regardant de près, le mécanisme tient debout, et il repose sur une fonctionnalité de l’OS que PHP-FPM exploite mal : le copy-on-write.

🔍 Comment un serveur en PHP peut-il tenir la charge ?

Réponse courte : en laissant le noyau faire le travail. Qbix charge le framework une fois dans un process parent, puis appelle pcntl_fork(). Chaque worker hérite des pages mémoire du parent, marquées copy-on-write : il ne paie que ce qu’il modifie. Selon le README, un worker coûte environ 120 Ko au lieu des 30 à 60 Mo d’un worker FPM.

C’est là que se joue l’argument. Sur une app qui passe son temps à attendre la base ou une API externe, le facteur limitant de FPM n’est pas le CPU mais le nombre de workers qui tiennent en RAM. Swoole règle ce problème avec des coroutines, à condition d’utiliser ses clients I/O. FrankenPHP et RoadRunner gardent un modèle à nombre de workers fixe. Qbix garde du code PHP bloquant tout à fait classique et lance simplement beaucoup plus de workers : le projet annonce environ 5 000 workers concurrents sur 1 Go de RAM, contre une vingtaine pour FPM.

🧱 Deux modes d’exécution

Par défaut, Qbix tourne en workers persistants (le projet parle aussi de mode « octane »). Le worker survit entre les requêtes, comme avec FrankenPHP en worker mode. Le problème classique de ce modèle, ce sont les fuites d’état : une propriété statique remplie par la requête A se retrouve dans la requête B.

Qbix attaque le problème sur deux fronts. D’abord, il réécrit à la volée, au chargement des fichiers, 27 fonctions natives qui n’ont pas de sens en SAPI CLI : header(), setcookie(), session_start(), ini_set(), set_error_handler(), spl_autoload_register(), putenv()… Elles sont suivies par requête et remises à leur valeur de boot. Ensuite, entre deux requêtes, un snapshot basé sur Reflection restaure toutes les propriétés statiques (environ 0,03 ms), repeuple les superglobales et vide $_SESSION et les buffers de sortie.

Quand ça ne suffit pas, il reste le fork-per-request : chaque requête s’exécute dans un process forké qui meurt ensuite. Aucune fuite possible, puisque le process disparaît. C’est plus lent, mais on conserve le bénéfice du copy-on-write. Et on peut mélanger les deux, en routant seulement certains chemins vers le mode fork :

"fork": { "patterns": ["legacy/.*", "unsafe-extension.php"] }

🚀 Démarrer avec Laravel ou WordPress

Pas de Composer à installer côté app. On clone le dépôt et on pointe le serveur sur son projet :

git clone https://github.com/Qbix/webserver
cd my-laravel-app
php /path/to/webserver/qbixserver.php --root=public --preset=laravel --port=8080

Pour WordPress, même principe avec --root=. --preset=wordpress. Les presets règlent les limites d’upload, la mémoire et le GC des sessions (64M d’upload pour WordPress, calé sur ce qu’affiche son uploader). La doc liste aussi Symfony, Drupal, Joomla et Magento comme compatibles sans modification.

Le composer.json du projet demande PHP 8.1 et ext-sockets. pcntl est présenté comme optionnel, mais sans lui on perd tout l’intérêt du copy-on-write : sous Windows, Qbix se replie d’ailleurs sur des sous-process php-cgi. Des binaires autonomes (PHP embarqué) sont publiés pour Linux, macOS et Windows.

🐳 Un Dockerfile pour Laravel

Qbix ne publie pas d’image Docker officielle. Voici celle que j’ai montée et testée sur un Laravel 13 fraîchement installé, avec Qbix v2.0.0 et PHP 8.4. Elle reprend le principe du build multi-stage pour Laravel : Composer dans une première étape, un runtime léger dans la seconde.

# Étape 1 : dépendances Composer
FROM composer:2 AS vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --no-autoloader --prefer-dist
COPY . .
RUN composer dump-autoload --optimize --no-dev --no-scripts
 
# Étape 2 : runtime Qbix
FROM php:8.4-cli-bookworm
 
RUN apt-get update && apt-get install -y --no-install-recommends git \
	&& docker-php-ext-install pcntl sockets pdo_mysql \
	&& rm -rf /var/lib/apt/lists/*
 
RUN git clone --depth 1 --branch v2.0.0 https://github.com/Qbix/webserver /opt/qbix
 
# Qbix v2.0.0 émet des notices Deprecated sous PHP 8.4 : on les garde hors des réponses
RUN printf 'display_errors=stderr\nerror_reporting=E_ALL & ~E_DEPRECATED\n' \
	> /usr/local/etc/php/conf.d/qbix.ini
 
WORKDIR /app
COPY --from=vendor --chown=www-data:www-data /app /app
# Qbix écrit ses logs dans local/ et ses clés mesh dans keys/, relatifs au dossier courant
RUN mkdir -p local/logs keys && chown -R www-data:www-data local keys
USER www-data
 
EXPOSE 8080
HEALTHCHECK CMD curl -fs http://127.0.0.1:8080/up || exit 1
CMD ["php", "/opt/qbix/qbixserver.php", "--root=public", "--preset=laravel", "--port=8080", "--config=/app/qbix.json"]

Et le fichier qbix.json à la racine du projet :

{
	"Q": {
		"webserver": {
			"forkPerRequest": true
		},
		"dashboard": false
	}
}

Trois choix méritent une explication, parce que je les ai tous appris en cassant le conteneur.

Le forkPerRequest: true d’abord. En mode persistant, la première requête passe, puis toutes les suivantes renvoient une 500 : Call to a member function handleRequest() on true. Le public/index.php de Laravel charge l’application avec require_once, et dans un worker qui a déjà exécuté ce fichier, require_once renvoie true au lieu de l’objet Application. En mode fork, chaque requête repart d’un process neuf et tout fonctionne. La promesse « Laravel sans modification » tient donc, mais pas dans le mode par défaut.

Ensuite "dashboard": false. Sans cette ligne, /Q/dashboard et /Q/health sont accessibles à n’importe qui sur le port exposé. Une fois le dashboard désactivé, /Q/health répond 404, d’où le healthcheck branché sur la route /up de Laravel. Dans mes tests, la page HTML de /Q/dashboard reste quand même servie (sans ses données temps réel) : derrière un reverse proxy, je bloquerais le préfixe /Q/ par précaution.

Enfin le fichier .ini. Sous PHP 8.4, Qbix v2.0.0 déclenche des notices « Creation of dynamic property » qui, avec la config par défaut de l’image, atterrissent directement dans le corps des réponses HTTP. Les renvoyer sur stderr suffit.

🧰 Ce qu’il y a dans la boîte

C’est la partie qui m’a le plus surpris, parce qu’on sort largement du rôle de serveur HTTP :

• HTTP, WebSocket et SSE sur le même port, avec des rooms à la Socket.IO ;
• les headers X-Accel-Redirect (fichiers protégés servis par le serveur après contrôle d’accès, comme avec nginx), X-Cache-Tree pour le cache de fragments, ETag et 304 ;
• redimensionnement d’images à la volée (?w=300) avec négociation AVIF/WebP ;
• TLS, cron et access log intégrés ;
• HTTP/2 via AMPHP en dépendance optionnelle.

La v2 ajoute une couche mesh (P2P chiffré sur Bluetooth, Wi-Fi ou TCP, synchronisation par filtres de Bloom et prolly trees) et un runtime iOS/Android. On parle là d’un projet aux ambitions très larges, bien au-delà du simple remplacement de FPM.

🎯 Qbix vs FrankenPHP et Swoole

Sur le fonctionnement, les trois outils ne jouent pas du tout la même partition :

Et les assets statiques ? Qbix les sert lui-même, sans nginx devant : ETag et réponses 304, compression, et redimensionnement d’images à la volée (?w=300) avec conversion automatique en AVIF ou WebP selon le navigateur. Pour un site qui servait ses images via nginx plus un service de resize séparé, c’est une brique de moins.

Le projet publie aussi des chiffres de débit, que je reprends tels quels :

À lire avec réserve : ce sont des mesures maison, et un FrankenPHP à 350 req/s en CPU-bound laisse penser à une config peu représentative (mode classique plutôt que worker mode ?). Notez d’ailleurs que sur les statiques, Swoole reste devant. À reproduire sur sa propre app avant d’y croire.

Ce qui me paraît solide, c’est l’argument structurel. En mémoire, un worker forké en COW coûte réellement très peu, et sur de l’I/O bloquant, plus de workers donne mécaniquement plus de débit. Côté compatibilité, Qbix n’exige aucune réécriture façon Swoole. En revanche, il n’offre ni HTTP/3 ni l’écosystème Caddy, et la communauté reste confidentielle (autour de 160 étoiles sur GitHub).

⚠️ Quelques précautions

Tout n’est pas remis à zéro entre deux requêtes. Le worker reste vivant, donc certaines choses créées pendant une requête sont encore là à la suivante. Qbix nettoie les variables de classe (les propriétés static) et les superglobales, mais pas le reste. Concrètement :

• une constante créée avec define() au milieu d’une requête existe toujours ensuite, et un second define() du même nom échouera ;
• un fichier ouvert, une connexion à la base ou un handle cURL restent ouverts, avec leurs réglages ;
• une extension PHP écrite en C peut garder sa propre mémoire interne, que Qbix ne voit pas.

La règle pratique : tout ce que votre code ouvre ou déclare pendant une requête, il doit le refermer ou le réinitialiser lui-même. C’est la même discipline qu’avec Laravel Octane. Et pour le code qui ne la respecte pas, le mode fork-per-request règle la question.

OPcache. Le code réécrit est compilé depuis la source transformée : la validation par fichier d’OPcache ne s’applique pas. Sans hot reload activé, il faut redémarrer après chaque déploiement.

Output buffering. Du code qui vide tous les buffers en boucle avec ob_end_flush() peut casser la capture de la réponse.

Tâches longues. Pour les migrations et scripts longs, la doc recommande --workers=1 ou, plus simplement, la CLI classique.

Maturité. Pas de package Packagist, une petite communauté, un périmètre qui s’étend vite. Pour de la prod critique, je testerais d’abord sur un service secondaire.

🎉 Conclusion

Qbix Server part d’une intuition juste : le modèle shared-nothing de PHP colle très bien au fork en copy-on-write, et c’est la mémoire par worker, plus que le CPU, qui plafonne FPM sur les apps I/O-bound. Le reset d’état par réécriture de fonctions et snapshot Reflection est astucieux, et le mode fork-per-request offre une vraie porte de sortie.

Pour une app Laravel ou Symfony en production, je reste sur FrankenPHP, plus mûr et mieux outillé. Mais Qbix mérite un banc d’essai si vos workers passent leur vie à attendre des I/O, ou si l’idée de livrer une app PHP en un seul binaire vous parle. Et si vous le testez, gardez un œil sur la mémoire réelle avec un outil comme Ember ou SigNoz : c’est là que les promesses se vérifient.

🔗 Liens utiles

• Site officiel de Qbix Server
• Dépôt GitHub Qbix/webserver
• Documentation de compatibilité (fonctions réécrites)
• Documentation du reset entre requêtes
• Notes de version