Pourquoi un runtime PHP managé est préférable à un VPS brut
Sur un VPS nu, vous êtes responsable de toute la pile : mises à jour de l'OS, pool PHP-FPM, configuration du serveur web, renouvellement TLS, règles de pare-feu, et démon de base de données. Si l'un de ces éléments dérive, le site casse, alors que la majorité de ce travail n'a rien à voir avec votre application. La plateforme PHP managée vous fournit un runtime PHP 8 pris en charge avec les extensions habituelles déjà présentes, si bien que votre responsabilité se réduit au code, à ses dépendances et à sa configuration — les seules parties qui vous appartiennent réellement.
Adapté aux frameworks Laravel et Symfony
Les frameworks modernes attendent une structure précise : une racine documentaire public/, un répertoire storage ou var accessible en écriture, et des dépendances gérées par Composer. La plateforme s'aligne directement là-dessus — vous définissez la racine documentaire sur public/ et gardez le reste de l'arborescence privé. L'extension phpredis est disponible sur le runtime, si bien qu'une application qui se connecte à son propre Redis fonctionne sans build sur mesure ; si vous voulez une instance Redis managée provisionnée pour vous, c'est un add-on des Container Apps.
Une base de données MySQL managée sans être DBA
Installer soi-même MySQL implique du tuning, des sauvegardes, de la gestion d'utilisateurs et un suivi des correctifs. Ici, la base de données arrive managée avec le compte : elle est provisionnée pour vous, les identifiants sont affichés dans le panneau, et vous les collez dans la configuration de votre application. Régénérer le mot de passe est une action du panneau, et le datastore est maintenu indépendamment de votre runtime applicatif.
Déployer simplement — et savoir où vit le pipeline Git
Tous les projets PHP ne sont pas sur Git, et un petit site ou une application legacy envoyé via le gestionnaire de fichiers peut être en ligne en quelques minutes — c'est le workflow autour duquel cette plateforme est construite. Quand un projet la dépasse et veut du déploiement au push, des étapes de build et des logs de déploiement, le bon foyer est les Container Apps avec GitHub Deploy : vous containerisez l'application une seule fois et obtenez là-bas le pipeline Git complet.
Cache edge et WAF devant votre PHP dynamique
Les applications PHP consomment un réel temps CPU pour générer les pages, si bien que servir les réponses cacheables directement depuis l'edge protège votre runtime de la charge. Vous décidez quelles routes peuvent être mises en cache sans risque — un catalogue public ou un article — et lesquelles doivent toujours s'exécuter, comme un tableau de bord authentifié ou un endpoint POST. Le WAF se trouve à l'edge, devant l'application, et filtre le trafic d'injection et de scan avant qu'il n'atteigne PHP, tandis qu'Auto SSL maintient le HTTPS valide sans cron de renouvellement.
Un chemin maîtrisé pour moderniser du PHP legacy
Les anciennes applications écrites pour PHP 5 ou un CMS non maintenu sont risquées à toucher, mais elles ne peuvent pas rester indéfiniment sur un runtime en fin de vie. La plateforme vous donne un endroit où apporter le code, migrer sa base de données vers MySQL managé avec le bon jeu de caractères, et l'exécuter sur PHP 8 où vous pouvez repérer et corriger les dépréciations. Vous validez sur une URL temporaire et placez le WAF devant une base de code qui ne reçoit plus de correctifs de sécurité, ce qui réduit la surface d'attaque publique avant même que le code ne soit entièrement nettoyé.
Comment déployer, étape par étape
Créer l'application PHP et choisir le runtime
Dans le panneau, ouvrez Platform, choisissez PHP, puis sélectionnez la version PHP 8 et le plan. Le runtime embarque les extensions courantes attendues par les applications PHP — PDO, mbstring, GD, OpenSSL, et l'extension Redis — vous n'avez donc pas besoin d'ouvrir un ticket pour activer une extension.
Mettre votre code sur la plateforme
Envoyez votre application via le gestionnaire de fichiers intégré — pour les applications basées sur un framework, vous définissez la racine documentaire sur le répertoire public/ et gardez le reste de l'arborescence privé. Si votre équipe veut un déploiement Git au push avec des étapes de build, ce workflow est exactement ce à quoi servent les Container Apps avec GitHub Deploy ; la plateforme PHP garde le déploiement délibérément simple.
Connecter la base de données MySQL managée
Une base de données MySQL managée est provisionnée avec votre compte d'hébergement. Son hôte, son nom, son utilisateur et son mot de passe sont affichés dans le panneau — vous les placez vous-même dans le .env ou la configuration de votre application, et vous pouvez réinitialiser le mot de passe depuis le panneau à tout moment sans toucher au serveur de base de données, car il n'y a aucun serveur de base de données à faire tourner de votre côté.
Pointer le domaine et émettre l'Auto SSL
Attachez votre domaine ou un sous-domaine name.cdn.com.tr, et Auto SSL émet et renouvelle le certificat pour l'apex et le www. Le trafic atteint désormais d'abord l'edge cdn.com.tr, où la terminaison SSL a lieu avant que les requêtes ne soient proxifiées vers votre runtime PHP.
Configurer le cache edge et les règles WAF
Définissez quelles routes sont cacheables à l'edge et lesquelles doivent toujours passer par PHP, et appliquez un profil WAF. Les réponses cacheables sont servies depuis l'edge sans réveiller votre runtime, et une purge depuis le panneau ou l'API les efface instantanément après l'envoi d'une nouvelle release.
Exemples de scénarios
Une application Laravel tourne sur le runtime PHP 8 managé avec la base de données MySQL managée, servie derrière Auto SSL, le cache edge et le WAF.
Un ancien portail sous CMS maison est migré vers PHP 8 avec une base de données managée, placé derrière le WAF, et modernisé route par route sans interruption de service.
Une API PHP écrite à la main tourne sur le runtime managé avec la base de données MySQL managée, exposée sur un domaine avec terminaison SSL à l'edge et filtrage WAF en amont.
Questions fréquentes
Quelles extensions PHP sont disponibles sur le runtime ?
Le runtime PHP 8 embarque les extensions dont dépendent les applications classiques — PDO et les pilotes MySQL, mbstring, GD pour la gestion d'images, OpenSSL, cURL, et l'extension phpredis pour les applications qui se connectent à un Redis qui leur appartient. Le jeu d'extensions étant standard, Laravel, Symfony et la plupart des paquets Composer s'installent sans build sur mesure.
Puis-je exécuter un worker de queue Laravel ou des tâches planifiées ?
Pas sur la plateforme PHP — elle exécute votre application à la requête web et n'a ni worker ni gestionnaire de cron. Si votre application dépend de workers de queue ou de tâches planifiées, exécutez-la plutôt comme Container App : les conteneurs sont des processus persistants, et cette plateforme propose aussi Redis managé comme backend de queue.
Comment les identifiants de base de données parviennent-ils à mon application ?
Les identifiants MySQL managés — hôte, nom de base, utilisateur, mot de passe — sont affichés dans le panneau. Vous les placez dans votre fichier .env ou de configuration sur la plateforme (hors du chemin servi sur le web), si bien qu'ils n'ont jamais besoin d'être versionnés dans Git, et vous pouvez réinitialiser le mot de passe depuis le panneau sans ticket de support.
Mon application cible PHP 7 — fonctionnera-t-elle sur PHP 8 ?
La majorité du code maintenu tourne sur PHP 8 avec des ajustements mineurs, mais PHP 8 a supprimé certains comportements dépréciés. La bonne approche consiste à apporter le code sur la plateforme, à l'exécuter sur une URL temporaire, et à corriger les dépréciations rencontrées avant de basculer le domaine — le runtime managé vous offre précisément un endroit sûr pour cela.
Dois-je définir la racine documentaire sur public/ ?
Oui. Pour Laravel, Symfony et les frameworks similaires, vous pointez la racine web vers le répertoire public/ afin que le reste de l'arborescence applicative — y compris .env, vendor et storage — reste hors du chemin servi sur le web. Les applications legacy qui servent depuis leur répertoire racine sont également prises en charge ; vous configurez la racine en conséquence.
Comment gérer les fichiers uploadés qui doivent survivre à un redéploiement ?
L'application dispose d'un volume persistant pour les données utilisateur, et pour les applications riches en médias, vous pouvez décharger les uploads vers l'Object Storage et les servir via le CDN plutôt que via le runtime. Cela garde les déploiements rapides et sans état, et signifie qu'un redéploiement ou un événement de scaling ne met jamais en danger les fichiers uploadés.