Déploiement Docker sur Clever Cloud : du Dockerfile au pipeline CI/CD

Introduction

Clever Cloud supporte nativement PHP, Node.js, Python et bien d’autres runtimes. Mais il est souvent plus pratique de rassembler toute la configuration dans une image Docker pour simplifier le déploiement.

Derrière la question technique se cache souvent un choix stratégique : remplacer un outil SaaS payant par son équivalent open-source. Au lieu de payer un abonnement mensuel par utilisateur pour un outil de feedback, de monitoring ou de capture d’emails, vous déployez une image Docker hébergée sur votre propre infrastructure. Vos données restent sur des serveurs européens, sous votre contrôle, et le coût est fixe quel que soit le nombre d’utilisateurs.

Nous allons prendre en exemple deux cas concrets que nous utilisons chez SmartBooster : Maildev pour capturer les emails de test et Fider pour la gestion des feedbacks clients. Dans les deux cas, le workflow est identique.

1. Pourquoi remplacer un SaaS par un outil open-source ?

Pour les outils transverses (capture d’emails, gestion de feedbacks, monitoring…), vous avez deux options : payer un abonnement SaaS ou héberger vous-même un équivalent open-source.

Le problème du modèle SaaS par utilisateur

La plupart des SaaS facturent par siège. Un outil de feedback à 25 €/utilisateur/mois devient rapidement coûteux dès que votre équipe ou votre base clients grandit. À cela s’ajoute la dépendance aux conditions tarifaires de l’éditeur : une augmentation de prix ou un changement de plans et vous êtes contraint de migrer dans l’urgence.

La question de la souveraineté des données

Les SaaS américains sont soumis au Cloud Act, qui autorise les autorités américaines à accéder aux données stockées par des entreprises américaines, même sur des serveurs européens. Pour des données clients ou des retours produit sensibles, l’auto-hébergement est la seule garantie réelle de maîtrise.

Le cas CapRenov : de Canny à Fider

Pour le logiciel CapRenov+, nous utilisions Canny pour collecter les demandes d’amélioration des utilisateurs. Canny est un SaaS américain efficace, mais dont le coût devient significatif à mesure que la base d’utilisateurs grandit.

Nous avons migré vers Fider en 2026, un outil open-source équivalent, déployé sur Clever Cloud. La migration a permis de reprendre la propriété complète des données et d’aller plus loin : nous avons activé la connexion SSO avec l’application CapRenov. Les utilisateurs se connectent directement avec leur compte CapRenov, sans créer un second compte.

Résultat : demandesutilisateurs.cap-renov.fr, une expérience utilisateur cohérente avec le reste de l’application, des données hébergées en France et un coût fixe.

C’est un exemple concret d’alternative au logiciel SaaS : utiliser l’open-source non par idéologie, mais pour des raisons économiques et de souveraineté des données.

2. La stratégie “utiliser plutôt que construire”

Pour les outils transverses, développer une solution maison est rarement justifié. Des images Docker open-source couvrent ces besoins avec fiabilité.

L’approche consiste à créer un dépôt Git contenant uniquement un Dockerfile qui référence l’image publique, puis à déployer ce dépôt sur Clever Cloud comme n’importe quelle application.

3. Créer l’application Docker sur Clever Cloud

Depuis la console Clever Cloud, créez une nouvelle application en choisissant le runtime Docker.

Quelques réglages à faire immédiatement après la création :

• Scaling : une instance Nano suffit pour les outils légers comme Maildev. Pour un outil avec base de données comme Fider, passez en XS.
• Force HTTPS : activez cette option dans l’onglet Information pour forcer le HTTPS sur toutes les requêtes.
• Domain name : supprimez le domaine généré par défaut et ajoutez un sous-domaine personnalisé (ex: maildev.votreprojet.cleverapps.io).

Ajouter les add-ons nécessaires

Si l’outil requiert une base de données ou du stockage fichier, Clever Cloud propose des add-ons à lier directement à l’application :

• PostgreSQL pour les outils avec persistance relationnelle (Fider utilise un plan XXS_SML minimum)
• Cellar (compatible S3) pour le stockage de fichiers (images, pièces jointes)

4. Gérer l’exposition réseau

Le port 8080

Clever Cloud attend que votre application écoute sur le port 8080. Pour les images Docker qui exposent un autre port par défaut, vous devrez soit remapper dans le Dockerfile, soit configurer via variable d’environnement. Pour Fider, c’est simple : PORT=8080 dans les variables d’environnement suffit.

Les redirections TCP

Certains outils nécessitent un accès via un protocole autre que HTTP, comme le SMTP pour Maildev. Clever Cloud propose des redirections TCP : la plateforme attribue un port aléatoire (ex: 20425) qui redirige vers le port interne de votre conteneur.

Après avoir créé la redirection, copiez le port attribué et ajoutez la variable d’environnement CC_DOCKER_EXPOSED_TCP_PORT avec cette valeur dans la configuration de l’application.

5. Configurer via les variables d’environnement

Les variables d’environnement sont le seul mécanisme de configuration à utiliser. Elles permettent d’adapter le comportement de l’image sans modifier le Dockerfile, et de gérer proprement les secrets.

Clever Cloud injecte automatiquement les variables des add-ons liés (ex: POSTGRESQL_ADDON_DIRECT_URI, CELLAR_ADDON_KEY_ID). Référencez-les directement dans vos variables applicatives.

Pour Fider, le bloc de variables minimal ressemble à ceci :

BASE_URL="https://fider.votreprojet.fr"
DATABASE_URL="%POSTGRESQL_ADDON_DIRECT_URI%"
PORT="8080"
JWT_SECRET="votre_secret_64_caractères"
EMAIL_NOREPLY="no-reply@votreprojet.fr"

Et pour Maildev votre liste de variable d’environnement est minime avec juste le port HTTP et la redirection TCP :

6. Le Dockerfile et l’automatisation CI/CD

Dockerfile minimal : utiliser une image pré-construite

Le Dockerfile est volontairement minimal : il référence l’image publique et expose les ports nécessaires. Voici le fichier complet pour Maildev, avec le relay vers Tipimail pour les envois réels depuis la recette :

FROM maildev/maildev:1.1.1
LABEL maintainer="dev@email.fr"

EXPOSE 8080 {PORT_TCP}

CMD ["--web-user", "{USER}", "--web-pass", "{PASSWORD}",
     "--web", "8080",
     "--smtp", "{PORT_TCP}",
     "--hide-extensions", "STARTTLS",
     "--outgoing-host", "{SMTP_HOST}",
     "--outgoing-port", "{SMTP_PORT}",
     "--outgoing-user", "{SMTP_USER}",
     "--outgoing-pass", "{SMTP_PASS}"]

Détail des paramètres :

• --web-user / --web-pass : identifiants HTTP Basic pour protéger l’interface web de visualisation des emails
• --web 8080 : port d’écoute de l’interface web (obligatoire sur Clever Cloud)
• --smtp {PORT_TCP} : port d’écoute SMTP, à remplacer par la valeur de votre redirection TCP Clever Cloud
• --hide-extensions STARTTLS : désactive STARTTLS pour éviter les erreurs de handshake TLS sur les connexions internes
• --outgoing-host / --outgoing-port / --outgoing-user / --outgoing-pass : configuration du relay SMTP sortant vers votre service d’envoi d’email (Mailgun, Brevo, Tipimail…) pour les emails que vous choisissez explicitement de laisser partir en recette

Pour Fider, le Dockerfile est encore plus direct :

FROM getfider/fider:v0.33.0

EXPOSE 8080 3000

HEALTHCHECK --timeout=5s CMD ./fider ping

CMD ./fider migrate && ./fider

La ligne CMD ./fider migrate && ./fider joue un rôle clé : elle exécute les migrations de base de données à chaque démarrage du conteneur, puis lance le serveur. Pas besoin de script séparé pour la migration initiale. Le HEALTHCHECK permet à Clever Cloud de détecter que l’application est prête à recevoir du trafic.

Quand utiliser un post_build.sh ?

Certains projets nécessitent une étape de build des assets frontend avant de démarrer. Clever Cloud propose la variable CC_POST_BUILD_HOOK qui exécute un script shell après le build Docker et avant le démarrage du conteneur. C’est utile quand votre image embarque les sources et doit compiler le frontend au déploiement :

# post_build.sh — exécuté via CC_POST_BUILD_HOOK
set -e

# Frontend build
npm install
make build-ssr
make build-ui

Pour les images pré-construites comme getfider/fider:v0.33.0, ce hook n’est pas nécessaire : tout est déjà compilé dans l’image. Réservez ce mécanisme aux projets qui buildent depuis les sources.

Automatiser les déploiements depuis GitLab

Pour automatiser les déploiements depuis GitLab, ajoutez un job utilisant l’image clevercloud/clever-tools :

deploy:
  stage: deploy
  image:
    name: clevercloud/clever-tools:latest
    entrypoint: ["/bin/sh", "-c"]
  when: manual
  script:
    - clever deploy -f -a nom-de-votre-app

L’option when: manual est recommandée pour les environnements de production : le déploiement se déclenche sur action volontaire depuis l’interface GitLab, pas à chaque push. La commande clever deploy et ses options sont documentées dans le cycle de vie du déploiement via CLI.

Le job restart : quand un déploiement échoue

Clever Cloud peut se retrouver dans un état instable après un déploiement en erreur : l’instance ne répond plus mais la plateforme ne relance pas le conteneur automatiquement. Dans ce cas, un simple clever restart suffit, sans repousser le code. Le paramètre --commit $CI_COMMIT_SHA force Clever Cloud à utiliser le commit exact du pipeline, ce qui évite les ambiguités quand plusieurs déploiements se sont enchaînés.

restart:
  stage: deploy
  image:
    name: clevercloud/clever-tools:latest
    entrypoint: ["/bin/sh", "-c"]
  when: manual
  script:
    - clever restart --commit $CI_COMMIT_SHA -a nom-de-votre-app
  cache: {}

Avoir ce job à portée dans le pipeline évite de passer par la console Clever Cloud manuellement et garde une trace de qui a redémarré l’application et à quel moment.

7. Le .dockerignore : ne pas exposer ce qu’on n’a pas à déployer

Comme .gitignore empêche de versionner certains fichiers dans Git, .dockerignore empêche de les inclure dans le contexte de build Docker.

La différence clé entre .gitignore et .dockerignore

Quand vous lancez docker build, Docker envoie au daemon l’ensemble des fichiers du répertoire courant : c’est le “contexte de build”. Sans .dockerignore, tout est envoyé, y compris votre dossier .git (parfois plusieurs centaines de Mo), vos node_modules, vos fichiers .env et votre documentation.

.gitignore contrôle ce qui entre dans Git. .dockerignore contrôle ce qui entre dans l’image Docker. Les deux ne sont pas synchronisés automatiquement : un fichier peut être ignoré par Git et quand même se retrouver copié dans l’image si vous ne l’excluez pas explicitement.

Pour un dépôt qui contient uniquement un Dockerfile (cas typique de Maildev ou Fider), un .dockerignore minimal suffit :

.git
.gitignore
README.md
docs/
*.log
.env
.env.local
.DS_Store

L’impact est double : les builds sont plus rapides (moins de données à transférer au daemon) et vous évitez d’inclure accidentellement des secrets dans l’image si votre workflow évolue.

8. Ajouter un robots.txt pour bloquer l’indexation

Les outils déployés en interne (Maildev, tableau de bord de monitoring, Fider en accès restreint…) ne doivent pas être indexés par les moteurs de recherche. Si votre outil expose un sous-domaine public, pensez à bloquer son indexation.

Fider sert automatiquement un robots.txt configurable depuis l’interface d’administration. Pour les outils qui ne le gèrent pas nativement, deux options existent : soit ajouter un fichier robots.txt dans le répertoire de fichiers statiques de l’application, soit configurer un en-tête HTTP X-Robots-Tag: noindex au niveau de votre reverse proxy.

L’essentiel : ne laissez pas Googlebot indexer vos environnements internes par défaut. Une page d’authentification publiquement accessible suffit à ce que Google commence à la visiter régulièrement.

9. Maintenir l’application

Les logs sont accessibles directement depuis la console Clever Cloud ou via la CLI avec clever logs. Ils sont indispensables pour diagnostiquer les erreurs au démarrage du conteneur, notamment les problèmes de connexion aux add-ons ou de configuration manquante.

Pour les tâches d’initialisation complexes (migrations de base de données, création de bucket…), Clever Cloud propose la variable CC_POST_BUILD_HOOK qui exécute un script shell après le build et avant le démarrage du conteneur.

10. Les mises à jour : comment et à quelle fréquence

Mettre à jour un outil Docker sur Clever Cloud se résume à trois étapes :

1. Consulter le changelog du projet (GitHub Releases ou CHANGELOG.md) pour identifier les ruptures de compatibilité et les migrations nécessaires
2. Modifier le tag de l’image dans le Dockerfile (ex: v0.33.0 → v0.34.0)
3. Commiter, pousser et déployer via le pipeline CI/CD

À quelle fréquence mettre à jour ?

• Patches de sécurité : dès leur publication. Abonnez-vous aux notifications GitHub Releases du projet pour être alerté sans avoir à surveiller manuellement.
• Versions mineures : mensuel ou dès que la version est stable. Lisez le changelog avant d’appliquer.
• Versions majeures : planifiées, après test sur l’environnement de recette. Les versions majeures peuvent inclure des changements de schéma de base de données ou de configuration qui nécessitent des actions manuelles.

11. Bonne pratique SmartBooster : documentez votre dépôt

Chaque dépôt Git hébergeant un outil Docker doit contenir un README.md qui centralise les informations utiles pour l’équipe. C’est la première chose que l’on consulte quand on revient sur un projet six mois plus tard ou quand un nouveau développeur doit intervenir.

Structure recommandée

# Maildev — Projet X

Service de capture d'emails pour les environnements de test.

## Liens utiles
- Interface Maildev (recette) : https://maildev.recette.votreprojet.fr
- Console Clever Cloud : https://console.clever-cloud.com/organisations/org_xxx/applications/app_xxx
- Documentation Maildev : https://maildev.github.io/maildev/

## Variables d'environnement
| Variable | Description |
|---|---|
| PORT | Port HTTP (toujours 8080 sur Clever Cloud) |
| CC_DOCKER_EXPOSED_TCP_PORT | Port SMTP attribué par la redirection TCP Clever Cloud |
| WEB_USER | Login pour l'interface web Maildev |
| WEB_PASS | Mot de passe pour l'interface web Maildev |

## Déploiement
Le déploiement se fait via le job GitLab `deploy` (manuel).
1. Vérifier que le Dockerfile pointe vers la bonne version de l'image
2. Déclencher le job depuis l'interface GitLab CI/CD > Pipelines

## How-to

**Changer le mot de passe d'accès**
Modifier les variables `WEB_USER` et `WEB_PASS` dans la console Clever Cloud,
puis redémarrer l'application depuis la console.

**Retrouver le port SMTP à configurer dans l'application cliente**
La valeur de `CC_DOCKER_EXPOSED_TCP_PORT` est visible dans la section
"TCP Redirections" de la console Clever Cloud. C'est ce port qui doit être
renseigné comme serveur SMTP dans votre application.

## FAQ

**Q : Les emails envoyés depuis la recette arrivent chez de vrais destinataires ?**
R : Non, Maildev intercepte tous les envois SMTP locaux. Seuls les emails relayés
via la configuration outgoing-host quittent le serveur.

**Q : L'interface est-elle sécurisée ?**
R : Oui, via HTTP Basic Auth (variables WEB_USER / WEB_PASS) et HTTPS forcé.

Ce README évolue au fil des incidents et des questions de l’équipe. Chaque fois qu’un membre pose une question sur l’outil, la réponse s’ajoute dans la section FAQ ou How-to. C’est le meilleur moyen de capitaliser sur l’expérience sans dépendre de la mémoire de chacun.

Conclusion

Un dépôt Git avec un Dockerfile de quelques lignes, un .dockerignore, quelques variables d’environnement et un add-on PostgreSQL : c’est tout ce qu’il faut pour héberger un outil complet sur Clever Cloud. Cette approche s’applique à des dizaines d’outils open-source et évite de réinventer des solutions pour des besoins transverses bien couverts par l’écosystème Docker.

Si cette logique vous intéresse au-delà de l’infrastructure, nous avons développé une réflexion plus large sur les alternatives aux logiciels SaaS : quand le sur-mesure ou l’open-source remplace avantageusement un abonnement mensuel sur le long terme.

Si vous utilisez déjà Clever Cloud pour vos applications Symfony ou Node.js, vous pouvez centraliser l’ensemble de votre infrastructure sur la même plateforme.