Cloudways est pratique parce que tu n’as pas à jouer au sysadmin. Sauf que Laravel, lui, s’en fiche de ton confort : il veut une arborescence propre, un public en webroot, des droits cohérents sur storage, et des assets buildés comme il faut. Et si tu rates un seul de ces détails, tu te retrouves avec une app “déployée” qui renvoie des 404, des 500, ou un écran blanc bien silencieux.
Voilà les 7 points qui font perdre une journée à plein d’équipes sur Cloudways. Pas de théorie, juste ce qui casse en vrai et comment le régler proprement.
1) Le webroot : Cloudways sert public_html, Laravel veut public
Le piège numéro 1, c’est la racine web. Par défaut, Cloudways sert ton dossier public_html. Sauf que dans Laravel, le dossier qui doit être exposé, c’est public. Si tu laisses Cloudways pointer sur public_html, tu vas soit exposer des fichiers que tu ne veux jamais exposer (coucou .env si un jour quelqu’un fait n’importe quoi), soit avoir un routing cassé, soit te battre avec des réécritures.
La solution simple, c’est d’avoir ton projet Laravel dans public_html et de dire à Cloudways que le webroot est public_html/public. Sur Cloudways, ça se règle côté application dans les settings (le nom exact change selon l’UI, mais l’idée reste la même : tu modifies le « Webroot »).
Petit détail qui pique : si ton webroot est bon mais que tu as encore des 404, vérifie que ton public/.htaccess est bien présent (si tu es en stack Apache derrière Nginx) et que tu n’as pas déployé un Laravel incomplet. Ça arrive plus souvent qu’on ne veut l’admettre, surtout avec des déploiements Git mal configurés.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
2) Le “déploiement Git” Cloudways : pratique, mais pas magique
Cloudways propose un déploiement via Git. Ça marche, mais il faut le voir comme un git pull assisté, pas comme un pipeline CI. Le code arrive sur le serveur, point. Si tu n’enchaînes pas derrière avec Composer, le cache, les migrations et le build des assets, tu vas déployer une moitié d’application.
Le truc qui fait gagner du temps, c’est d’utiliser les « deployment hooks » (ou l’équivalent) pour exécuter des commandes après le pull. Sinon tu finis en SSH à la main, et “à la main” en prod veut dire “un jour je vais oublier une étape”.
3) composer install en prod : les bons flags, sinon tu souffres
Sur Cloudways, tu peux installer les dépendances via SSH. En production, tu veux éviter d’installer les packages de dev, tu veux une autoload optimisée, et tu veux limiter les interactions. Le combo classique tourne bien.
cd /home/master/applications/APP_ID/public_html
# Dépendances PHP pour la prod
composer install --no-dev --prefer-dist --no-interaction --optimize-autoloader
# Cache Laravel (à faire après avoir mis à jour le .env)
php artisan config:cache
php artisan route:cache
php artisan view:cache
# Migrations en prod
php artisan migrate --force
# Si tu as des queues
php artisan queue:restartDeux mises en garde très terrain. D’abord, si tu caches la config et que ton .env change ensuite, tu peux avoir l’impression que Laravel “ignore” tes variables. Il ne les ignore pas : il lit son cache. Ensuite, ne lance pas des commandes Artisan au hasard si ton user/permissions sont incohérents, tu vas créer des fichiers appartenant au mauvais utilisateur et tu vas t’auto-saboter pour le prochain déploiement.
4) Permissions : storage et bootstrap/cache doivent être écrivable, mais pas en mode cowboy
Le deuxième grand classique, c’est l’erreur sur storage (logs, sessions, cache) et bootstrap/cache. Si ce n’est pas écrivable par le process PHP, tu vas voir passer des erreurs du style « failed to open stream » ou « permission denied », parfois juste un 500 sans détail si ton logging est lui-même bloqué.
La fausse bonne idée, c’est de passer tout en 777. Ça “répare” vite, et ça laisse une dette de sécurité et de maintenance. Sur Cloudways, l’approche saine, c’est de garder une propriété cohérente (le même user/groupe que celui utilisé par l’app) et d’ouvrir les droits juste comme il faut sur ces deux dossiers. Si tu ne sais pas quel user exécute PHP, regarde les fichiers créés quand tu fais un hit sur l’app ou quand tu lances une commande artisan, tu auras vite le coupable.
Un symptôme très parlant : les pages publiques marchent, puis tu as des erreurs aléatoires dès que ça écrit quelque chose (login, upload, génération de cache). Ça ne vient pas “de Laravel”, ça vient presque toujours d’un droit d’écriture bancal.
5) Le .env : celui du serveur, pas celui de ton laptop
Sur Cloudways, tu vas souvent pousser ton code via Git, mais ton .env ne doit pas venir avec. Tu veux un .env propre au serveur, avec les bons secrets, la bonne base de données, les bons drivers (cache, session), et surtout le bon APP_URL. Un APP_URL mauvais te casse des liens, des redirects, des URLs signées, et parfois des assets si tu as des configs qui en dépendent.
Et encore une fois, le point qui fait perdre du temps : si tu as fait php artisan config:cache, modifier le .env ne suffit pas. Il faut recacher la config (ou au moins faire php artisan config:clear) sinon tu restes avec l’ancienne réalité dans le cache.
6) Assets et Vite : “manifest not found” est ton meilleur ami (quand tu sais le lire)
Cloudways peut très bien servir un Laravel avec Vite, mais il ne va pas builder tes assets tout seul. Si tu déploies du PHP sans déployer le contenu de public/build, tu vas te retrouver avec des erreurs du style « Vite manifest not found » ou des pages sans CSS/JS.
Tu as deux stratégies réalistes. Soit tu build en CI et tu versionnes/déploies le résultat (donc public/build arrive sur le serveur avec le code). Soit tu installes Node sur le serveur et tu build pendant le déploiement. La deuxième solution marche, mais elle rallonge le temps de deploy et elle te rajoute une surface de bugs (Node qui saute, dépendances qui changent, mémoire). Perso, dès que le projet devient un minimum sérieux, je préfère builder ailleurs et livrer un artefact propre.
Un détail bête : si tu build en local, build en mode production. On a tous déjà vu un build “dev” qui traîne et qui fait croire que Cloudways a un problème, alors que c’est juste une sortie Vite pas adaptée.
7) Migrations : fais-les, mais fais-les avec une règle de discipline
En production, php artisan migrate sans --force ne passera pas, et c’est normal. Le piège, c’est de les lancer au mauvais moment ou dans le mauvais ordre. Typiquement, tu déploies du code qui s’attend à une colonne, mais tu n’as pas migré, et tu te manges une erreur SQL. Ou l’inverse : tu migres d’abord, mais ton code en prod ne sait pas encore gérer la nouvelle structure. Dans les deux cas, c’est toi qui te crées une fenêtre d’indisponibilité.
Si ton application a un peu de trafic, réfléchis “compatibilité” à chaque migration. Les migrations destructrices (drop/rename de colonnes) sont celles qui font les plus belles outages quand on déploie trop vite. Cloudways n’y changera rien. C’est une histoire de discipline d’équipe et de design de schéma.
Diagnostic rapide : quand ça part en vrille sur Cloudways
Si tu as 404 sur toutes les routes, pense webroot avant tout. Un mauvais webroot ou un public jamais servi te donne exactement ce résultat, et tu peux perdre une heure à regarder Laravel alors que Laravel n’est même pas exécuté.
Si tu as un 500 et zéro log, c’est souvent parce que le log ne peut pas s’écrire. Donc permissions sur storage. Si tu as un 500 avec un message sur bootstrap/cache, même combat, c’est le cache qui n’est pas accessible en écriture.
Si l’app marche mais sans CSS/JS, ou si tu vois une erreur Vite sur le manifest, c’est un problème de build assets ou de déploiement de public/build. Et si tu changes le .env sans effet, ne te raconte pas d’histoires : tu es très probablement en config cache, et c’est juste ton cache qui gagne le bras de fer.
Mon avis (sec) : Cloudways est un bon compromis… à condition d’assumer la partie “déploiement”
Cloudways te fait gagner du temps sur la maintenance serveur. Mais il ne remplace pas un process de déploiement. Si tu veux un truc fiable, arrête le mode “je pousse du code et je prie”. Tu fixes le webroot une fois pour toutes, tu standardises les permissions, tu décides où tu buildes les assets, et tu automatises le run Composer + cache + migrations dans un hook. Après ça, Cloudways redevient ce qu’il doit être : un outil qui te laisse coder.
