Déployer en on-premise

1. Pourquoi Coolify ?

L'application existe. Elle tourne bien en local, les fonctionnalités principales sont là, et arrive maintenant une étape moins glamour : la mettre en ligne sans transformer le serveur en atelier de bricolage permanent.

Quand on parle de mise en ligne aujourd'hui, beaucoup pensent directement à Vercel, Railway, Render ou Fly.io. D'autres pensent encore à un petit forfait d'hébergement à 10 euros par mois, à quelques GitHub Actions bricolées pour faire partir les fichiers au bon endroit, ou, pour les plus débutants, à une session FileZilla tard le soir. Et puis il y a aussi l'autre extrême : penser tout de suite à Kubernetes, alors qu'en pratique c'est souvent trop lourd, trop tôt, ou simplement pas adapté à une petite application visitée par deux ou cinq personnes par jour. L'idée reste pourtant toujours la même : réussir à mettre le projet en ligne sans se battre contre l'infrastructure plus que contre le code. Coolify s'inscrit dans cette logique, mais avec une différence importante : au lieu de louer directement la plateforme chez un tiers, on l'installe sur sa propre machine. C'est ce qui le rend intéressant pour un déploiement on-premise.

En clair, Coolify apporte une expérience de déploiement moderne sur une infrastructure que l'on contrôle soi-même. On garde la VM, le stockage, les domaines, la base, les accès SSH, mais on évite de tout refaire à la main à chaque mise en production.

2. Installer Coolify sur une VM

La première étape reste donc très simple : prendre une VM Linux chez un provider, s'y connecter en SSH, puis installer Coolify. Pas besoin d'en faire plus au début.

Exemple :

ssh root@IP_DE_LA_VM
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

À ce stade, il ne s'agit pas encore de déployer l'application. Il s'agit d'abord d'avoir une machine propre, avec un vrai point d'entrée pour les futurs déploiements.

Une fois l'installation terminée, le plus simple est d'ouvrir l'adresse IP de la VM dans un navigateur. Coolify affiche alors son interface d'initialisation. Il suffit de créer l'email administrateur, de terminer la configuration de départ, puis d'entrer dans le dashboard. Et là, le parallèle avec les plateformes modernes saute vite aux yeux : on retrouve un tableau de bord très propre, presque "Vercel like", mais chez soi.

Sur cette capture, le dashboard affiche déjà deux projets déployés sur la même VM. L'idée est simplement de montrer que Coolify peut centraliser plusieurs applications au même endroit.

3. Préparer une application propre

Mais avant Coolify, il faut une base saine. Contenériser l'application n'est pas une obligation absolue pour exister sur Coolify, mais dans la pratique c'est souvent ce qui rend le déploiement plus simple, plus lisible et plus reproductible. Si l'application dépend encore de manipulations manuelles à chaque lancement, le vrai problème n'est pas l'outil de déploiement. Le vrai problème, c'est que le projet reste difficile à déplacer proprement.

Premier conseil donc : contenériser l'application. Un docker-compose.yml suffit largement dans beaucoup de cas. Le but n'est pas de construire une plateforme de cloud maison. Le but est d'avoir une application qui sait démarrer avec ses dépendances, son réseau, ses variables d'environnement et ses volumes, sans rituel mystérieux avant chaque lancement.

Exemple simple :

services:
  app:
    build:
      context: .
    restart: unless-stopped
    env_file:
      - .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-app}
      POSTGRES_USER: ${POSTGRES_USER:-app}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  postgres_data:

À partir de là, Coolify devient surtout une surcouche confortable : branchement Git, variables d'environnement, domaine, HTTPS, logs, redéploiement. Il ne remplace pas les fondations. Il les rend simplement plus agréables à exploiter.

4. Le vrai terrain de jeu : New Resource

Une fois Coolify installé, accessible via l'adresse IP de la VM, et l'utilisateur administrateur créé, vient le moment de poser le premier vrai élément de travail : le projet. Dans la pratique, on commence donc par aller dans l'onglet Projects, puis New Project. Une fois ce projet créé, on peut y ajouter une ressource.

Une ressource, dans Coolify, c'est simplement ce que l'on veut faire tourner : une application, une base de données, un service, un worker, ou une autre brique du même genre. Dit autrement, le projet sert à regrouper, et la ressource sert à déployer.

On peut bien sûr partir sur une application classique reliée à un dépôt Git, public ou privé. Mais l'onglet ne s'arrête pas là. Il propose aussi des déploiements à partir d'un Dockerfile, d'un Docker Compose, d'une image Docker existante, de bases de données comme PostgreSQL, MySQL, MariaDB, Redis ou MongoDB, et surtout une longue liste de services prêts à l'emploi.

Et c'est probablement ce qui rend l'ensemble assez impressionnant : on ne parle plus seulement de "mettre son app en ligne". On entre dans un univers open source beaucoup plus large, avec la possibilité d'ajouter autour de son projet des outils comme Grafana, Gitea, Ghost, Immich, LibreChat, Langfuse, Jenkins, Mattermost, Mailpit, Homepage, et bien d'autres. Ce n'est plus seulement un bouton "deploy". C'est déjà une petite porte vers tout un écosystème self-hosted.

5. Séparer la quali de la production

Le premier réflexe à avoir quand on veut déployer en production, c'est souvent de ne pas commencer par la production. Dans l'idéal, la première ressource créée dans le projet devrait être une quali. C'est elle qui sert de zone de validation : on y vérifie qu'une branche tient bien, qu'une release démarre correctement, qu'une migration passe, ou qu'une idée mérite encore un peu de calme avant d'arriver devant de vrais utilisateurs. La production, elle, n'a pas ce confort : elle sert les vraies données et les vrais utilisateurs.

En pratique, même avec une seule VM, il est possible d'avoir une application quali et une application prod. Elles peuvent partager la même machine mais pas les mêmes secrets, pas les mêmes volumes, pas les mêmes bases, et idéalement pas le même domaine.

app.example.com        -> production
app-quali.example.com  -> qualification

Le réflexe important est donc simple : l'image ou le dépôt peuvent être les mêmes, mais les variables d'environnement, le domaine, le stockage et la base doivent rester séparés.

Dans Coolify, le chemin le plus simple est souvent le suivant : créer d'abord la quali, la configurer proprement, puis utiliser le bouton Clone pour en déduire la prod. Ce clone fait gagner du temps, mais il ne faut pas oublier l'essentiel ensuite : changer les variables d'environnement, le domaine, et tout ce qui distingue réellement une production d'une qualification.

Le parallèle avec Git arrive presque tout seul : une ressource peut très bien suivre une branche donnée. Par exemple, une branche pour la qualification, une autre pour la production. Ce n'est pas une obligation, mais cela aide souvent à garder un flux lisible entre ce qui est en test et ce qui est réellement publié.

Et au fond, c'est souvent pour cela qu'on a entendu un jour : "ne pousse pas directement sur main". Dans beaucoup de pratiques, main finit justement par représenter ce qui part en production, ou ce qui s'en rapproche le plus. Séparer les branches, ce n'est donc pas seulement une manie d'équipe. C'est une façon assez simple d'éviter qu'un test, une idée encore fragile, ou une modification trop rapide arrive directement au mauvais endroit.

Pour régler cela dans Coolify, il suffit ensuite d'ouvrir la ressource concernée, par exemple quali ou prod, puis la partie Environment Variables. C'est ici que l'on sépare réellement les deux environnements : base de données, secrets applicatifs, clés API, domaine, mode d'exécution. Le code peut rester le même, mais le contexte, lui, doit changer.

Petit rappel important : il ne faut jamais pousser les variables d'environnement de production sur GitHub. Même si le flux de travail ressemble à CI -> GitHub -> pull -> build dans la VM, les secrets ne doivent pas vivre dans le dépôt. Ils doivent rester dans le gestionnaire d'environnement de la plateforme, ici Coolify.

6. Domaines, logs et vie quotidienne

Une fois l'application branchée, deux choses deviennent vite très concrètes dans Coolify : le domaine et les logs. Ce sont souvent ces deux points qui transforment un projet "déployé quelque part" en application réellement exploitable.

Configuration d'une ressource Coolify avec les champs de domaine dans Configuration -> General.

En pratique, c'est ici que l'on renseigne le domaine qui doit pointer vers la ressource. Dans un projet basé sur Docker Compose, on peut même voir plusieurs champs selon les besoins, par exemple pour l'application elle-même ou pour un service de migration. Et juste à côté, l'onglet Logs devient vite le meilleur allié quand une application ne démarre pas, redémarre en boucle, échoue au build, ou n'arrive pas à joindre sa base de données.

7. Travailler à plusieurs

Dans un contexte d'équipe, l'onglet Teams mérite aussi un coup d'oeil. Depuis la sidebar de Coolify, il est possible d'aller dans Teams, puis Members, pour ajouter d'autres personnes à l'espace de travail. C'est simple, mais très utile dès que le déploiement ne repose plus sur une seule personne.

Un autre onglet utile, surtout quand l'application commence à avoir de vrais utilisateurs, c'est Notifications. Coolify peut envoyer des alertes vers Discord, Telegram, Slack et d'autres canaux du même genre. L'idée est simple : si un déploiement échoue, si un service tombe, ou si la production casse pendant que personne n'a l'onglet ouvert, quelqu'un peut quand même être prévenu. Et pour le coup, c'est presque magique : il suffit de brancher les bons canaux pour ne plus découvrir les problèmes par hasard.

8. Régler l'instance elle-même

Et puis il y a la partie Settings, qui concerne cette fois toute l'instance Coolify, pas seulement une application. C'est ici que l'on retrouve la configuration générale : domaine principal de l'instance, nom, fuseau horaire, IP publique, sauvegardes, email transactionnel, OAuth, mises à jour, ou réglages plus avancés. Ce n'est pas l'écran le plus spectaculaire, mais c'est souvent là que se rangent les détails qui donnent une vraie forme à la plateforme.

9. Ne pas oublier les sauvegardes

Ce qui mérite d'être surveillé dès le départ :

• les volumes persistants pour la base et les fichiers
• les sauvegardes de base de données
• les variables d'environnement séparées entre quali et prod
• la politique de redéploiement
• les logs applicatifs quand un déploiement échoue
• le domaine et le certificat HTTPS

Petite parenthèse sur la base de données : dès qu'elle commence à contenir de vraies données, mieux vaut prendre l'habitude de la sauvegarder tôt. Dans Coolify, cela se fait assez simplement avec Scheduled Tasks. Le chemin est le même : projet -> ressource -> onglet Scheduled Tasks. L'idée est de lancer une commande tous les jours, par exemple à 4h00, pour faire un dump puis l'envoyer vers un bucket S3 chez un autre provider. Le but n'est pas de préparer un scénario de fin du monde. Le but est simplement d'éviter que toute l'histoire du projet repose sur un seul serveur.

10. Ce qu'il faut retenir

Le point à retenir est peut-être là : déployer en on-premise ne veut pas dire revenir en arrière, ni tout faire à la main dans un terminal sombre à 2 heures du matin. Cela veut surtout dire reprendre un peu la main sur l'infrastructure, sans forcément tomber dans quelque chose de trop lourd pour le projet.

Avec une VM propre, une application à peu près bien préparée, une quali, une prod, quelques sauvegardes, et un outil comme Coolify, on obtient déjà quelque chose de très sérieux. Pas parfait, pas "cloud native 3000", mais largement suffisant pour beaucoup de projets réels.