Vous lisez un tutoriel : application Node, Redis, PostgreSQL, Nginx, worker — cinq conteneurs docker-compose copiés-collés. Sur un VPS à 8 Go de RAM, la pile démarre… puis s'effondre sous charge réelle parce que personne n'a dimensionné les ressources ni configuré les contrôles de santé. Docker n'était pas le problème. L'empilement prématuré l'était.
Docker résout une douleur précise : « ça marchait sur ma machine ». Il fige les dépendances et la commande de démarrage. Pour héberger une application web, commencez par un conteneur application bien construit — pas par une usine à gaz.
Étape 1 : un Dockerfile lisible
Partez d'une image de base officielle avec version figée (node:20-alpine, php:8.3-fpm). Utilisez un build multi-étapes : une phase pour compiler les assets, une phase d'exécution minimale. Exécutez le processus final avec un utilisateur non root, ajoutez un HEALTHCHECK HTTP simple, et maintenez un .dockerignore agressif — pas de node_modules local ni de dépôt .git embarqué.
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-alpine
USER node
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]
Un Dockerfile est un contrat d'exécution. S'il dépasse une page, simplifiez l'application ou scindez les services plus tard.
Étape 2 : données hors conteneur
Les uploads ne doivent pas vivre dans la couche éphémère du conteneur : utilisez un volume ou un stockage objet. La base SQL ne doit pas tourner sans volume nommé, sauf si vous préférez une base managée chez l'hébergeur. Les journaux peuvent sortir sur la sortie standard, mais prévoyez une agrégation externe. Les secrets ne doivent jamais être gravés dans l'image : injectez-les à l'exécution, comme le rappelle le guide Secrets de déploiement.
Sur un petit projet, application en Docker, PostgreSQL managé chez l'hébergeur évite d'opérer une base sur le même VPS.
Étape 3 : docker-compose seulement si nécessaire
Compose a du sens pour le développement local ou un petit VPS mono-locataire avec deux ou trois services couplés. En production, retenez-le si vous administrez vous-même Redis et l'application sur une même machine, ou si vous avez besoin d'un réseau interne app ↔ redis sans exposer Redis publiquement. Sinon, un seul service app derrière un reverse proxy (Caddy ou Nginx sur l'hôte, ou un conteneur reverse proxy unique) suffit.
Déployer sur VPS : pattern simple
Construisez l'image en intégration continue, poussez-la vers un registre (GHCR, Scaleway Registry…), puis sur le VPS exécutez docker pull et docker run avec volumes et --restart unless-stopped. Terminez le TLS sur un reverse proxy hôte qui pointe vers le port du conteneur. Centralisez les journaux via docker logs ou un agent, et mettez à jour en redéployant une image taguée — jamais :latest sans pin explicite.
Les PaaS conteneurisés (Clever Cloud, Fly.io, Render) absorbent registre et orchestration légère si vous préférez éviter l'administration du VPS.
Erreurs débutant en production
Évitez :latest sans version figée : le déploiement devient non reproductible. N'exécutez pas le conteneur en root : une évasion est plus dangereuse. Posez des limites mémoire : un OOM kill silencieux peut surprendre. Ne copiez pas un compose de développement en production avec ports exposés et mots de passe faibles. Enfin, ne confondez pas Docker et orchestration : Docker seul n'assure pas la haute disponibilité multi-nœud — Kubernetes relève d'une autre ligue.
Le sommet : Docker simplifie le deploy, pas l'architecture
Avant d'empiler, demandez : qu'est-ce qui doit monter en charge séparément ? Si la réponse est « rien pour l'instant », un conteneur suffit.
Décider et avancer sans angle mort
Rédigez un Dockerfile multi-étapes avec utilisateur non root, externalisez la base et les fichiers lourds, et réservez Compose aux services réellement co-localisés. Branchez l'intégration continue pour construire et pousser l'image, puis faites tirer une version taguée sur le VPS. Comparez les hébergeurs Docker et PaaS via l'annuaire et le guide PaaS ou serveur pour placer la complexité ailleurs si besoin.
Questions fréquentes
Docker remplace-t-il un VPS classique ?
Non. Docker encapsule l'application ; il faut toujours une machine hôte. Il standardise l'environnement d'exécution sans remplacer l'infrastructure.
Un conteneur ou docker-compose dès le départ ?
Un conteneur applicatif avec base managée suffit souvent. Compose devient utile si Redis ou PostgreSQL tournent sur la même machine que l'application.
Où stocker les données persistantes ?
Volumes Docker ou services managés — pas le système de fichiers éphémère seul, sous peine de perdre les données au redémarrage.
Docker sur mutualisé ?
Rarement disponible. Docker cible VPS, dédié ou PaaS conteneurisé.
Docker pour héberger une application, ce n'est pas collectionner des conteneurs. C'est un artefact déployable — puis autant de services que votre architecture exige réellement.