[{"data":1,"prerenderedAt":252},["ShallowReactive",2],{"seo-verification":3,"blog-php2shell-docker-wordpress-reconstruire-images-php-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-php2shell-docker-wordpress-reconstruire-images-php-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":190,"ctaBody":191,"ctaButton":192,"ctaUrl":193,"relatedPosts":194},501,"php2shell-docker-wordpress-reconstruire-images-php",{"fr":10,"en":12,"ar":13,"es":14},"php2shell-docker-rebuild-php-wordpress-images","php2shell-docker-إعادة-بناء-صور-php-ووردبريس","php2shell-docker-reconstruir-imagenes-php-wordpress","PHP2Shell et Docker : reconstruire vos images PHP et WordPress","WordPress ou Laravel à jour ne change pas le PHP de l'image Docker. Prouvez la version servie, repérez les tags qui ont bougé et reconstruisez sans piège.",12,0,false,"2026-10-23T00:00:00+00:00","2026-10-23T23:43:01+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fphp2shell-docker-wordpress-reconstruire-images-php-poster.svg",{"categorySlug":34,"appSlug":35},"cms","wordpress","Vous avez mis WordPress à jour la semaine dernière, relancé le conteneur, et vous pensez être couvert contre PHP2Shell. Ce n'est pas certain : dans un conteneur, le PHP vit dans l'image, pas dans l'application, et un redémarrage réutilise l'image déjà présente sur le disque. Les correctifs PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sortis le 21 octobre 2026. Ce guide montre comment prouver, conteneur par conteneur, quel PHP répond vraiment, puis comment retirer ou reconstruire l'image qui n'est pas corrigée, pour WordPress, Nextcloud, Laravel Octane et une image maison.",[38,42,52,68,71,86,89,127,130,145,148,151,160,187],{"type":39,"title":40,"body":41},"h2","Pourquoi mettre à jour l'application ne change pas le PHP","Une mise à jour de WordPress, un `composer update` ou une nouvelle version de Nextcloud remplacent des fichiers de l'application. L'interpréteur PHP, lui, est un programme installé dans l'image Docker, au même titre que le système Debian ou Alpine qui l'entoure. Tant que l'image ne change pas, le PHP ne change pas, quel que soit le nombre de mises à jour de l'application.\n\nLe second piège est le redémarrage. `docker restart` relance le conteneur existant, donc la même image. `docker compose up -d` ne va pas chercher une version plus récente quand une image portant ce nom existe déjà sur le serveur : il réutilise la copie locale. Seul un `pull` ou un `build --pull`, suivi d'une recréation du conteneur, change l'interpréteur.\n\nLes deux failles et les commandes `apt` ou `dnf` sont détaillées dans \u003Ca href=\"\u002Fblog\u002Fphp2shell-cve-2026-109618-109619-mettre-a-jour-php\">notre guide de mise à jour de PHP\u003C\u002Fa>. Ici, il s'agit de l'image Docker et de la preuve qu'elle est la bonne.",{"type":43,"title":44,"items":45},"ul","Six objets à ne pas confondre",[46,47,48,49,50,51],"**L'image du registre** — ce que Docker Hub ou votre registre privé sert aujourd'hui sous une étiquette comme `php:8.3-fpm`. Une étiquette est mobile : elle pointe vers un autre contenu après chaque reconstruction.","**L'image locale** — la copie présente sur votre serveur, visible avec `docker image ls`. Elle ne bouge que si vous tirez ou construisez une image.","**Le conteneur en cours** — il garde l'identifiant de l'image avec laquelle il a été créé, même si une image plus récente porte désormais le même nom.","**Le processus qui répond** — PHP-FPM, Apache avec `mod_php` ou FrankenPHP. C'est lui qui est exposé, et `php -v` ne l'interroge pas.","**Les autres services** — worker de file, planificateur, conteneur `cli` de maintenance : chacun a sa propre image, donc sa propre version de PHP.","**Le cache de construction** — une couche `FROM` en cache peut rejouer l'ancienne base sans qu'aucune erreur ne s'affiche.",{"type":53,"title":54,"steps":55},"steps","Comparer le registre, l'image locale et le conteneur",[56,59,62,65],{"title":57,"body":58},"Lister les images locales et leur date","`docker image ls php` (ou `wordpress`, `nextcloud`). La colonne `CREATED` indique quand l'image a été construite. Une image `php:8.3-fpm` créée avant le 21 octobre 2026 ne contient pas le correctif.",{"title":60,"body":61},"Lire l'image de chaque conteneur","`docker ps` affiche dans la colonne `IMAGE` l'étiquette demandée à la création. Pour obtenir l'identifiant réel de l'image utilisée, interrogez le conteneur : `docker inspect --format '{{.Image}}' \u003Cconteneur>`.",{"title":63,"body":64},"Comparer avec l'image présente sur le disque","`docker image inspect --format '{{.Id}}' php:8.3-fpm` rend l'identifiant de l'image qui porte aujourd'hui ce nom. Si cet identifiant diffère de celui du conteneur, le conteneur tourne sur une image plus ancienne que celle du disque : il n'a jamais été recréé après le dernier tirage.",{"title":66,"body":67},"Comparer avec le registre","`docker pull php:8.3-fpm` termine par une ligne `Status: Downloaded newer image for …` quand une image plus récente est arrivée, ou `Status: Image is up to date for …` sinon. Dans le second cas, soit votre copie est déjà la dernière, soit l'étiquette n'a pas encore été republiée : confrontez-la à la date de l'étiquette sur Docker Hub.",{"type":39,"title":69,"body":70},"Lire la version que le web sert vraiment","`php -v` interroge le programme en ligne de commande, pas le processus qui répond aux requêtes. La constante `PHP_SAPI` dit lequel parle : `cli` en ligne de commande, `fpm-fcgi` pour PHP-FPM, `apache2handler` pour Apache avec `mod_php`. Dans une image unique, les deux versions coïncident presque toujours. L'écart apparaît dans trois situations courantes avec Docker : un `docker compose run` démarre un conteneur neuf, donc depuis l'image locale la plus récente, alors que le service web tourne toujours sur l'ancienne ; un conteneur `cli` de maintenance est bâti sur une autre étiquette que le service web ; un reverse proxy renvoie vers un autre conteneur que celui que vous inspectez.\n\nLa preuve la plus fiable reste la requête HTTP : elle suit le chemin d'un visiteur et lit `PHP_VERSION` dans le processus qui répond. Le binaire FPM se contrôle en complément avec `docker exec \u003Cconteneur> php-fpm -v`.",{"type":53,"title":72,"steps":73},"Prouver la version servie, service par service",[74,77,80,83],{"title":75,"body":76},"Déposer un fichier de test dans le dossier servi","Exemple avec le service `wordpress` de l'image officielle, dont le dossier web est `\u002Fvar\u002Fwww\u002Fhtml` (adaptez le service et le chemin à votre stack) : `docker compose exec wordpress sh -c 'echo \"\u003C?php echo PHP_VERSION, \\\" \\\", PHP_SAPI;\" > \u002Fvar\u002Fwww\u002Fhtml\u002Fv-check.php'`",{"title":78,"body":79},"L'interroger par HTTP, puis le supprimer aussitôt","`curl -s https:\u002F\u002Fvotre-domaine.com\u002Fv-check.php` puis `docker compose exec wordpress rm \u002Fvar\u002Fwww\u002Fhtml\u002Fv-check.php`. La réponse donne la version suivie du SAPI. Comparez-la aux versions corrigées : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche. Un numéro inférieur pour votre branche signifie que le correctif n'est pas là.",{"title":81,"body":82},"Contrôler le binaire FPM du conteneur","`docker exec \u003Cconteneur> php-fpm -v` affiche la version et le SAPI du binaire FPM de ce conteneur précis. Avec une image Apache, la requête HTTP de l'étape précédente suffit : `mod_php` est chargé par Apache.",{"title":84,"body":85},"Ne pas se fier à docker compose run","`docker compose run` crée un conteneur neuf à partir de l'image locale. Il peut annoncer la version corrigée pendant que le conteneur du site, lui, n'a pas bougé. Contrôlez toujours le conteneur qui reçoit le trafic.",{"type":39,"title":87,"body":88},"Tags flottants et tags pinnés : qui avance tout seul","Une étiquette de branche comme `php:8.3-fpm` avance au prochain `pull` : elle pointe alors vers la version corrigée. Une étiquette exacte comme `php:8.3.36-fpm` reste sur sa version, et une référence par empreinte (`@sha256:…`) ne bouge jamais. La documentation de `docker image pull` est explicite : avec une empreinte, Docker ne récupère aucune reconstruction, correctifs de sécurité compris, tant que vous ne changez pas l'empreinte vous-même.\n\nLes étiquettes corrigées de l'image officielle `php` sont arrivées sur Docker Hub dans la journée et la soirée du 21 octobre 2026 (UTC), pour les variantes FPM des branches 8.5, 8.4, 8.3 et 8.2. Les images WordPress officielles `php8.3-fpm`, `php8.4-fpm` et `php8.3-apache` ont été republiées le 22 octobre 2026 au petit matin (UTC), et celles de Nextcloud le même jour. Une image tirée avant ces moments est donc l'ancienne, même si son nom est identique. Relisez ces dates sur la page de chaque étiquette. La branche 8.2 reçoit son correctif mais atteint sa fin de vie le 31 décembre 2026 : planifiez son remplacement.",{"type":90,"title":91,"headers":92,"rows":96},"comparison","Quelle écriture avance, laquelle reste figée",[93,94,95],"Dans votre compose ou Dockerfile","Avance au prochain pull ?","Pour obtenir le PHP corrigé",[97,101,105,108,112,115,119,123],[98,99,100],"`php:8.3-fpm`","Oui, l'étiquette est republiée","`pull` ou `build --pull`, puis recréer le conteneur",[102,103,104],"`php:8.3.36-fpm`","Non, version exacte","Déjà corrigé ; à changer à la main au prochain correctif",[106,103,107],"`php:8.3.\u003Cn>-fpm` avec n inférieur à 36","Passer à une étiquette corrigée, reconstruire, recréer",[109,110,111],"`wordpress:php8.3-fpm`","Oui, l'éditeur la republie","`pull`, puis recréer le service",[113,114,111],"`wordpress:\u003Cx.y>-php8.3-fpm`","Oui pour le PHP : l'éditeur la republie",[116,117,118],"`php:8.3-fpm@sha256:…`","Jamais","Remplacer l'empreinte par celle d'une image corrigée",[120,121,122],"`FROM php:8.3-fpm` dans votre Dockerfile","Seulement si vous construisez avec `--pull`","`build --pull`, puis recréer le conteneur",[124,125,126],"`image: monregistre\u002Fapp:latest` (votre image)","Non, c'est votre dernière construction","Reconstruire, republier, puis tirer et recréer",{"type":39,"title":128,"body":129},"Image maison : la séquence et ce que chaque option change","Pour une image construite chez vous à partir de `FROM php:8.3-fpm`, la séquence tient en trois commandes : `docker compose build --pull --no-cache`, puis `docker compose up -d --force-recreate`, puis le contrôle de la version servie. Chacune répond à un piège précis.\n\n`--pull` est l'option qui change la version de PHP : elle demande à Docker de chercher une version plus récente de l'image de base au lieu de réutiliser celle du serveur. Sans elle, le `FROM` est résolu avec la copie locale, et la construction réussit avec l'ancien interpréteur, sans le moindre message.\n\n`--no-cache` rejoue toutes les couches, y compris `apt-get` et `composer install`, ce qui renouvelle aussi les bibliothèques système et les dépendances. Il n'est pas nécessaire pour changer de PHP, car quand l'image de base change, les couches suivantes sont reconstruites d'elles-mêmes. Il sert quand une couche en cache fige un paquet à renouveler.\n\n`--force-recreate` recrée les conteneurs même si Compose estime que leur configuration et leur image n'ont pas changé. C'est ce qui supprime le doute sur ce qui tourne.\n\nReconstruire ses images à chaque correctif est un calendrier à tenir, pas un geste unique. Sur un VPS en accès root, ce calendrier est le vôtre, et \u003Ca href=\"\u002Fblog\u002Fdemarrer-avec-docker-vps\">notre guide d'installation de Docker sur VPS\u003C\u002Fa> pose la base de travail.",{"type":53,"title":131,"steps":132},"Reconstruire et recréer une image maison",[133,136,139,142],{"title":134,"body":135},"Vérifier que l'étiquette de base est corrigée","Ouvrez la page de votre étiquette de base sur Docker Hub et vérifiez qu'elle a été publiée à partir du 21 octobre 2026. Si votre `FROM` vise une version exacte plus ancienne, changez-la d'abord.",{"title":137,"body":138},"Reconstruire en tirant la base","`docker compose build --pull --no-cache`. Notez la version avant l'opération avec le fichier de test, pour avoir un avant et un après.",{"title":140,"body":141},"Recréer les conteneurs","`docker compose up -d --force-recreate`. Une seule commande peut aussi enchaîner les trois temps : `docker compose up -d --build --pull always`. Recréez tous les services qui utilisent l'image : web, worker de file, planificateur.",{"title":143,"body":144},"Prouver le résultat","Relancez le fichier de test, puis comparez l'identifiant donné par `docker inspect --format '{{.Image}}' \u003Cconteneur>` à celui de `docker image ls`. L'ancienne et la nouvelle image peuvent porter le même nom : seuls l'identifiant et la réponse HTTP font foi.",{"type":39,"title":146,"body":147},"WordPress et Nextcloud officiels : le PHP vient de l'étiquette","Une étiquette WordPress combine une version de WordPress, une version de PHP et une variante, par exemple `php8.3-apache` ou `php8.3-fpm`. La branche PHP est choisie par le nom de l'étiquette. Changer de version de WordPress, ou laisser les mises à jour automatiques agir dans le volume de données, ne touche pas à cette branche. Pour obtenir le PHP corrigé, il faut re-tirer l'étiquette avec `docker compose pull`, puis recréer le service. La variante Apache est la variante par défaut, et elle charge PHP en `mod_php` : c'est celle que le projet PHP juge la plus exposée, avec un exploit démontré avant l'exécution du moindre code applicatif. Traitez-la en priorité.\n\nNextcloud suit le même principe, en deux variantes : `apache` embarque un Apache complet, `fpm` demande un serveur web devant lui. La documentation de l'image décrit la mise à jour comme un remplacement : tirer l'image, jeter l'ancien conteneur, démarrer le nouveau. Le code de Nextcloud et vos données vivent dans le volume `\u002Fvar\u002Fwww\u002Fhtml`, que la recréation du conteneur n'efface pas. Voir \u003Ca href=\"\u002Fblog\u002Fheberger-wordpress\">notre guide WordPress sur VPS\u003C\u002Fa> et \u003Ca href=\"\u002Fblog\u002Fheberger-nextcloud\">celui de Nextcloud\u003C\u002Fa>.",{"type":39,"title":149,"body":150},"Laravel Octane et FrankenPHP : le moteur est dans l'image","Avec Octane et FrankenPHP, il n'y a pas de PHP-FPM : le serveur d'application embarque l'interpréteur. Les images officielles de FrankenPHP reposent sur les images PHP officielles, et leur étiquette combine la version de FrankenPHP, celle de PHP et le système, sous la forme `dunglas\u002Ffrankenphp:\u003Cversion>-php8.4-trixie`. Le projet les reconstruit à chaque version et, chaque jour à 4 h UTC, si de nouvelles images PHP officielles existent. Votre `FROM dunglas\u002Ffrankenphp` ne reçoit le correctif que si vous reconstruisez votre image avec `--pull`.\n\nLe piège propre à Octane est le worker. Octane démarre l'application une fois et la garde en mémoire : `php artisan octane:reload` relance proprement les workers pour charger le code déployé. C'est le bon geste après un déploiement de code, mais il ne remplace pas l'interpréteur, qui reste celui de l'image en cours. Il en va de même pour un `kill -USR2` ou un rechargement de PHP-FPM lancé dans l'ancien conteneur : ils relancent les mêmes fichiers, ceux de l'ancienne image. Pour changer de PHP, recréez le conteneur, y compris ceux des workers de file et du planificateur. Voir \u003Ca href=\"\u002Fblog\u002Fdeployer-laravel-vps-octane\">notre guide Laravel Octane sur VPS\u003C\u002Fa>.",{"type":43,"title":152,"items":153},"Pièges d'infrastructure qui rejouent l'ancienne image",[154,155,156,157,158,159],"**Cache de build de la CI** — un cache de couches restauré peut rejouer la couche `FROM`. Ajoutez `--pull` à la commande de build de la CI, ou invalidez le cache pour cette étape.","**Registre privé ou miroir** — si vos serveurs tirent depuis un registre interne qui copie les images à la main ou par tâche planifiée, vérifiez qu'il a recopié l'étiquette. Sinon `pull` répond `Image is up to date` alors que l'éditeur a republié.","**Stack Portainer ou outil d'orchestration** — la mise à jour d'une stack ne re-tire pas toujours l'image. Cochez l'option de re-téléchargement avant le redéploiement si votre outil en propose une.","**`pull_policy: missing`** — c'est la valeur par défaut de Compose sans section `build` : il ne tire que si l'image est absente du serveur. Seule l'étiquette `latest` est tirée dans tous les cas. Utilisez `always`, ou `daily` et `weekly` pour vérifier le registre à intervalle fixe.","**Un service oublié** — web, worker, planificateur et conteneur `cli` construits depuis des Dockerfile séparés ont chacun leur base : corrigez-les tous.","**Un conteneur orphelin** — un `docker run` oublié ou un autre projet Compose peut encore répondre sur un port. Listez tout ce qui tourne avec `docker ps`.",{"type":90,"title":161,"headers":162,"rows":166},"Dépannage : ce que vous voyez, ce que cela veut dire",[163,164,165],"Ce que vous constatez","Cause probable","Remède",[167,171,175,179,183],[168,169,170],"`pull` affiche `Status: Image is up to date` mais la version reste ancienne","L'étiquette n'a pas encore été republiée, ou vous tirez une version exacte ou une empreinte","Comparer avec la date de l'étiquette sur Docker Hub, puis passer à une étiquette corrigée",[172,173,174],"`up -d` ne change rien après un tirage","Le conteneur existant n'a pas été recréé","`docker compose up -d --force-recreate`, puis comparer les identifiants d'image",[176,177,178],"Le build se termine en quelques secondes, avec la base déjà en cache","`--pull` absent : la base du serveur est réutilisée","`docker compose build --pull`, avec `--no-cache` si des paquets système doivent aussi être renouvelés",[180,181,182],"`docker compose run` annonce la version corrigée, le site répond l'ancienne","`run` crée un conteneur neuf, le service web n'a pas été recréé","Contrôler par HTTP le conteneur qui reçoit le trafic, puis le recréer",[184,185,186],"La version est bonne mais un worker se comporte comme avant","Un worker de file ou Octane tourne encore dans un ancien conteneur","Recréer tous les conteneurs qui utilisent l'image, pas seulement le service web",{"type":39,"title":188,"body":189},"La documentation officielle","Les sources : \u003Ca href=\"https:\u002F\u002Fwww.php.net\u002Farchive\u002F2026.php\">les annonces de sécurité et de versions de PHP\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.docker.com\u002Freference\u002Fcli\u002Fdocker\u002Fcompose\u002Fup\u002F\">docker compose up\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.docker.com\u002Freference\u002Fcli\u002Fdocker\u002Fcompose\u002Fbuild\u002F\">docker compose build\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.docker.com\u002Freference\u002Fcompose-file\u002Fservices\u002F#pull_policy\">l'attribut pull_policy\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.docker.com\u002Freference\u002Fcli\u002Fdocker\u002Fimage\u002Fpull\u002F\">docker image pull\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fhub.docker.com\u002F_\u002Fphp\">l'image php\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fhub.docker.com\u002F_\u002Fwordpress\">l'image wordpress\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fnextcloud\u002Fdocker\">l'image Nextcloud\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Ffrankenphp.dev\u002Fdocs\u002Fdocker\u002F\">FrankenPHP avec Docker\u003C\u002Fa> et \u003Ca href=\"https:\u002F\u002Flaravel.com\u002Fdocs\u002F12.x\u002Foctane\">Laravel Octane\u003C\u002Fa>.","Un VPS où vous tenez vos images et leur calendrier","Sur un VPS ServOrbit.com, vous avez l'accès root et une IPv4 dédiée : vos images Docker, leurs étiquettes et le moment de chaque reconstruction sont les vôtres. Une option d'administration VPS existe aussi ; ses modalités sont décrites sur la page de l'offre.","Découvrir les VPS","\u002Fvps-cloud",[195,212,232],{"id":196,"slug":197,"slugs":198,"title":202,"excerpt":203,"readTime":204,"views":205,"isPinned":19,"publishedAt":206,"updatedAt":207,"category":208,"categories":209,"featuredImage":30,"bgImage":31,"posterImage":211,"relatedSolution":30},489,"php2shell-cve-2026-109618-109619-mettre-a-jour-php",{"fr":197,"en":199,"ar":200,"es":201},"php2shell-cve-2026-109618-109619-patch-php","php2shell-cve-2026-109618-109619-تحديث-php","php2shell-cve-2026-109618-109619-actualizar-php","PHP2Shell : corriger CVE-2026-109618 et CVE-2026-109619","PHP2Shell : deux failles critiques de PHP exploitables sans compte. Versions corrigées, commandes de mise à jour par système et parades temporaires.",9,1,"2026-10-22T00:00:00+00:00","2026-10-22T01:57:44+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[210],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fphp2shell-cve-2026-109618-109619-mettre-a-jour-php-poster.svg",{"id":213,"slug":214,"slugs":215,"title":219,"excerpt":220,"readTime":221,"views":18,"isPinned":19,"publishedAt":222,"updatedAt":21,"category":223,"categories":228,"featuredImage":30,"bgImage":31,"posterImage":230,"relatedSolution":231},73,"heberger-wordpress",{"fr":214,"en":216,"ar":217,"es":218},"host-wordpress-on-your-own-vps","استضافة-wordpress-على-خادم-vps-الخاص-بك","alojar-wordpress-en-un-vps","Héberger WordPress sur votre propre VPS","Hébergez WordPress sur votre VPS pour des performances et un contrôle maximaux : Docker, MariaDB, cache, reverse proxy et SSL.",7,"2026-04-08T00:00:00+00:00",{"id":221,"name":224,"slug":225,"color":226,"icon":227},"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[229],{"id":221,"name":224,"slug":225,"color":226,"icon":227},"\u002Fblog\u002Fcovers\u002Fheberger-wordpress-poster.svg",{"categorySlug":225,"appSlug":35},{"id":233,"slug":234,"slugs":235,"title":238,"excerpt":239,"readTime":240,"views":18,"isPinned":19,"publishedAt":241,"updatedAt":242,"category":243,"categories":249,"featuredImage":30,"bgImage":31,"posterImage":251,"relatedSolution":30},436,"deployer-laravel-vps-octane",{"fr":234,"en":236,"ar":237,"es":236},"laravel-octane-vps-frankenphp-docker-traefik","laravel-octane-على-vps-frankenphp-docker-traefik","Laravel Octane sur VPS : FrankenPHP, Docker et Traefik","Migrer vers Laravel Octane avec FrankenPHP en Docker Compose derrière Traefik : cycle de vie partagé, checklist compatibilité et zero-downtime en production.",11,"2026-10-12T00:00:00+00:00","2026-10-13T14:10:28+00:00",{"id":244,"name":245,"slug":246,"color":247,"icon":248},4,"Développement","developpement","bg-warning\u002F10 text-warning","dev",[250],{"id":244,"name":245,"slug":246,"color":247,"icon":248},"\u002Fblog\u002Fcovers\u002Fdeployer-laravel-vps-octane-poster.svg",1792799336174]