Auto-hébergement de Next.js et Payload avec Coolify : le calcul qui tient, et trois choses qui cassent

Les grilles tarifaires des plateformes serverless sont construites pour que le démarrage ne coûte rien. Cela fonctionne : le projet part sans facture, et les premières factures n’arrivent qu’au moment où quelque chose commence à vivre. Le problème, c’est qu’elles ne grandissent pas avec le chiffre d’affaires, mais avec le trafic, le nombre de personnes dans l’équipe et le temps d’exécution des fonctions — trois choses que personne ne prévoit au lancement.

Cet article est un calcul, pas un manifeste. D’un côté, Vercel avec une base de données gérée ; de l’autre, votre propre serveur privé virtuel (VPS) piloté par Coolify. Les chiffres viennent des grilles publiées par les fournisseurs (août 2026), et les trois pannes décrites plus bas nous sont arrivées en production, sur la pile exacte qui fait tourner le site que vous êtes en train de lire.

Une précision d’entrée, parce qu’elle conditionne la lecture de tout ce qui suit. Les montants de cet article restent dans la devise du fournisseur — dollars pour Vercel, MongoDB Atlas et Coolify, euros pour Hetzner. Ce sont des tarifs mondiaux, que vous payez à l’identique depuis Lausanne ou depuis Berlin ; les convertir en francs ajouterait un taux de change du jour sans rien apprendre de plus, et l’écart que nous voulons montrer est d’un ordre de grandeur, pas de quelques pour cent.

Si vous cherchez une procédure pas à pas, elle existe à part : notre projet de départ public sur GitHub contient une configuration prête à l’emploi de cette pile, fichiers de déploiement compris. Ici, il s’agit de la décision, et de ce qu’elle coûte une fois prise.

Ce que vous payez réellement chaque mois

Une comparaison n’a de sens que si l’on compte la même chose des deux côtés : l’application, la base de données, le trafic et l’espace pour les fichiers. Prenons une équipe de trois personnes et 2 To de trafic par mois — l’échelle d’un petit site de contenu, pas celle d’une jeune pousse qui vient de lever des fonds.

Deux chiffres de ce tableau méritent un commentaire, parce que ce sont eux qui font la différence. Le premier : le trafic. Vercel Pro inclut 1 To et facture au-delà entre 0,15 et 0,35 USD le gigaoctet, selon la région. Hetzner inclut 20 To dans ses régions européennes — vingt fois plus, compris dans le prix. Le second : la base de données. Les 57 USD correspondent à un seul nœud M10, alors qu’une base de production tourne sur un jeu de trois réplicas ; la facture réelle se rapproche donc du triple, avant même d’ajouter les sauvegardes et le trafic.

Il existe aussi un poste qu’aucun tableau ne montre : sur votre propre serveur, chaque service supplémentaire est gratuit. Un processus qui traite une file d’attente, une tâche planifiée maison, Redis, un petit service d’appoint — c’est la même machine. Dans un modèle facturé à l’exécution, chacun d’eux a sa propre ligne sur la facture, et c’est souvent ce poste-là, plus que l’hébergement de l’application, qui fait gonfler le montant au bout d’un an.

Ce que ce tableau ne montre pas

L’écart d’abonnement n’est pas une économie : c’est un coût déplacé de la facture vers le temps de quelqu’un. Vous reprenez trois obligations que vous n’aviez pas auparavant : les sauvegardes avec restauration à un instant précis, les mises à jour de sécurité et la surveillance de la disponibilité. Elles ne disparaissent pas parce que la facture a baissé — elles changent de propriétaire.

Le calcul honnête se fait en une ligne : heures d’exploitation par mois, multipliées par le taux horaire de la personne qui les assure, et ce produit se compare à l’écart d’abonnement, pas à l’abonnement lui-même. Nous ne mettons volontairement aucun taux horaire suisse dans ce calcul — le vôtre est celui que vous payez, à un employé ou à un prestataire, et c’est le seul qui compte. Mais faites l’exercice avec lui : aux taux pratiqués ici, il suffit de peu d’heures par mois pour que le produit rejoigne l’écart du tableau. L’auto-hébergement devient rentable lorsque ces heures existent de toute façon dans l’équipe et se répartissent sur plusieurs projets à la fois, pas sur un seul.

Si vous confiez cette exploitation à quelqu’un d’autre, la question devient celle d’un forfait mensuel ; notre calculateur du coût de maintenance le chiffre ligne par ligne, avec nos propres tarifs en francs.

Où se trouvent physiquement vos données

Un point que le tableau cache et qui, en Suisse, décide parfois à lui seul. Les régions européennes de Hetzner dont nous citons le prix sont situées en Allemagne et en Finlande. Le fichier de configuration présenté plus bas ne s’en soucie pas : il tourne de la même façon sur n’importe quel serveur, y compris sur une machine installée dans un centre de données suisse. Mais le prix de ce tableau est celui d’un serveur hors de Suisse, et si vous avez promis à vos clients que leurs données restent dans le pays, ce montant ne vous concerne pas. Nous n’avons pas relevé les grilles des fournisseurs de serveurs virtuels installés ici, et nous ne vous en donnerons donc pas d’estimation.

Ce qui se transpose tel quel, c’est la liste des endroits à vérifier. L’auto-hébergement ne concentre pas les données sur une seule machine : les fichiers envoyés partent vers un stockage compatible S3, les sauvegardes vers un autre emplacement, les images transitent par un réseau de diffusion. Chacun de ces éléments a sa propre adresse physique, et la promesse faite à vos clients vaut pour le maillon le plus éloigné. Les questions à poser à un hébergeur sont détaillées dans notre texte sur le choix d’un hébergement.

Architecture : comment l’ensemble est assemblé

Depuis la version 3, Payload n’est plus une application séparée qui se tient à côté de Next.js. Il fonctionne comme un paquet à l’intérieur, partage le même processus, la même compilation et le même fichier de configuration. Cela change l’architecture de déploiement plus qu’il n’y paraît : le panneau d’administration, l’interface de programmation et le site public forment un seul artefact, donc un seul conteneur d’application au lieu de deux. Ce que Payload sait faire comme CMS et dans quels cas nous le choisissons est décrit dans notre texte sur Payload CMS ; Next.js lui-même est démonté dans notre comparaison entre Next.js et React.

Un conteneur ou plusieurs

Par défaut, nous partons sur un seul conteneur d’application, plus des conteneurs distincts pour la base de données, Redis et le proxy. Découper l’application en davantage de processus n’a de sens que lorsque l’un d’eux évolue autrement que le reste — par exemple un processus qui traite une file de tâches, a besoin de mémoire pendant une importation de données et ne fait rien le reste de la journée.

Compilation « standalone » : 1,5 Go contre 150 Mo

Next.js sait produire un répertoire qui ne contient que ce dont l’application a besoin pour tourner — sans l’arbre complet des dépendances de développement. Cela s’active d’une ligne dans la configuration (output: "standalone"), et l’écart de taille de l’image est d’un ordre de grandeur : on descend d’environ 1,5 Go à quelque 150 Mo. Ce n’est pas cosmétique. Une image plus petite, c’est un transfert plus court à chaque déploiement, et beaucoup moins de place occupée par les versions successives que Docker conserve localement.

Il y a une condition, facile à manquer : dans une compilation en plusieurs étapes, il faut copier à la main les répertoires des ressources statiques et des fichiers publics, parce que le mode « standalone » ne les emporte pas. Oubliez-le, et vous obtenez une application qui fonctionne mais sans styles — un symptôme qui ressemble à un problème de CSS et qui est en réalité un problème de Dockerfile.

Le squelette docker-compose

Ci-dessous, le cœur de la configuration. Coolify y ajoute le routage, le domaine et le certificat ; le fichier ne dit donc pas un mot de Traefik — c’est précisément la partie pour laquelle on utilise Coolify plutôt que Docker tout court.

1services:
2  app:
3    build: .
4    environment:
5      DATABASE_URI: mongodb://mongo:27017/app
6      PAYLOAD_SECRET: ${PAYLOAD_SECRET}
7      REDIS_URL: redis://redis:6379
8    volumes:
9      - media:/app/public/media        # CHAQUE répertoire de fichiers envoyés, séparément
10    depends_on: [mongo, redis]
11
12  mongo:
13    image: mongo:7
14    volumes:
15      - dbdata:/data/db
16
17  redis:
18    image: redis:7-alpine
19    command: redis-server --save 60 1
20    volumes:
21      - redisdata:/data
22
23volumes:
24  media:
25  dbdata:
26  redisdata:
Copy

Une remarque sur les volumes, parce que c’est l’erreur la plus fréquente. Le système de fichiers d’un conteneur est éphémère. Chaque répertoire dans lequel l’application écrit des fichiers doit avoir sa propre entrée sous volumes — et « chaque » veut dire chacun, séparément pour chaque collection de fichiers envoyés. Ajouter une nouvelle collection dans Payload sans ajouter son volume n’est pas une erreur que vous verrez dans les journaux. Vous la verrez après un redémarrage, quand les fichiers auront disparu.

L’ensemble complet — Dockerfile, fichier compose, variables d’environnement et liste de contrôle avant la mise en ligne — se trouve dans notre dépôt public : nextjs-payload-starter.

Coolify lui-même : ce qui est gratuit, et ce qui ne l’est pas

La version que vous installez sur votre propre serveur est libre et gratuite, avec l’ensemble des fonctions : vous ne payez que le serveur. Ce qui est payant, c’est Coolify Cloud — 5 USD par mois pour deux serveurs connectés, puis 3 USD pour chaque serveur supplémentaire, selon la grille de Coolify. Il vaut alors la peine de comprendre ce que l’on achète : Cloud héberge le panneau de pilotage, tandis que vos applications continuent de tourner sur votre serveur. Autrement dit, la variante payante ne déplace ni vos données ni votre charge ; elle vous retire seulement l’entretien de l’outil qui les orchestre.

Quelle taille de serveur suffit

Pour un site de contenu, un point de départ raisonnable est de 4 processeurs virtuels et 8 Go de mémoire vive — le niveau du CPX31 de Hetzner à 16,49 EUR par mois. En dessous de 4 Go, le problème n’est pas de faire tourner le site, mais de compiler une nouvelle version et de traiter les images, deux opérations qui consomment beaucoup plus que le service ordinaire des pages. Si vous compilez l’image hors du serveur, dans GitHub Actions, les exigences baissent nettement ; nous y revenons dans la troisième panne.

Trois choses qui cassent

Les guides décrivent le déploiement qui a réussi. Voici les trois mécanismes qui le font échouer le plus souvent — chacun accompagné d’un incident réel de notre production, à titre de preuve et non d’illustration.

1. La mémoire : l’optimisation des images réveille l’« OOM Killer »

Le composant next/image recalcule par défaut les images dans le processus de l’application, à l’aide de la bibliothèque sharp. Sur une plateforme gérée, c’est un service séparé, dimensionné pour cela, qui s’en charge, et personne ne le remarque. Dans un conteneur sur un VPS doté de 2 à 4 Go de mémoire, l’envoi de quelques photos de produits depuis le panneau de Payload peut déclencher l’OOM Killer — le noyau tue le processus pour sauver le système. L’application disparaît sans la moindre ligne dans ses journaux, parce qu’elle n’a pas eu le temps de l’écrire.

La conséquence pour l’entreprise est sans proportion avec la cause : le site cesse de répondre en pleine journée, et si un robot d’indexation passe à ce moment-là, la page sort de l’index pour bien plus longtemps que n’a duré la panne.

La correction se fait en deux temps. Les fichiers quittent le serveur pour un stockage compatible S3 — dans Payload, c’est le rôle de @payloadcms/plugin-cloud-storage, avec un adaptateur pour Cloudflare R2, AWS S3 ou une Storage Box de Hetzner. Le recalcul des images part lui aussi à l’extérieur : soit vers un réseau de diffusion qui transforme à la volée (Cloudflare Images), soit en désactivant l’optimiseur intégré (images.unoptimized) et en générant les tailles côté Payload au moment de l’enregistrement. L’application cesse alors de garder en mémoire ce qu’elle n’a aucune raison d’y garder. Le choix de l’hébergement, du réseau de diffusion et de ce qui accélère réellement un site est traité dans notre texte sur l’hébergement.

Notre version de cette erreur était pire, parce que plus silencieuse. Ce n’est pas la mémoire qui nous a manqué, c’est un volume. Le répertoire de l’une des collections n’avait pas de stockage persistant attaché ; au redémarrage du conteneur, tous ses fichiers ont disparu, tandis que les enregistrements en base restaient en place et affirmaient que ces fichiers existaient. C’est arrivé deux fois : une fois avec une collection de médias, une fois avec la collection des documents — onze fichiers de rapports et de modèles effacés du disque, pendant que le site continuait de les proposer au téléchargement.

Ce qu’il faut en retenir ne tient pas au détail technique. Sur une plateforme gérée, l’oubli d’un volume n’existe pas, parce que le stockage n’est pas votre problème. Sur votre serveur, la persistance est une décision que vous prenez répertoire par répertoire, et chaque nouvelle fonction qui enregistre un fichier en ajoute une.

2. Le cache : l’ISR n’a nulle part où habiter

Sur Vercel, le rafraîchissement des pages statiques et revalidateTag opèrent au niveau d’un réseau de diffusion mondial. Dans votre propre conteneur, le cache de Next.js s’écrit dans .next/cache, sur le disque de ce conteneur. Il en découle deux choses, désagréables l’une comme l’autre : avec deux instances, chacune a son propre cache, non synchronisé ; et la publication d’un contenu dans le panneau ne le vide pas d’elle-même. C’est d’ailleurs l’un des prix de l’architecture découplée — nous le détaillons dans notre texte sur le CMS headless.

La correction. Un CacheHandler sur mesure, déclaré dans next.config, qui conserve les entrées dans Redis — l’état devient alors commun à toutes les instances et survit au redémarrage. Et, dans les collections de Payload, un crochet afterChange qui, après chaque enregistrement, appelle revalidatePath ou revalidateTag précisément pour ce qui a changé. La variante minimale — un volume persistant sur .next/cache — ne règle que le redémarrage, pas la multiplication des instances.

Ce que plusieurs langues changent ici. Pour une entreprise qui publie en français, en allemand ou en anglais, chaque page existe en autant d’exemplaires que de versions linguistiques, et chacune occupe sa propre entrée dans le cache. Deux conséquences pratiques. La clé du cache doit contenir la langue, faute de quoi un visiteur reçoit, depuis la mémoire tampon, la version qu’un autre a demandée dans une autre langue. Et le crochet de revalidation doit connaître l’adresse de chaque version : sur notre site, qui fonctionne en quatre versions linguistiques, l’identifiant d’URL est traduit, si bien qu’un même document a une adresse différente dans chaque langue. Un crochet qui ne revalide que l’adresse de la langue modifiée laisse les autres servir un contenu périmé — sans erreur visible, jusqu’au jour où quelqu’un compare deux versions.

Notre version : un disque rempli jusqu’à 89 Go, alors que personne n’avait rien envoyé. Des robots balayaient des adresses inexistantes, et le rendu à la demande enregistrait chacune de ces réponses comme un fichier de cache dans .next/server/app. Cela a grossi pendant des semaines, sans symptôme, jusqu’à ce que la place manque. La correction s’est révélée tenir en une ligne — un filtre qui écarte ces requêtes avant qu’elles ne produisent un fichier. La leçon, pourtant, ne porte pas sur le filtre : sur votre propre serveur, le cache est votre répertoire, sur votre disque, et personne ne le range à votre place.

3. Ressources et état : la compilation affame la base de données

Si la base de données tourne sur la même machine que l’application, docker build accapare, pendant un déploiement, la quasi-totalité du processeur et de la mémoire. Résultat : le site ralentit exactement au moment où vous déployez une correction — c’est-à-dire, en général, au moment où quelque chose ne fonctionne déjà plus. Avec 8 Go de mémoire vive, la compilation de Next.js peut aussi, tout simplement, être tuée.

• La mémoire d’échange. Au minimum 4 Go de swap. Elle n’accélérera pas la compilation, mais l’empêchera d’être tuée — et c’est tout ce qu’on lui demande ici.
• La compilation hors production. L’image est construite dans GitHub Actions, déposée dans un registre (GHCR), et Coolify récupère l’artefact terminé. Le serveur de production cesse de participer à la compilation — c’est la bonne architecture cible, pas une optimisation.
• La séparation de la base. Quand le projet grandit, la base de données reçoit sa propre instance. C’est la première dépense qu’il vaut la peine d’engager volontairement, avant qu’une panne ne l’impose.
• Les sauvegardes avec restauration à un instant précis. Un export quotidien ne suffit pas si ce qui compte est la quantité de données que vous pouvez vous permettre de perdre. La restauration à un instant donné repose sur le journal des écritures — le WAL dans Postgres, l’oplog dans MongoDB — et c’est lui qui décide si vous revenez à la veille ou à dix minutes plus tôt.

Sur ce dernier point, une règle que nous appliquons à nous-mêmes : une sauvegarde que vous n’avez jamais restaurée est une hypothèse, pas une sauvegarde. C’est l’obligation que l’on reprend avec le serveur et, le plus souvent, l’endroit où l’économie se révèle illusoire. Un export par jour ne convient que si vous acceptez de perdre une journée de travail ; sinon, il vous faut de la place pour le journal des écritures et une procédure de restauration que vous avez répétée au moins une fois.

Deux pièges qui nous ont touchés précisément. Le premier : le serveur qui compile n’a pas accès à la base de données, si bien que toute fonction qui génère des chemins au moment de la compilation doit le prévoir — sinon la compilation réussit en local et échoue en production. Le second est plus sournois : next build vérifie les types de tout le projet, de sorte qu’un répertoire exclu par .dockerignore peut faire échouer un déploiement pendant que l’intégration continue — qui compile hors de Docker — reste au vert. Cela nous a coûté plusieurs déploiements avant de comprendre qu’une intégration continue au vert et un déploiement réussi sont deux choses différentes.

Les certificats. Coolify les renouvelle automatiquement via Let’s Encrypt, mais le renouvellement exige que le proxy réponde à un défi HTTP. Si Cloudflare se trouve devant le serveur en mode proxy complet et que ses règles ne laissent pas tout passer, le renouvellement échoue sans bruit, et vous l’apprenez quatre-vingt-dix jours après le déploiement.

Quand cela se rentabilise, et quand non

La décision est rarement technique. Elle revient à savoir si quelqu’un, dans l’équipe, décrochera le téléphone quand le serveur cessera de répondre un samedi.

La ligne sur la juridiction mérite d’être lue avec la section sur l’emplacement des données : le serveur que vous contrôlez vous permet de choisir le pays, mais seulement si vous choisissez aussi celui des sauvegardes et du stockage des fichiers. Un serveur installé en Suisse dont les sauvegardes partent ailleurs ne tient pas la promesse faite aux clients.

Reste une question qui arrive tôt ou tard : quand faut-il déplacer la base de données sur sa propre machine ? Au moment où le déploiement devient perceptible pour les utilisateurs — autrement dit, quand la compilation de l’image sur la même machine ralentit les réponses de la base. Si vous compilez hors production, ce moment recule nettement, et il arrive souvent qu’il ne vienne jamais.

Si, après ce calcul, votre propre serveur vous paraît toujours sensé, le point de départ est notre projet public — Next.js 16, Payload 3, MongoDB et un déploiement sous Coolify dans un seul dépôt : nextjs-payload-starter.

Le contexte technologique plus large — ce que le choix d’une pile fait au coût d’un projet — est déplié dans notre comparaison des plateformes. Et si c’est la facture d’exploitation complète qui vous intéresse, pas seulement l’hébergement : le prix de la maintenance d’un site web.

Nous construisons ce type de déploiement pour nous-mêmes et pour nos clients — voyez comment nous développons des applications web.

D’où viennent ces chiffres

Les prix proviennent des grilles publiées par les fournisseurs, relevées en août 2026 : Vercel (20 USD par siège et par mois, 1 To de trafic inclus, puis 0,15 à 0,35 USD le Go selon la région), Hetzner Cloud (CPX31 : 4 processeurs virtuels, 8 Go de mémoire vive, 160 Go NVMe, 16,49 EUR par mois, 20 To de trafic dans les régions européennes) et MongoDB Atlas (M10 dès environ 57 USD par mois et par nœud ; une base de production est un jeu de trois réplicas). Le tarif de Coolify Cloud a été vérifié sur la page du fournisseur en septembre 2026. Tous ces montants restent dans la devise dans laquelle le fournisseur les publie, pour la raison donnée en ouverture.

Les pannes décrites viennent de nos propres déploiements, pas de la littérature.

Ce que nous ne donnons pas, et pourquoi : aucun taux horaire d’exploitation pour le marché suisse, et aucun prix de serveur virtuel installé en Suisse. Nous n’avons relevé ni l’un ni l’autre nous-mêmes, et transposer un chiffre d’un autre marché en francs fabriquerait un montant qui aurait l’air vérifié sans l’être. Là où le chiffre manque, vous avez le calcul à faire avec vos propres valeurs — il fonctionne quel que soit le taux, ce qu’un chiffre recopié ne ferait pas.