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, des dépendances gérées par Composer, et un endroit où exécuter les migrations de base de données lors du déploiement. La plateforme s'aligne directement là-dessus — vous définissez la racine documentaire sur public/, gardez le reste de l'arborescence privé, et intégrez composer install ainsi que les commandes de migration artisan/console dans les étapes de déploiement. Redis est disponible pour le cache, les files d'attente et les sessions, exactement ce dont a besoin un worker de queue Laravel ou un pool de cache Symfony.
MySQL et Redis managés sans être DBA
Installer soi-même MySQL et Redis implique du tuning, des sauvegardes, de la gestion d'utilisateurs et un suivi des correctifs. Ici, les deux sont des add-ons managés : vous les provisionnez, et leur hôte, port, utilisateur et mot de passe sont injectés dans l'environnement de l'application plutôt que collés dans un fichier de configuration. Cela garde les secrets hors de votre historique Git, permet de régénérer un mot de passe de base de données sans redéployer le code, et fait que le datastore est maintenu indépendamment du runtime applicatif.
Déployer à votre façon
Tous les projets PHP ne sont pas encore sur Git, et ce n'est pas un problème. Un petit site ou une application legacy peut être envoyé via le gestionnaire de fichiers et être en ligne en quelques minutes. Une équipe disposant d'un dépôt connecte Git ou GitHub et obtient un déploiement au push avec des étapes de build définies — composer install, un build front-end, des migrations — si bien que les releases sont reproductibles au lieu d'un glisser-déposer SFTP où quelqu'un oublie toujours un fichier. Le statut de déploiement et l'heure du dernier déploiement sont visibles dans le panneau.
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
Utilisez le gestionnaire de fichiers intégré pour un envoi rapide, ou connectez un dépôt Git/GitHub afin qu'un push déploie l'application. Pour les applications basées sur un framework, vous définissez la racine documentaire sur le répertoire public/ et configurez une fois pour toutes les étapes de build et de migration.
Attacher une base de données managée et Redis
Provisionnez une base de données MySQL managée et, si l'application a besoin de cache, de files d'attente ou de sessions, une instance Redis managée. Les valeurs de connexion sont injectées dans le runtime sous forme de variables d'environnement, si bien que les identifiants restent hors de votre .env versionné et peuvent être régénérés depuis le panneau.
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, le WAF et les étapes de déploiement
Définissez quelles routes sont cacheables à l'edge et lesquelles doivent toujours passer par PHP, appliquez un profil WAF, et figez le pipeline de déploiement — par exemple composer install, un build d'assets, et des migrations de base de données — afin que chaque release exécute exactement les mêmes étapes et se termine par une purge automatique.
Exemples de scénarios
Une application Laravel se déploie depuis GitHub avec composer install et des migrations, utilise MySQL managé et une queue Redis, et est servie derrière Auto SSL 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 Redis pour le rate-limit et l'état de session, exposée sur un domaine avec terminaison SSL à l'edge.
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 Redis utilisée pour le cache, les sessions et les files d'attente. 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 ?
Oui. Redis est disponible comme backend de queue, et la plateforme fait tourner votre application sur un runtime persistant plutôt que dans un bac à sable par requête, si bien que le traitement en arrière-plan et les tâches planifiées s'intègrent naturellement au modèle. Vous définissez les commandes dans la configuration de l'application plutôt que d'éditer une crontab système sur un serveur que vous devriez sinon gérer vous-même.
Comment les identifiants de base de données parviennent-ils à mon .env sans versionner de secrets ?
Les détails de connexion à la base de données managée et à Redis sont injectés dans l'environnement du runtime. Votre framework les lit depuis l'environnement de la même façon qu'il lit déjà les valeurs .env, si bien que vous ne versionnez jamais l'hôte, l'utilisateur ou le mot de passe dans Git, et régénérer un mot de passe depuis le panneau ne nécessite aucun changement de code.
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.