Migrer de Laravel Forge vers Laravel Cloud

Migrer une application Laravel d’un hébergement géré par Laravel Forge (VPS) vers Laravel Cloud change la façon dont le déploiement, le scaling et la base de données sont gérés. Laravel News a documenté une migration en direct (stream YouTube), avec les choix, les étapes et les pièges à anticiper. Ce guide en résume les points essentiels.

Prérequis

• Application Laravel déjà en production sur Forge (ou VPS classique)
• Compte Laravel Cloud et accès au tableau de bord
• Sauvegardes de la base de données et des fichiers (storage, .env)

1. Préparer la migration

• Documenter l’existant : cron, workers, variables d’environnement, domaines, SSL.
• Vérifier la compatibilité de l’app avec l’environnement Cloud (PHP, extensions, Redis, filesystems, queues).
• Prévoir une fenêtre de maintenance ou une bascule avec trafic réduit pour limiter les risques.

2. Approche : réduire les risques, valider par étapes

La démarche recommandée consiste à :

1. Déployer l’application sur Laravel Cloud dans un premier environnement (staging si disponible).
2. Tester : migrations, jobs, scheduling, storage, envoi d’emails, logs.
3. Basculer progressivement : DNS, trafic, en gardant une possibilité de rollback (ancien Forge/VPS encore actif quelques jours).

3. Vérifications avant coupure

• Base de données : export/import propre ; encodage, jeux de caractères, triggers et events si utilisés.
• Fichiers : storage/ (uploads, cache, logs) ; s’assurer que le stockage Cloud (S3, etc.) ou le volume prévu est configuré et testé.
• Cron : schedule:run et éventuelles tâches custom — vérifier qu’elles tournent sur Cloud comme attendu.
• Queues : workers (Redis, database, etc.) — s’assurer que la config de queue et les workers Cloud sont cohérents.
• ** .env** : APP_KEY, APP_URL, DB_*, REDIS_*, MAIL_*, FILESYSTEM_*, etc. Ne pas réutiliser l’ancienne APP_KEY si vous changez d’infra de façon définitive sans raison de compatibilité.

4. Bascule DNS et trafic

• Réduire le TTL des enregistrements concernés avant la bascule pour accélérer la propagation.
• Changer les A / CNAME vers les cibles Laravel Cloud au moment choisi.
• Surveiller les logs, erreurs et métriques (Cloud, Sentry, etc.) juste après la bascule.

5. Pièges fréquents

• Chemins et filesystem : storage_path(), public_path() ; volumes ou disques éphémères selon l’offre — ne pas supposer que storage/ est persistant comme sur un VPS si ce n’est pas garanti.
• Queue / cron : configuration différente (variables, timeouts, nombre de workers) — bien comparer Forge et Cloud.
• Websockets / broadcasting : si utilisé (Pusher, Redis, etc.), revoir la config des drivers et des URLs.
• Sessions : driver database ou redis ; s’assurer que la BDD/Redis Cloud est utilisée et que les anciennes sessions ne posent pas de conflit (en cas de changement de APP_KEY, les sessions seront invalidées, ce qui peut être voulu).

Dépannage

Bonnes pratiques

• Garder l’ancien environnement (Forge) opérationnel et rollbackable pendant quelques jours.
• Logger et monitorer (erreurs, temps de réponse, queues) avant et après la migration.
• Préparer un runbook (étapes, contacts, rollback) pour l’équipe.

Ressources

• Laravel News – Migrating Laravel News from Laravel Forge to Cloud
• Laravel Cloud – Documentation
• Laravel Forge – Documentation

Cet article s’inscrit dans notre série de guides technique et développement web. Pour un serveur ou une application sur-mesure, contact.