Auto-hébergement

Exécution de Coolify sur un VPS à 6 $ : benchmarks et exigences en matière de fichier d'échange

Un benchmark chronométré montre que Coolify fonctionne sur un droplet DigitalOcean de 1 Go si vous ajoutez un fichier d'échange de 2 Go, l'installation prenant 172 secondes.

Illustration of a small server with limited resources managing a delicate balance of tasks.
Illustration créée pour cet article

Traduit automatiquement depuis l’original en anglais.

Un récent benchmark a testé la capacité de la plateforme auto-hébergée Coolify à fonctionner efficacement sur un serveur privé virtuel à faible coût. Le test, réalisé le 1er octobre 2026, utilisait un droplet DigitalOcean coûtant six dollars par mois. Les résultats confirment que le logiciel fonctionne sur ce matériel minimal, mais uniquement si les administrateurs configurent une astuce spécifique de gestion de la mémoire avant l'installation.

Ce qui s'est passé

Le test visait à déterminer si les exigences système officielles de deux CPU et 2 Go de RAM étaient des nécessités strictes ou des estimations prudentes. Le testeur a déployé Coolify sur un droplet DigitalOcean doté d'un vCPU, de 1 Go de RAM et d'un SSD de 25 Go. Le processus a été chronométré étape par étape pour mesurer les performances réelles pour les petites équipes gérant des projets annexes ou des outils internes.

Le script d'installation s'est terminé en 172 secondes. Après la création d'un compte root et la configuration de la première application, le déploiement initial a pris 210 secondes pour commencer à répondre aux requêtes HTTP. Le temps total écoulé pour l'ensemble de la configuration était d'environ 23 minutes, bien que les étapes actives de configuration aient pris moins de dix minutes. Le délai incluait la résolution d'un répertoire de base mal configuré et une courte pause.

Les données d'utilisation de la mémoire ont révélé pourquoi cette configuration supplémentaire est vitale. Alors que le système inactif utilisait environ 618 Mo de RAM, le processus de compilation d'une application Node.js d'exemple a atteint un pic de 720 Mo de RAM et a utilisé 669 Mo supplémentaires d'espace d'échange. Sans le fichier d'échange, le noyau aurait interrompu le processus de compilation en raison d'une mémoire insuffisante. Avec le fichier d'échange activé, la compilation a ralenti mais s'est terminée avec succès.

Détails clés

  • Matériel utilisé : Plan DigitalOcean Basic Regular (6 $/mois) avec 1 vCPU, 1 Go de RAM et 25 Go de SSD sous Ubuntu 24.04 LTS.
  • Exigence critique : Un fichier d'échange de 2 Go doit être créé avant l'installation pour prévenir les erreurs de mémoire insuffisante lors des compilations.
  • Temps d'installation : Le script d'installation officiel a pris 172 secondes, principalement consacrées à l'installation de Docker et au téléchargement des images de conteneurs.
  • Temps de déploiement : Le premier déploiement d'application a pris 210 secondes du clic à la réponse HTTP en direct ; les déploiements suivants ont été plus rapides, à 1 minute 52 secondes.
  • Empreinte des ressources : Coolify lui-même utilise environ 250 Mo de RAM lorsqu'il est inactif, laissant peu de marge pour les applications sur un serveur de 1 Go.
  • Efficacité des coûts : La configuration coûte 6 $ par mois, nettement moins cher que les options comparables de Platform-as-a-Service comme Heroku ou Render pour plusieurs petits services.

Contexte

Coolify est un outil open source qui permet aux développeurs d'héberger leur propre plateforme similaire à Heroku, Vercel ou Netlify. Il fournit une interface web pour déployer des applications fonctionnant dans des conteneurs Docker. Cette approche, connue sous le nom d'auto-hébergement, donne aux équipes un contrôle total sur leur infrastructure et leurs données tout en évitant les frais récurrents par application facturés par les fournisseurs cloud commerciaux.

L'espace d'échange est une portion du stockage du disque dur utilisée comme extension de la RAM physique. Lorsqu'un serveur manque de mémoire physique, il déplace les données inactives vers le fichier d'échange. Cela empêche les applications de planter, mais est beaucoup plus lent que l'utilisation de la RAM réelle. Sur les serveurs à mémoire limitée, comme le droplet de 1 Go utilisé dans ce test, l'échange est essentiel pour gérer les pics temporaires de demande, tels que la compilation de code lors d'un déploiement.

Pourquoi c'est important

Pour les petites entreprises et les développeurs indépendants, les coûts d'infrastructure sont une préoccupation majeure. Les plateformes commerciales facturent souvent par application ou par service, ce qui peut rapidement s'accumuler lors de l'exécution de multiples outils internes, environnements de staging ou projets annexes. En consolidant ces services sur un seul serveur à faible coût, les équipes peuvent réduire leurs factures d'hébergement mensuelles de plusieurs dizaines de dollars à un seul tarif fixe. Ce benchmark prouve que même la tranche la moins chère de l'hébergement cloud peut soutenir une plateforme de développement fonctionnelle.

Cependant, l'exécution de charges de travail de production sur un matériel minimal nécessite une gestion rigoureuse. Le test souligne que si le logiciel tient, la marge d'erreur est mince. Les compilations sont gourmandes en ressources et les pics de trafic pourraient submerger un serveur de 1 Go. Les équipes doivent comprendre que les économies de coûts s'accompagnent d'une responsabilité opérationnelle accrue. Elles doivent surveiller l'utilisation des ressources, gérer les sauvegardes et traiter les mises à jour de sécurité elles-mêmes, plutôt que de compter sur un fournisseur géré.

Cette information aide les responsables IT à prendre des décisions éclairées concernant la frontière entre l'auto-hébergement et les services managés. Pour les outils internes non critiques ou les sites à faible trafic, l'option à 6 $ est viable. Pour les applications destinées aux clients nécessitant une haute disponibilité et des temps de compilation rapides, passer à un plan de 2 Go ou utiliser des pipelines de build externes devient nécessaire.

Ce que vous pouvez faire

  • Créez un fichier d'échange de 2 Go sur n'importe quel serveur Linux disposant de 1 Go de RAM avant d'installer des applications gourmandes en mémoire pour éviter les plantages lors des compilations.
  • Utilisez la commande free -m pour surveiller l'utilisation de la mémoire et de l'échange en temps réel lors du déploiement de nouvelles applications afin d'identifier les goulets d'étranglement en ressources.
  • Envisagez de déléguer les processus de compilation lourds à des services CI/CD externes comme GitHub Actions si votre serveur peine avec les temps de compilation.
  • Passez à un plan de 2 Go de RAM si vous prévoyez d'héberger plus de deux petites applications ou des services intensifs en bases de données aux côtés de Coolify.
  • Activez les sauvegardes automatisées via votre fournisseur cloud ou la fonctionnalité intégrée de Coolify.

Autres actualités

Toutes les actualités