J’ai quitté Vercel pour Coolify auto-hébergé — 7 étapes, 38 € par mois et les 2 pièges qui m’ont fait revenir en arrière une fois

La première tentative a échoué. Pas spectaculairement — le site tournait, les pages s’affichaient, les tests passaient. Il a fallu quatre jours pour découvrir que les téléversements d’images disparaissaient à chaque redéploiement, parce que le dossier de destination n’était pas dans un volume persistant. Retour arrière, DNS repointé, honte modérée.

La seconde tentative, trois semaines plus tard, a tenu. Elle tient depuis quatorze mois, sur un VPS à trente-huit euros par mois qui héberge désormais quatre projets. Voici la procédure exacte, avec les deux pièges qui m’ont coûté la première tentative explicitement signalés là où ils se déclenchent.

À qui cette migration convient — et à qui elle ne convient pas

Soyons honnête sur le périmètre. Cette bascule est un bon calcul si vous hébergez plusieurs projets de taille modeste, si votre audience est majoritairement européenne, si la maîtrise de l’emplacement des données compte pour vous, et si quelqu’un dans l’équipe accepte d’assumer une à deux heures d’exploitation par mois.

Elle est un mauvais calcul si vous avez un seul petit projet — le gain financier sera nul et vous aurez acheté de la charge mentale — ou si votre trafic est réellement mondial et sensible à la latence, auquel cas un serveur unique ne remplacera pas un réseau de points de présence. Aucune méthode ne change ces deux constats.

Étape 1 — Inventorier ce que la plateforme fait pour vous sans le dire

Avant de toucher au moindre serveur, listez les services rendus implicitement. Une plateforme managée fait beaucoup de choses que l’on ne remarque qu’en les perdant : optimisation d’images à la volée, exécution de fonctions en périphérie, protection contre les pics de trafic, environnements de prévisualisation par branche, journaux consultables, rotation automatique des certificats.

Pour chacune, une décision explicite : je la reproduis, je m’en passe, ou je la remplace par un service tiers. Écrivez-la. C’est ce document qui vous évitera la mauvaise surprise en semaine trois, quand un client demandera pourquoi les prévisualisations de branche ont disparu.

Étape 2 — Dimensionner sur le pic de compilation, jamais sur le trafic

L’erreur de dimensionnement la plus répandue vient d’un raisonnement pourtant sain : « mon site fait deux mille visites par jour, un petit serveur suffit ». C’est vrai pour servir les requêtes. C’est faux pour compiler.

Une compilation Next.js de taille moyenne consomme entre 2 et 4 Go de mémoire vive, parfois davantage avec beaucoup de pages générées statiquement. Coolify et sa base de données en réservent environ un de plus. Si votre serveur est ajusté au trafic, la compilation entrera en compétition mémoire avec l’application en cours d’exécution, et le noyau tuera l’un des deux — généralement au pire moment.

La configuration qui fonctionne sans y penser : 8 Go de RAM, 4 cœurs, 80 Go de disque. Chez les hébergeurs européens, cela se situe entre 25 et 45 euros par mois. C’est la ligne à trente-huit euros de mon titre, et elle héberge quatre projets sans transpirer.

Étape 3 — Installer Coolify et durcir l’accès avant tout le reste

L’installation elle-même est triviale : un script d’installation sur un serveur fraîchement provisionné, quelques minutes, une interface web accessible. Le piège n’est pas là. Il est dans la tentation de déployer immédiatement une application avant d’avoir durci l’accès.

Faites-le dans cet ordre, avant le premier déploiement : authentification SSH par clé uniquement et mot de passe désactivé, pare-feu n’ouvrant que les ports strictement nécessaires, interface d’administration protégée derrière une authentification forte, mises à jour de sécurité automatiques activées. Un tableau de bord de déploiement exposé sans protection, c’est un accès racine offert à qui le trouve — et il sera trouvé, les balayages automatisés font le tour d’internet en quelques heures.

Un panneau d’administration de PaaS, c’est un shell distant avec une jolie interface. Traitez-le comme tel.

Étape 4 — Reproduire le build et les variables d’environnement (piège n° 1)

Voici le premier piège, celui qui produit l’essentiel des « ça marchait en local ». Dans une application Next.js, les variables d’environnement se répartissent en deux familles que les plateformes managées vous font oublier : celles nécessaires au moment de la compilation, qui sont figées dans l’artefact produit, et celles lues à l’exécution, résolues à chaque démarrage du conteneur.

Sur une plateforme managée, l’interface unique masque cette distinction. Sur Coolify, elles sont configurées à deux endroits distincts, et oublier la moitié produit un symptôme déroutant : l’application démarre normalement, puis échoue à un appel précis avec une erreur qui ne mentionne aucune variable manquante.

La procédure fiable : exportez la liste complète des variables depuis l’ancienne plateforme, classez-les en deux colonnes selon qu’elles sont préfixées pour exposition publique ou non, et reportez-les dans les deux sections correspondantes. Puis validez avec un déploiement de test avant de brancher le vrai domaine.

Étape 5 — Brancher domaines, TLS et cache de façade

Coolify gère le reverse proxy et l’émission automatique des certificats. Renseignez le domaine dans la configuration de l’application, pointez un enregistrement DNS vers l’adresse du serveur, le certificat est émis et renouvelé sans intervention.

L’ajout qui change tout, et que trop de migrations sautent : placez un cache de façade devant votre origine. C’est ce qui restitue l’essentiel du bénéfice perçu du réseau de diffusion que vous venez d’abandonner. Les ressources statiques, les polices et les images sont servies depuis un point de présence proche du visiteur, et votre VPS ne voit plus que les requêtes dynamiques. Sur un site de contenu classique, cela retire entre 70 et 90 % de la charge de l’origine.

Vérifiez ensuite que le cache respecte bien vos en-têtes sur les routes authentifiées. Une page personnalisée servie depuis un cache partagé est un incident de confidentialité, pas un problème de performance. Le sujet est traité en détail par nos confrères de WebGuard Agency, qui en font un point de contrôle systématique en audit.

Étape 6 — Migrer la base de données et les fichiers (piège n° 2)

Le second piège, celui qui m’a coûté la première tentative. Un conteneur est éphémère par construction : tout ce qui est écrit hors d’un volume persistant disparaît au redéploiement suivant. Sur une plateforme managée, vous n’écriviez de toute façon jamais sur le disque local — le stockage passait par un service externe et l’habitude s’était perdue.

Concrètement, deux vérifications avant la bascule. D’abord, déclarez explicitement un volume persistant pour tout répertoire écrit par l’application : téléversements, cache d’images généré, fichiers temporaires à durée de vie longue. Ensuite — et c’est l’étape que j’avais sautée — testez-le en redéployant deux fois et en vérifiant qu’un fichier envoyé après le premier déploiement survit au second. Cinq minutes de test contre quatre jours de diagnostic.

Pour la base de données, Coolify sait provisionner PostgreSQL avec sauvegardes planifiées. Le point non négociable est la destination : une sauvegarde qui reste sur le même serveur que la base ne protège de rien, sinon d’une erreur de manipulation. Configurez un envoi vers un stockage objet chez un autre fournisseur, et surtout : testez une restauration complète avant la bascule. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Étape 7 — Basculer le DNS progressivement et garder un retour arrière

Ne coupez rien. La séquence qui permet de dormir : abaissez la durée de vie DNS à soixante secondes quarante-huit heures avant la bascule, pour que la propagation soit rapide le jour J. Faites tourner les deux hébergements en parallèle pendant quarante-huit heures, avec le trafic réel sur l’ancien et une vérification manuelle régulière sur le nouveau.

Basculez ensuite le DNS et surveillez pendant vingt-quatre heures : taux d’erreur, latence, journaux applicatifs, et surtout les parcours utilisateurs complets — inscription, connexion, envoi de fichier, paiement le cas échéant. Ne résiliez l’ancien abonnement qu’après sept jours de fonctionnement propre. Le surcoût d’une semaine de double facturation est dérisoire face au coût d’un retour arrière impossible.

Bilan après quatorze mois

Quatre projets sur un serveur à trente-huit euros, contre environ cent quatre-vingts euros mensuels auparavant répartis sur deux plateformes. Deux incidents en quatorze mois : un disque saturé par des images de conteneurs non purgées — corrigé par une tâche de nettoyage planifiée — et un redémarrage après une mise à jour du noyau.

Le temps d’exploitation réel s’établit autour d’une heure et demie par mois, essentiellement des mises à jour et la vérification trimestrielle de restauration de sauvegarde. Ce que j’ai gagné et que je n’avais pas anticipé : la capacité de dire précisément où sont les données et qui peut y accéder. Cette réponse-là vaut quelque chose dans un appel d’offres public français.

Pour aller plus loin

Sur l’industrialisation du déploiement, notre guide CI/CD appliqué au machine learning couvre les mêmes mécaniques appliquées à des artefacts plus lourds, et créer une API d’intelligence artificielle détaille le dimensionnement quand la charge devient irrégulière.

Si votre application appelle des modèles de langage, la question du coût d’inférence change complètement l’arbitrage d’hébergement : l’équipe de Plug-Tech publie régulièrement sur ce chiffrage.

Questions fréquentes

Quel VPS faut-il pour héberger Coolify et une application Next.js ?

Le dimensionnement se fait sur le pic de compilation, jamais sur le trafic moyen. Une compilation Next.js de taille moyenne consomme 2 à 4 Go de RAM et Coolify en réserve environ 1 de plus. En dessous de 8 Go et 4 cœurs, attendez-vous à des échecs de compilation intermittents très pénibles à diagnostiquer, parce qu’ils ressemblent à des erreurs applicatives. Chez les hébergeurs européens, cette configuration coûte 25 à 45 euros par mois.

Perd-on le réseau de diffusion de contenu ?

Oui, et c’est le principal renoncement. La compensation raisonnable est un cache de façade gratuit devant l’origine pour les ressources statiques et les images, qui restitue l’essentiel du bénéfice perçu. Pour une audience principalement française ou européenne, l’écart de latence résiduel se compte en dizaines de millisecondes — inaudible sur un site classique.

Combien de temps prend la migration complète ?

Trois à quatre jours pour une application avec base de données, période de double exécution comprise. La partie technique pure représente environ une journée : l’essentiel du temps part dans la reproduction fidèle des variables d’environnement et dans la validation. Ne compressez pas la double exécution — c’est elle qui évite le retour arrière en urgence un vendredi soir.

Est-ce vraiment moins cher ?

En coût d’infrastructure, oui, souvent d’un facteur trois à cinq dès que plusieurs projets partagent le serveur. En coût complet, cela dépend de votre valorisation du temps : comptez une à deux heures d’exploitation par mois. Pour une équipe avec un seul petit projet, l’arbitrage financier est neutre et la vraie motivation devient la maîtrise des données et l’absence de dépendance.