Alternatives à Coolify — PaaS self-hosted et plateformes managées pour indie builders

Pourquoi les fondateurs cherchent des alternatives à Coolify

Coolify est devenu la recommandation par défaut pour les indie founders qui veulent self-host leurs apps. Et pour de bonnes raisons — on obtient une expérience de déploiement type Heroku sur un VPS à 5 $/mois. Git push to deploy, SSL automatique, bases de données en un clic et un dashboard web qui rend la gestion de conteneurs accessible. Pour un fondateur bootstrapé, les économies par rapport aux plateformes managées sont significatives.

Mais après avoir fait tourner Coolify en production un moment, les points de friction apparaissent.

L'UI n'est pas toujours stable. Coolify est en développement actif, ce qui est super pour les nouvelles features mais rude côté fiabilité. Les mises à jour cassent parfois le dashboard, et certains workflows ont l'air à moitié finis. Les pages de settings peuvent être confuses, surtout autour des configurations de build et du networking. Si on a déjà cliqué sur un bouton dans Coolify en se demandant si ça avait réellement fait quelque chose, on n'est pas seul.

L'architecture mono-serveur est le défaut, et elle est fragile. La plupart des indie builders font tourner Coolify sur un seul VPS. Ce serveur, c'est toute l'infrastructure — chaque app, chaque base de données, chaque background worker. S'il tombe, tout tombe. Coolify supporte les setups multi-serveurs, mais les configurer demande plus de compétences DevOps que la plupart des fondateurs solo n'en ont. On est à une mauvaise mise à jour kernel d'un outage.

L'overhead de maintenance est réel. Self-host, ça veut dire qu'on est responsable des mises à jour OS, des correctifs de sécurité, du monitoring de l'espace disque, du nettoyage Docker, de la vérification des sauvegardes et du renouvellement des certificats. Coolify automatise une partie, mais pas tout. Le temps qu'on passe à maintenir son serveur, c'est du temps qu'on ne passe pas sur les features, le marketing ou les conversations avec les clients. Pour un projet pré-revenu, ce compromis est acceptable. Pour un SaaS en croissance, chaque heure compte.

L'espace disque Docker grignote silencieusement. Les vieilles images, les volumes orphelins et les caches de build s'accumulent. Si on ne configure pas un Docker prune régulier, le serveur sature et tout s'arrête. C'est pas un problème spécifique à Coolify, mais ça surprend beaucoup de nouveaux venus dans le self-hosting.

Ces points ne sont pas rédhibitoires pour tout le monde. Mais ils expliquent pourquoi des fondateurs qui commencent avec Coolify cherchent parfois quelque chose qui lisse les aspérités ou qui retire complètement la responsabilité infrastructure.

Analyse détaillée : ce que chaque alternative fait de mieux

CapRover — le PaaS self-hosted plus simple

CapRover, c'est ce qu'on obtient quand on réduit un PaaS self-hosted à l'essentiel en priorisant la simplicité. On l'installe sur un VPS, on pointe un DNS wildcard vers le serveur, et on a une plateforme de déploiement fonctionnelle en environ 10 minutes.

La marketplace d'apps en un clic est le point fort de CapRover. Plus de 100 templates couvrent tout, de WordPress à Plausible Analytics en passant par n8n. On clique, on remplit quelques variables, et le service se déploie. Pour les fondateurs qui déploient principalement des outils open source existants, CapRover est plus rapide que Coolify.

CapRover a une feature que Coolify gère différemment : le clustering Docker Swarm intégré. On ajoute des worker nodes et CapRover distribue les conteneurs automatiquement. C'est pas de l'orchestration niveau Kubernetes, mais ça donne de la redondance et de la distribution de charge de base sans la complexité.

Le compromis, c'est l'expérience développeur pour les apps custom. CapRover ne supporte pas Nixpacks ni les buildpacks Heroku. Déployer son propre code implique d'écrire un Dockerfile ou d'utiliser le format Captain Definition de CapRover. Pour un dev à l'aise avec Docker, c'est pas un souci. Pour quelqu'un habitué à l'auto-détection de Coolify ou Railway, c'est une étape en plus.

La vélocité de développement a ralenti. Coolify ship des mises à jour chaque semaine ; CapRover passe des mois entre les releases. Le core est stable, mais les nouvelles features et correctifs arrivent lentement. La communauté est plus petite, et la documentation a des trous.

Quand choisir CapRover : On déploie principalement des apps pré-construites (WordPress, outils d'analytics, outils internes) et on veut du clustering basique sans la complexité de Kubernetes.

Dokku — le PaaS du minimaliste

Dokku est le PaaS self-hosted le plus ancien de cette liste, et ça se voit — dans le bon sens. Il a été affiné jusqu'à l'essentiel : un script bash, quelques plugins et un workflow de déploiement qui reproduit exactement Heroku. Pas de dashboard web, pas d'orchestration de conteneurs, pas de processus supplémentaires sur le serveur.

La compatibilité Heroku est réelle. Si l'app a un Procfile et fonctionne avec les buildpacks Heroku, elle se déploie sur Dokku avec git push dokku main. Mêmes buildpacks, même gestion des variables d'environnement, mêmes types de processus. Migrer une app Heroku vers Dokku, c'est changer un remote git et mettre à jour le DNS.

La légèreté de Dokku est un vrai avantage sur les petits VPS. Coolify fait tourner ses propres conteneurs pour le dashboard, l'API et le proxy. L'overhead de Dokku est minimal — juste le processus Dokku lui-même et nginx comme reverse proxy. Sur un VPS de 1 Go de RAM, la différence de ressources disponibles pour les vraies apps est notable.

L'écosystème de plugins couvre l'essentiel. dokku postgres:create mydb donne une base Postgres. dokku letsencrypt:auto-renew gère le SSL. Des plugins existent pour Redis, MySQL, MongoDB et la plupart des services courants. Chaque plugin s'installe en une seule commande.

Là où Dokku pèche, c'est tout ce qui est visuel. Pas de dashboard web signifie pas de vue d'ensemble rapide de ses déploiements. Pas de deploy previews sans scripting. Pas de templates de services en un clic. Consulter les logs, c'est se connecter en SSH et lancer dokku logs nom-app. Pour un dev qui vit dans le terminal, c'est naturel. Pour n'importe qui d'autre, c'est un point de friction.

Quand choisir Dokku : On migre depuis Heroku, on préfère la gestion en CLI, et on veut le footprint le plus petit possible sur son VPS.

Railway — l'échappatoire managée

Railway, c'est l'alternative pour les fondateurs qui ont essayé le self-hosting et qui ont décidé qu'ils préféraient payer quelqu'un d'autre pour gérer l'infrastructure. L'expérience développeur est la meilleure de cette catégorie. On connecte un repo GitHub, Railway détecte le framework, build l'app et la déploie. Le tout prend moins de deux minutes.

L'expérience base de données intégrée, c'est là que Railway brille face au self-hosting. On clique pour provisionner Postgres, MySQL, Redis ou MongoDB. La connection string est injectée automatiquement en variable d'environnement. Pas de SSH sur un serveur, pas de gestion de volumes Docker, pas de souci avec les schedules de backup. Railway gère tout.

Les environnements de preview pour les pull requests sont standard. Chaque PR obtient son propre déploiement avec sa propre instance de base de données. Pour un fondateur solo qui utilise les PR GitHub, ça attrape les bugs avant la production. Essayez de reproduire ce workflow sur une instance Coolify self-hosted — c'est possible, mais ça demande de la vraie configuration.

La différence de coût, c'est l'éléphant dans la pièce. Une charge qui coûte 10 $/mois sur un VPS Hetzner avec Coolify coûte 25-50 $/mois sur Railway, selon le trafic et l'utilisation de la base de données. Pour une seule app avec une base, le crédit de 5 $ du plan Hobby couvre souvent la note. Mais quand on ajoute une deuxième app, une instance Redis et un background worker, la facture grimpe. Les fondateurs sensibles au burn rate le sentent passer.

La tarification à l'usage signifie que la facture fluctue. On se retrouve en une d'Hacker News et la facture Railway explose. Sur un VPS self-hosted, le même pic de trafic ne coûte rien de plus — en supposant que le serveur tienne la charge.

Quand choisir Railway : On valorise son temps plus que son argent, on veut la meilleure expérience développeur, et on accepte la prime pour zéro gestion d'infrastructure.

Render — le juste milieu avec plan gratuit

Render se situe entre le self-hosted et le full managé. Le plan gratuit est réellement utilisable : sites statiques avec 100 Go de bande passante par mois et services web avec 750 heures de compute. Pour un side project, un environnement de staging ou un site de documentation, on ne paye rien.

Le palier payant commence à 7 $/mois par service. Une app web plus une base Postgres coûte 14 $/mois. On ajoute une instance Redis et un background worker et on est à 28 $/mois. C'est moins cher que Railway pour la même charge, mais plus cher que Coolify sur un VPS.

Le Postgres managé de Render a un piège : le plan gratuit expire après 90 jours. On crée une nouvelle base gratuite (migration de données manuelle) ou on passe au plan payant. C'est documenté mais ça surprend quand même ceux qui deploy-and-forget leurs side projects.

Les temps de build sont le point faible de Render. Les apps complexes prennent 3-5 minutes à build. Coolify build les mêmes apps plus vite parce que Nixpacks sur un VPS dédié n'a pas de queue. Pour un workflow de deploy-on-push où on ship 5-10 fois par jour, la différence de vitesse d'itération se fait sentir.

Le problème du cold start sur le plan gratuit compte aussi. Après 15 minutes d'inactivité, les services web gratuits s'endorment. La première requête après la veille prend 30-60 secondes. Pour un produit face aux utilisateurs, ce délai tue l'expérience. Pour des outils internes et des side projects, c'est tolérable.

Quand choisir Render : On veut de l'hébergement managé avec un vrai plan gratuit pour les projets à faible trafic, et on est prêt à payer la tarification par service pour les charges de production.

Kamal — la philosophie de déploiement de 37signals

Kamal est différent de tout le reste sur cette liste. Ce n'est pas un PaaS. C'est un outil de déploiement construit par l'équipe derrière Basecamp et HEY. Leur philosophie : on devrait posséder ses serveurs et y déployer simplement, sans Kubernetes ni plateforme hébergée qui prend sa part.

Kamal déploie des conteneurs Docker sur un ou plusieurs serveurs via SSH en utilisant Traefik comme reverse proxy. Les déploiements zero-downtime sont intégrés — Kamal lance la nouvelle version, fait un health-check, bascule le trafic et stoppe l'ancienne version. Toute la configuration tient dans un seul fichier deploy.yml.

Les déploiements multi-serveurs sont une feature de premier ordre. La même commande kamal deploy pousse sur un serveur ou vingt. On définit les serveurs web, les serveurs de jobs et les services accessoires (comme les bases de données) dans le fichier de config. Kamal gère l'orchestration. C'est là que Kamal dépasse Coolify — des déploiements multi-serveurs production-grade sans Kubernetes.

Le compromis, c'est que Kamal est un outil de déploiement, pas une plateforme. Pas de dashboard web. Pas de provisionnement de bases en un clic. Les certificats SSL nécessitent de la configuration Traefik (ou laisser Traefik gérer Let's Encrypt automatiquement, ce qui fonctionne mais demande du setup). Pas de deploy previews. On gère son serveur, ses fichiers Docker Compose pour les bases de données et son setup de monitoring.

Kamal est une gem Ruby, et l'écosystème suppose une certaine familiarité avec Ruby et Rails. La configuration deploy.yml est bien documentée, et on n'a pas besoin d'écrire du Ruby pour utiliser Kamal, mais l'outillage penche Ruby. Les devs non-Rails peuvent l'utiliser, mais la communauté et les exemples sont très orientés Rails.

Quand choisir Kamal : On veut des déploiements zero-downtime production-grade sur ses propres serveurs avec de l'infrastructure-as-code, et on est à l'aise pour gérer tout le reste soi-même.

Portainer — la couche de gestion Docker

Portainer n'est pas une alternative à Coolify au sens classique. Il ne build pas le code, ne détecte pas le framework et ne gère pas les déploiements basés sur git. Ce qu'il fait, c'est donner une UI web soignée pour gérer les conteneurs Docker, les stacks Compose, les services Swarm et même les clusters Kubernetes.

Si le workflow de déploiement tourne déjà autour de fichiers Docker Compose, Portainer rend la gestion de ce workflow visuelle. On déploie une stack depuis un fichier Compose. On consulte les logs, les stats et les réseaux des conteneurs. On redémarre des services, on scale les replicas, on gère les volumes — tout depuis un navigateur.

La feature de templates d'apps fournit du déploiement one-click de services courants, similaire à la marketplace de CapRover. La bibliothèque de templates de Portainer est plus petite mais bien maintenue.

Là où Portainer manque en tant que remplacement de Coolify, c'est l'automatisation. Pas de git push to deploy. Pas de builds automatiques. Pas de Nixpacks ni de détection de buildpack. On build ses images Docker manuellement (ou via CI/CD) et Portainer gère les conteneurs en cours d'exécution. Pour les devs qui ont déjà un pipeline CI/CD, c'est un fit naturel. Pour les fondateurs qui veulent la simplicité type Heroku, c'est trop manuel.

La Community Edition est gratuite jusqu'à 3 nodes (environnements). La plupart des fondateurs solo n'ont besoin que d'un node. La Business Edition ajoute la gestion de registres, le RBAC et les logs d'activité, à partir de 15 $/mois par node.

Quand choisir Portainer : On déploie déjà avec Docker Compose et on veut une couche de gestion visuelle pour ses conteneurs. On le combine avec un pipeline CI/CD (GitHub Actions, GitLab CI) pour un workflow de déploiement automatisé.

Comparaison des coûts : self-hosted vs managé

Voici ce qu'un stack SaaS indie typique (app web + Postgres + Redis + background worker) coûte réellement sur chaque plateforme :

Les options self-hosted se regroupent autour de 5-10 $/mois quel que soit le nombre de services. Les plateformes managées facturent par service. On fait tourner trois apps avec des bases de données et l'écart de coût passe à 3-5x.

Mais le coût brut n'est pas toute l'histoire. Une plateforme managée fait économiser 2-5 heures par mois de maintenance serveur. Si le taux horaire (ou le coût d'opportunité du temps) dépasse la différence de prix, l'hébergement managé est le meilleur deal. Pour un side project pré-revenu, le self-hosting gagne en pure économie. Pour un SaaS qui génère 5K $/mois en MRR, la prime de 20-30 $/mois pour Railway est une erreur d'arrondi.

La décision self-hosting vs plateforme managée

C'est la vraie question derrière chaque recherche d'alternative à Coolify. Ce n'est pas quel outil est meilleur. C'est sur quoi on veut passer son temps.

Choisir le self-hosting (Coolify, CapRover, Dokku, Kamal) si :

• Le burn rate est serré et chaque euro compte
• On apprécie le travail d'infrastructure (ou au moins on n'en a pas horreur)
• On fait tourner plusieurs apps et services qui reviendraient cher sur des plateformes managées
• On veut le contrôle total sur ses données et son environnement de déploiement
• On est à l'aise avec l'administration de serveurs Linux

Choisir le managé (Railway, Render) si :

• On est solo et le temps est la ressource la plus contrainte
• On veut se concentrer exclusivement sur le développement produit
• On a besoin de features comme les environnements de preview et la collaboration d'équipe out of the box
• La fiabilité et l'uptime comptent plus que l'optimisation des coûts
• On préfère une tarification prévisible par service plutôt que de la gestion d'infrastructure

L'approche hybride fonctionne aussi. On fait tourner l'app de production sur Railway pour la fiabilité et l'uptime. On fait tourner les outils internes, les environnements de staging et les side projects sur Coolify pour les économies. Ce n'est pas un choix tout-ou-rien.

Quand rester sur Coolify

Coolify reste le bon choix si :

• On fait tourner 3+ apps et bases de données et on veut garder l'hébergement sous 15 $/mois au total
• On est assez technique pour gérer un serveur Linux et debug les problèmes Docker
• On veut un dashboard web pour gérer les déploiements (pas juste la CLI comme Dokku ou Kamal)
• Les rough edges ne dérangent pas parce que les économies le valent
• On aime posséder toute son infrastructure et ne pas dépendre d'un vendor

Coolify s'améliore vite. Le rythme de développement est agressif — de nouvelles features sont shippées chaque semaine. La communauté grandit. La documentation s'améliore à chaque release. La plupart des critiques sur Coolify portent sur le polish, pas sur les capacités. Si les rough edges actuels sont le principal point de friction, attendre quelques mois et mettre à jour peut suffire.

Pour un fondateur technique qui fait tourner un SaaS bootstrapé, Coolify sur un VPS Hetzner reste l'une des décisions d'infrastructure à plus haute valeur ajoutée. Les 5-10 $/mois qu'on dépense en hébergement au lieu de 50-100 $/mois sur des plateformes managées se cumulent sur la vie du business.

Conseils de setup et de migration

Si on quitte Coolify pour une plateforme managée :

1. Exporter les variables d'environnement d'abord. On copie chaque env var depuis les settings du projet Coolify. Les plateformes managées utilisent des formats différents — Railway importe les fichiers .env, Render utilise le dashboard.
2. Dumper les bases de données. On utilise pg_dump pour Postgres, mysqldump pour MySQL. On teste la restauration sur la plateforme cible avant de basculer. On vérifie les index et les extensions.
3. Basculer le DNS en dernier. On garde Coolify en parallèle pendant que la nouvelle plateforme est testée. On met à jour le DNS uniquement quand on a confirmé que tout fonctionne. Un TTL de 300 secondes donne une fenêtre de rollback rapide.

Si on passe à une autre option self-hosted :

1. Installer la nouvelle plateforme sur un VPS séparé. On n'essaie pas de faire tourner deux PaaS sur le même serveur. Un VPS Hetzner à 5 $/mois pour tester vaut le coût temporaire.
2. Migrer une app à la fois. On commence par un service non critique. On le déploie sur la nouvelle plateforme, on le teste pendant une semaine, puis on passe au suivant. Précipiter une migration complète invite le downtime.
3. Déployer le monitoring avant tout le reste. On installe Uptime Kuma ou un service de monitoring externe pour surveiller les nouveaux déploiements. Les pannes silencieuses pendant la migration sont le plus gros risque.

Quel que soit l'endroit où on va :

• Mettre en place des sauvegardes automatisées et tester la restauration
• Configurer des alertes d'espace disque pour que Docker ne remplisse pas le disque en silence
• Documenter son setup de déploiement — le futur soi-même remerciera le soi-même du présent quand quelque chose cassera à minuit