infracoolifycloud

Coolify + VPS : mon défaut, et ce qui me fait basculer vers le cloud managé

Pourquoi je pars de Coolify sur VPS Hetzner par défaut plutôt que du cloud managé, et les signaux concrets qui me font changer d'avis.

Le réflexe cloud managé n'est pas une décision, c'est une habitude

La plupart des devs seniors que je croise démarrent un nouveau projet en ouvrant la console AWS ou GCP. Pas parce qu'ils ont fait le calcul — parce que c'est le réflexe qu'on leur a inculqué. Moi je fais l'inverse : je démarre sur un VPS Hetzner avec Coolify, et je ne bouge vers du cloud managé que quand un signal concret me le demande.

Ce n'est pas une position anti-cloud. C'est un ordre d'opérations : d'abord connaître le trafic réel, ensuite choisir l'infra qui le sert. Partir cloud avant de connaître son trafic, c'est payer pour de l'élasticité dont on n'a pas encore besoin.

Ce que Coolify + VPS donne vraiment

Coolify, c'est une couche d'orchestration open-source au-dessus de Docker : déploiement Git-push, certificats TLS automatiques, bases de données managées sur la même machine, rollback en un clic. Posé sur un VPS Hetzner, ça couvre l'essentiel de ce qu'un produit early-stage a besoin — sans la facture ni la complexité opérationnelle d'un cluster Kubernetes.

# docker-compose.yml minimal servi par Coolify
services:
  api:
    build: .
    environment:
      - DATABASE_URL=${DATABASE_URL}
    labels:
      - coolify.managed=true

Le point n'est pas l'outil en lui-même — c'est que la boucle de déploiement reste identique à ce que tu ferais en local. Pas d'abstraction cloud propriétaire à apprendre, pas de lock-in sur des services managés qu'il faudra réécrire pour partir.

Le cas Vercel : pas un ennemi, un outil de contexte différent

Je ne dis pas que le cloud managé ou des plateformes comme Vercel sont mauvaises. Sur un site vitrine, une landing page ou une V1 sans backend stateful, Vercel reste un choix défendable — le confort de déploiement dépasse largement le coût, et gérer un VPS pour ça serait une perte de temps. La question n'est jamais "Coolify ou Vercel", c'est "est-ce que ce projet a un backend stateful, des jobs longs, des contraintes de coût prévisible" — si oui, VPS. Si non, la discussion ne se pose même pas.

Les signaux qui me font basculer vers le cloud managé

Je ne fixe pas de seuil chiffré à l'aveugle. Mais les signaux qualitatifs qui me font bouger sont clairs :

  • Le produit doit servir plusieurs régions avec une latence garantie — un seul VPS ne fait pas du multi-région propre
  • Le client a une exigence de conformité (SOC2, hébergement de données de santé) qui impose un provider certifié
  • Le trafic devient réellement élastique — des pics imprévisibles, pas juste "ça grossit"
  • L'équipe du client grandit et a besoin d'une plateforme opérée par quelqu'un d'autre que moi, parce que je ne serai pas éternellement le seul point de contact infra

Aucun de ces signaux n'est "on grossit". Grossir linéairement, un VPS plus gros l'absorbe très bien — Hetzner monte haut avant qu'un changement d'architecture soit nécessaire.

Ce que ça coûte de se tromper dans le sens inverse

Le vrai risque n'est pas de rester trop longtemps sur Coolify. C'est de partir cloud managé trop tôt, sur un produit qui n'a pas encore de trafic, et de payer pour une complexité opérationnelle (IAM, VPC, load balancers managés) que personne dans l'équipe ne maîtrise vraiment. J'ai vu des V1 perdre des semaines à configurer une infra Kubernetes pour une poignée d'utilisateurs actifs. Ce temps-là n'a rien produit pour le produit.

Le VPS n'est pas un dogme. C'est un point de départ qui force à connaître son trafic avant de payer pour l'anticiper.