Comment exécuter Docker sur un VPS avec Portainer (guide 2026)

Avez-vous déjà entendu parler de Dockerception ?

Eh bien, accrochez-vous. Nous allons descendre dans le terrier du lapin.

Portainer, l'interface web que vous vous apprêtez à installer par-dessus Docker, est lui-même un conteneur Docker.

C'est un outil qui tourne sur la chose même qu'il gère. Vous le lancez avec une seule ligne docker run. La première chose qu'il fait ensuite est de repasser par un petit trou dans l'hôte (un fichier socket) pour demander au démon Docker de lui montrer tous les conteneurs de la machine, y compris lui-même. Depuis cet onglet de navigateur, vous gérez tous vos autres conteneurs Docker.

L'interface que vous avez sous les yeux apparaît dans sa propre liste de conteneurs.

Sur un VPS que vous payez déjà et où vous êtes déjà à l'aise avec SSH, Portainer s'installe proprement par-dessus Docker sans rien changer au fonctionnement de ce qui se trouve en dessous.

C'est tout l'intérêt.

Une machine de 4 Go peut être un point de départ pour Docker et Portainer, mais ce sont les applications que vous ajoutez qui déterminent si cette capacité suffit. Pensez domotique, photothèque familiale, assistant IA et la newsletter que vous menacez de lancer depuis des mois, le tout sur un serveur qui vous appartient vraiment.

Voici comment le mettre en route, le sécuriser et commencer à en tirer parti.

Qu'est-ce que Portainer, exactement ?

Portainer est une interface web qui tourne comme un conteneur Docker et gère vos autres conteneurs via le socket Docker.

Il s'agit essentiellement d'une interface dans le navigateur (une GUI Docker) pour les mêmes commandes Docker que vous taperiez sinon à la main. Elle ajoute la gestion des stacks, le contrôle d'accès basé sur les rôles (si vous passez à Business Edition) et un tableau de bord qui affiche le CPU et la mémoire.

C'est la connexion au socket qui fait tout fonctionner. Le montage ressemble à -v /var/run/docker.sock:/var/run/docker.sock dans la commande d'installation, et cette seule ligne fait tout le gros du travail. Sans elle, Portainer est une interface pour un hôte Docker vide. Avec elle, Portainer devient la télécommande de l'hôte Docker.

Gardez une chose à l'esprit : tout processus capable d'atteindre /var/run/docker.sock peut contrôler le démon Docker. La documentation de sécurité de Docker est sans détour : seuls des utilisateurs de confiance doivent y être autorisés, car un conteneur lancé via le démon peut monter l'intégralité du système de fichiers de l'hôte et le modifier sans restriction. C'est une fonctionnalité quand c'est Portainer qui le demande, et un problème quand c'est un conteneur que vous avez lancé la semaine dernière en oubliant que vous lui aviez donné accès au socket.

Traitez le montage du socket comme une capacité privilégiée, et contrôlez chaque autre conteneur qui en réclame un.

Avez-vous besoin de Portainer si vous utilisez déjà Docker ?

Non. Docker fonctionne très bien depuis le terminal, et beaucoup de gens font tourner quelques conteneurs pendant des années sans jamais installer d'interface par-dessus.

Portainer est fait pour vous si :

• Vous allez jongler avec plus de deux ou trois conteneurs Docker pour différentes applications.
• Vous préférez cliquer sur restart plutôt que de retaper une commande Compose à 23 h.
• Vous partagez l'accès avec quelqu'un qui ne vit pas dans un terminal.
• Vous voulez déployer des mises à jour de stack depuis un dépôt Git sans écrire de script de déploiement.

Passez-vous de Portainer si :

• Vous exécutez un ou deux conteneurs qui changent rarement.
• Vous êtes déjà à l'aise avec Docker Compose et cela vous convient très bien.

Docker est suffisamment répandu pour que ce choix n'ait rien de marginal. Dans l'enquête Stack Overflow Developer Survey 2025, 71 % des répondants déclaraient utiliser Docker. C'est le meilleur résultat parmi les technologies de développement cloud et d'infrastructure, après un bond de 17 points de pourcentage par rapport à 2024. Le projet Portainer compte plus de 38 000 étoiles sur GitHub en août 2026.

D'autres options existent. Dokploy, par exemple, s'oriente davantage vers une PaaS auto-hébergée complète, qui gère pour vous les applications, les bases de données et le SSL. Portainer reste plus proche de Docker brut : mêmes fichiers Compose, mêmes images, simplement avec une interface par-dessus.

Si vous vivez dans tmux et n'exécutez qu'une seule application, fermez cet onglet. Tout va bien pour vous. Si vous faites tourner quatre applications auto-hébergées et que vous avez cherché Comment voir les logs Docker, déjà ? deux fois ce mois-ci, poursuivez votre lecture.

Quelle taille de VPS pour exécuter Docker et Portainer ?

Portainer n'indique aucun minimum de RAM. Un VPS de 4 Go peut convenir à une petite stack, mais dimensionnez-le en fonction des besoins cumulés du système d'exploitation, du démon Docker et de chaque conteneur que vous prévoyez d'exécuter.

La page des prérequis de Portainer en dit étonnamment peu sur la RAM : le Server est livré sous forme de conteneur léger, et les recommandations de performance de la documentation concernent le stockage (nous y reviendrons plus bas). Le vrai calcul de RAM, ce sont vos charges de travail : prévoyez de la mémoire pour le système d'exploitation, le démon Docker et chaque conteneur que vous prévoyez d'exécuter. Prévoyez aussi de l'espace disque pour les logs. Le pilote de logs json-file utilisé par défaut par Docker n'effectue aucune rotation, si bien que les logs d'un conteneur bavard peuvent occuper beaucoup d'espace disque au fil du temps. La documentation de Docker sur la journalisation recommande plutôt le pilote local. Une fois Docker installé (étape 2 ci-dessous), créez le répertoire de configuration de Docker, définissez le pilote de journalisation local, puis redémarrez Docker : exécutez sudo install -d -m 0755 /etc/docker, puis printf '%s\n' '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json > /dev/null, puis sudo systemctl restart docker. Faites-le avant de déployer des applications destinées à tourner longtemps. Le pilote local effectue la rotation des logs par défaut, et le changement ne s'applique qu'aux conteneurs créés ensuite.

Voici ce que cela donne pour des charges de travail réelles :

La feuille de calcul est une simple addition : cherchez les besoins en RAM documentés de chaque application que vous prévoyez d'exécuter, ajoutez le système d'exploitation et le démon Docker, puis gardez une marge pour les pics d'utilisation. Portainer lui-même n'indique aucun minimum de RAM : ce sont donc les applications, et non l'interface, qui remplissent la machine.

Chez DreamHost, notre hébergement VPS se décline en quatre offres Stack basées sur la RAM (Stack 4, 8, 16 et 32). L'offre d'entrée de gamme Stack 4 (2 vCPU, 4 Go de RAM, 75 Go de SSD NVMe, accès root complet) convient naturellement à un petit hôte Docker. En facturation mensuelle, elle coûte 8,99 $/mois pendant les 3 premiers mois, puis se renouvelle automatiquement à 15,99 $/mois (tarifs d'août 2026 ; la totalité de la période plus les taxes est facturée lors du paiement, et les tarifs actuels figurent toujours sur la page VPS Docker + Portainer).

Si vous hésitez à savoir si l'auto-hébergement vaut le temps investi, Stack 4 est la taille idéale pour commencer : assez grande pour en avoir le cœur net, assez petite pour ne pas payer une marge que vous n'utiliserez pas. Si votre feuille de calcul la dépasse, vous pouvez passer à l'offre supérieure et votre environnement vous suit. Notez toutefois qu'il n'est actuellement pas possible de redescendre vers un Stack plus petit : commencez donc petit, en connaissance de cause.

Une remarque sur le stockage : le volume de données de Portainer contient sa propre base de données et sa configuration, ainsi qu'un clone de chaque dépôt Git à partir duquel vous déployez des stacks. La documentation de Portainer avertit que des dépôts volumineux ou multiples peuvent occuper beaucoup d'espace disque. Les recommandations de performance de la documentation portent sur le stockage, pas sur la mémoire : la documentation juge idéales des performances de niveau SSD (≈ 3,5 Mo/s, 30 000 IOPS ou plus, latence d'écriture inférieure à 10 ms). Stack 4 inclut 75 Go de stockage SSD NVMe.

Comment installer Docker et Portainer sur un VPS ?

Cela se fait en sept étapes. Le temps de téléchargement et d'installation dépend de votre VPS et de votre connexion réseau. Les commandes des étapes 2 à 6 sont écrites pour Ubuntu et peuvent être collées dans l'ordre sur un serveur vierge. Une seule commande nécessite une valeur que vous êtes le seul à connaître (votre propre adresse IP, à l'étape 4), et l'étape concernée le signale. (Envie de sauter toute la liste ? La bibliothèque d'applications de l'hébergement VPS DreamHost comprend une image Docker + Portainer avec les deux déjà configurés.)

1. Choisissez une distribution Linux

Ce guide utilise Ubuntu 24.04 LTS. Docker Engine prend en charge Ubuntu 22.04, 24.04 et 26.04 LTS (en août 2026). Ubuntu fait partie des systèmes d'exploitation préinstallés proposés avec l'hébergement VPS DreamHost.

Debian et les distributions de la famille RHEL comme AlmaLinux fonctionnent aussi, mais elles ont leurs propres procédures d'installation dans la documentation de Docker, et les commandes ci-dessous ne s'appliqueront pas telles quelles. Une subtilité de plus pour la famille RHEL : la documentation d'installation de Portainer suppose que SELinux est désactivé. Elle indique de passer --privileged à Docker lors du déploiement de Portainer si vous avez besoin que SELinux reste activé. Si cette phrase ne vous dit rien, utilisez Ubuntu.

Vous ne savez pas quelle version d'Ubuntu vous utilisez ? Découvrez cinq façons de la vérifier.

2. Installez Docker depuis le dépôt officiel

N'exécutez pas apt install docker.io, et n'installez pas non plus Docker via snap. La documentation d'installation officielle de Docker classe docker.io parmi les paquets non officiels à désinstaller avant d'installer Docker Engine, et la documentation d'installation de Portainer avertit que le paquet snap peut causer des problèmes de compatibilité.

Commencez par supprimer les éventuels paquets en conflit. Voici la commande de suppression tirée de la documentation d'installation actuelle de Docker. Sur un serveur vierge, elle ne trouve généralement rien à supprimer, et la documentation précise qu'apt peut vous signaler qu'aucun de ces paquets n'est installé :

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Ajoutez ensuite la clé GPG de Docker (chaque ligne ci-dessous est une commande distincte) :

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Puis ajoutez le dépôt apt de Docker. Cette commande écrit la définition du dépôt dans /etc/apt/sources.list.d/docker.sources, le fichier qu'utilise la documentation d'installation de Docker, en renseignant automatiquement votre version d'Ubuntu et l'architecture de votre processeur :

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

Enfin, installez Docker Engine et le plugin Compose en une seule fois :

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Vérifiez que Docker fonctionne

Exécutez sudo docker run hello-world.

Si vous n'obtenez pas le message Hello from Docker!, réparez le démon avant d'ajouter Portainer par-dessus.

4. Intégrez UFW à Docker avant de lancer Portainer

Voici la partie que la plupart des guides placent à la fin, quand il est trop tard. Lorsque Docker publie un port, le trafic vers celui-ci est détourné avant d'atteindre les chaînes filtrées par UFW, si bien qu'un port publié est accessible depuis l'internet public même quand UFW indique qu'il est bloqué. (L'explication complète se trouve plus bas.) Dès que vous démarrez Portainer, son port 9443 devient public, précisément pendant la fenêtre de cinq minutes où la première personne à l'atteindre peut créer le compte administrateur. Alors réglez le pare-feu d'abord.

Si UFW n'est pas déjà actif, autorisez SSH et activez-le. (Si votre SSH utilise un port personnalisé, autorisez ce port à la place du 22, sinon c'est à cette étape que vous vous enfermerez dehors.)

sudo ufw allow 22/tcp
sudo ufw enable

Installez ensuite chaifeng/ufw-docker, un outil tiers qui ajoute les règles nécessaires à /etc/ufw/after.rules pour que le trafic vers les ports publiés par Docker soit filtré par la chaîne DOCKER-USER. Les commandes ci-dessous fixent la version 251123 du projet (novembre 2025) au lieu de récupérer la branche master, qui évolue en permanence. Elles utilisent curl, que vous avez installé à l'étape 2 :

sudo curl -fsSL -o /usr/local/bin/ufw-docker \
  https://github.com/chaifeng/ufw-docker/raw/251123/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo ufw reload

Après le rechargement, les ports de conteneurs publiés sont filtrés par UFW. Si votre politique de trafic routé refuse les connexions entrantes et qu'aucune règle existante n'autorise le port, les connexions publiques restent bloquées jusqu'à ce que vous les autorisiez explicitement. (Le projet ufw-docker précise que si les règles ne prennent pas effet après un redémarrage d'UFW, un redémarrage du serveur règle le problème.)

Autorisez maintenant à l'avance votre propre accès à l'interface de Portainer. Remplacez YOUR_HOME_IP par l'adresse IP publique depuis laquelle vous naviguerez :

sudo ufw route allow proto tcp from YOUR_HOME_IP to any port 9443

Si cette règle est en place avant le démarrage de Portainer, le trafic IPv4 vers l'interface n'est autorisé que depuis votre IP, et aucune autre, y compris pendant la fenêtre de création de l'administrateur initial. Telle qu'elle est écrite, la règle ne couvre que l'IPv4. D'après la documentation de ufw-docker, l'outil prend aussi en charge les réseaux IPv6 et met à jour /etc/ufw/after6.rules si nécessaire, mais ne le croyez pas sur parole : si votre VPS répond sur une adresse IPv6 publique, refaites aussi en IPv6 le test depuis l'extérieur décrit dans la section sur le pare-feu avant de vous y fier. La contrepartie : la plupart des connexions domestiques changent d'IP de temps en temps, et vous devrez peut-être mettre à jour la règle plus tard. Si cela vous agace, la solution la plus propre à long terme consiste à placer un VPN devant l'interface (voir la section sur la sécurisation).

5. Créez un volume persistant pour les données de Portainer

Ensuite, exécutez sudo docker volume create portainer_data.

Stocker la base de données de Portainer sur un volume Docker (et non dans le conteneur) garantit qu'une mise à jour de Portainer n'effacera pas votre configuration.

6. Lancez Portainer Community Edition

Voici la commande tirée de la documentation d'installation Linux de Portainer, à une option près : la version officielle publie aussi le port 8000, un tunnel TCP nécessaire uniquement si vous connectez plus tard des environnements distants via des Edge Agents. Une installation sur un seul hôte n'en a pas besoin, nous l'omettons donc :

sudo docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Voyons cela ligne par ligne :

• -d l'exécute en mode détaché.
• -p 9443:9443 correspond à l'interface web de Portainer en HTTPS, le port que vous avez autorisé pour votre IP à l'étape 4.
• --restart=always relance Portainer après un redémarrage du serveur.
• Les options -v correspondent au montage du socket et au volume persistant de l'étape 5.
• :lts vous fixe sur la branche Long Term Support de Portainer, le tag qu'utilise la documentation d'installation de Portainer elle-même.

7. Ouvrez l'interface et créez votre compte administrateur

Dans votre navigateur, ouvrez https://YOUR_VPS_IP:9443 (depuis l'adresse IP autorisée à l'étape 4).

Passez l'avertissement concernant le certificat auto-signé. Vous arrivez sur l'écran create the initial administrator user. Choisissez un nom d'utilisateur autre que admin, définissez un mot de passe robuste et conservez-le en lieu sûr. Et… vous y êtes !

Pourquoi Portainer a-t-il expiré ?

Parce que, lors de la première installation, Portainer attend exactement cinq minutes que quelqu'un en prenne possession. Passé ce délai, il ferme la porte.

Mot pour mot, d'après la FAQ de Portainer :

As a security precaution, when Portainer is first installed it will wait for 5 minutes for an administrator user to be created (part of the initial setup). If a user is not created within those 5 minutes, the Portainer Server will stop listening for requests.

Traduction : si vous avez profité de l'étape 6 pour vous préparer un sandwich, votre installation refuse désormais de vous parler, et vous n'avez rien fait de mal.

La solution est simple. Exécutez sudo docker restart portainer.

Cela relance le conteneur, vous donne une nouvelle fenêtre de cinq minutes et vous amène sur l'écran de création de l'administrateur. Répétez autant que nécessaire. Bienvenue dans l'auto-hébergement.

Si vous scriptez l'installation pour tout un parc de serveurs (Ansible, Terraform, un pipeline de déploiement), Portainer accepte une option --admin-password-file qui crée l'utilisateur administrateur à partir d'un fichier au premier démarrage du conteneur. Plus besoin de course contre la montre sur l'écran de création. La documentation de configuration CLI de Portainer détaille la syntaxe. Pour une installation ponctuelle sur un VPS, l'astuce du redémarrage suffit.

Comment empêcher Docker de contourner votre pare-feu ?

C'est déjà fait, à l'étape 4. Voici ce qui s'est réellement passé, comment ouvrir des ports volontairement et comment vérifier que cela fonctionne.

Le problème : lorsque vous publiez le port d'un conteneur avec -p 80:80, ce port est accessible depuis l'internet public même si ufw status indique que le port 80 est refusé. Selon la documentation de Docker sur le filtrage des paquets : Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses.

UFW n'est pas en panne. Il monte simplement la garde dans le mauvais couloir.

La solution recommandée par Docker lui-même est la chaîne iptables DOCKER-USER, une chaîne que Docker crée spécialement pour les règles définies par l'utilisateur et qui est traitée avant les règles des chaînes propres à Docker. Le script ufw-docker installé à l'étape 4 relie UFW à cette chaîne en ajoutant un bloc de règles (entre les marqueurs # BEGIN UFW AND DOCKER et # END UFW AND DOCKER) à /etc/ufw/after.rules, afin qu'il soit chargé avec le reste de votre configuration UFW.

Pour ouvrir volontairement un port de conteneur au public, par exemple pour une application web sur le port 80 du conteneur, utilisez une règle de routage :

sudo ufw route allow proto tcp from any to any port 80

Un piège signalé par la documentation de ufw-docker : la règle prend le port du conteneur, pas celui de l'hôte. Si vous avez publié avec -p 8080:80, c'est bien la règle ci-dessus (port 80) qu'il faut utiliser, pas le port 8080.

Pour vérifier depuis l'extérieur, testez depuis un réseau absent de votre liste d'autorisation : un partage de connexion depuis votre téléphone fait l'affaire. La commande doit expirer au lieu de renvoyer la page de connexion de Portainer :

curl -k --max-time 5 https://YOUR_VPS_IP:9443

# For IPv6, enclose the address in square brackets:
curl -k --max-time 5 'https://[YOUR_VPS_IPV6]:9443'

Exécutez la même commande depuis l'IP autorisée à l'étape 4 : vous devriez recevoir du HTML. Qu'UFW affiche denied n'est qu'une affirmation. Un délai d'expiration depuis un réseau inconnu est une preuve.

Pour tout annuler, exécutez sudo ufw-docker uninstall, qui, selon la documentation du projet, restaure votre configuration UFW et supprime les fichiers installés par l'outil, puis sudo ufw reload. Vous pouvez aussi supprimer manuellement le bloc situé entre les marqueurs # BEGIN UFW AND DOCKER et # END UFW AND DOCKER dans /etc/ufw/after.rules, puis recharger UFW.

Ce piège surprend même des ingénieurs chevronnés, aussi bien sur des machines personnelles que sur des serveurs de production : UFW dit une chose, l'internet public en dit une autre, et la vérité se trouve dans iptables. Si vous préférez que Portainer n'ait aucun port public, placez-le derrière un tunnel VPN comme WireGuard.

Que sécuriser juste après la première connexion ?

Vous y êtes. Voici cinq choses à faire avant de fermer cet onglet. Les quatre premières viennent directement du guide de sécurité de Portainer :

• Activez Force HTTPS only. L'installation de ce guide ne publie que le port 9443 : aucun port HTTP n'est donc exposé au départ. Activer l'option Force HTTPS only dans Settings → SSL Certificate verrouille cet état. Selon la documentation des paramètres de Portainer, cette option désactive complètement l'écoute sur l'ancien port HTTP (9000). Un futur redéploiement qui ajouterait -p 9000:9000 ne pourra donc pas rouvrir un accès non chiffré.
• Remplacez le certificat auto-signé. Importez un certificat que vous avez généré, ou placez Portainer derrière un proxy inverse NGINX doté d'un certificat Let’s Encrypt. Passé le premier jour, cliquer à chaque fois pour ignorer l'avertissement du navigateur est une habitude que vous regretterez.
• Utilisez un vrai nom d'utilisateur administrateur. Avec le nom par défaut, admin, un attaquant a un identifiant de moins à deviner. Choisissez un nom qui vous est propre.
• Limitez l'accès à l'interface via un VPN. Faire tourner Portainer derrière un VPN WireGuard, c'est l'approche que recommande le guide de sécurité de Portainer. Un port 9443 restreint à votre IP source (étape 4), c'est bien. Un port 9443 accessible uniquement sur un réseau privé, c'est mieux.
• Auditez le montage du socket Docker. Tout ce qui a accès à /var/run/docker.sock contrôle le démon Docker et, à travers lui, l'hôte. Ne montez pas le socket à la légère dans d'autres conteneurs. Chaque montage supplémentaire ouvre un nouveau chemin vers l'hôte. Si un conteneur prétend avoir besoin du socket, demandez pourquoi, et envisagez un proxy de socket si la réponse est pour la supervision.

Comment utiliser Portainer au quotidien ?

Installer Portainer prend tout son sens le jour où, au lieu de vous connecter en SSH pour redémarrer un conteneur récalcitrant, vous cliquez simplement sur un bouton. Mais le vrai bénéfice, c'est la gestion des stacks.

Une stack Portainer est une application multi-conteneurs définie par un fichier Docker Compose. Portainer peut déployer des configurations Docker Compose compatibles sous forme de stacks de quatre manières, listées dans la documentation officielle sur les stacks :

• Coller le fichier Compose dans l'éditeur web
• Importer un fichier Compose
• Pointer Portainer vers un dépôt Git
• Déployer à partir d'un modèle personnalisé

C'est la méthode Git qui compte vraiment. Vous indiquez à Portainer un dépôt public ou authentifié et le chemin vers docker-compose.yml, puis vous activez les mises à jour GitOps. Portainer interroge alors le dépôt à l'intervalle que vous définissez, ou vous fournit une URL de webhook à ajouter à votre hébergeur Git (déclenchée depuis une GitHub Action, par exemple). Quand le fichier Compose change en amont, Portainer récupère les modifications et redéploie automatiquement. Et oui, cela fonctionne dans la Community Edition : sur la page de documentation des stacks, seule l'option des volumes à chemin relatif porte la mention Business Edition.

C'est la version auto-hébergée du déploiement à chaque push, sans payer un PaaS pour ce privilège.

Les petits gains du quotidien s'additionnent aussi : des logs consultables dans un panneau plutôt que suivis en ligne de commande, des redémarrages en un clic, la reconstruction d'une stack d'un simple bouton, et des graphiques de ressources lisibles en trois secondes au lieu de lancer Docker stats.

Si vous ajoutez plus tard des hôtes distants via des Edge Agents, le port 8000 redevient nécessaire. La FAQ ci-dessous explique le redéploiement et la règle de pare-feu.

Comment sauvegarder Portainer et vos conteneurs ?

Un volume assure la persistance, pas la sauvegarde. Le volume portainer_data de l'étape 5 survit aux mises à jour du conteneur, mais il réside sur le même disque que tout le reste. Un vrai plan de sauvegarde comporte donc trois volets, et tous trois sortent du VPS.

1. La configuration de Portainer. Dans l'interface, allez dans Settings → Back up Portainer, gardez l'option par défaut Download backup file et cliquez sur Download backup. Selon la documentation des paramètres de Portainer, cela télécharge une archive tar.gz de tout ce que Portainer stocke sur son volume /data, éventuellement chiffrée par mot de passe, et cette archive suffit pour restaurer Portainer. La documentation est tout aussi claire sur la portée : elle sauvegarde uniquement la configuration de Portainer, pas les conteneurs, stacks ou volumes que vous avez déployés. (Les sauvegardes planifiées vers S3 existent, mais uniquement dans la Business Edition. Avec la CE, ajoutez un rappel récurrent à votre agenda.)

2. Les données de vos applications. La documentation de Docker sur les volumes présente les volumes nommés comme la méthode privilégiée pour conserver les données des conteneurs, plus faciles à sauvegarder ou à migrer que les montages bind. Un montage en lecture seule empêche seulement le conteneur de sauvegarde d'écrire. L'application elle-même peut toujours écrire dans le volume pendant l'archivage et vous laisser une copie incohérente. Arrêtez donc d'abord le conteneur de l'application (sudo docker stop myapp), ou utilisez le mécanisme de sauvegarde pris en charge par l'application. Montez ensuite le volume en lecture seule dans un conteneur jetable, créez-en une archive tar, puis redémarrez l'application (remplacez par vos propres noms) :

sudo docker run --rm \
  -v myapp_data:/source:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/myapp_data.tgz -C /source .

Pour les bases de données, préférez l'outil de dump de la base (pg_dump, mysqldump) à la copie des fichiers de données actifs, afin de ne pas archiver un fichier en cours d'écriture. Ensuite, envoyez régulièrement les archives hors du serveur : rsync ou scp vers une autre machine, ou envoi vers un stockage objet. Une sauvegarde stockée sur le disque qu'elle sauvegarde disparaît avec ce disque.

3. Vos fichiers Compose et vos secrets. Si vous déployez vos stacks depuis Git, les fichiers Compose sont déjà hors de l'hôte. Ce que Git ne contient pas, c'est tout ce que vous n'avez jamais commité : fichiers .env, clés API et mots de passe fournis au moment du déploiement. Les répertoires montés en bind échappent aussi à la sauvegarde de volume ci-dessus. Recensez-les séparément et sauvegardez-les de façon chiffrée.

Testez ensuite la restauration, avant d'en avoir besoin. D'après la documentation de Portainer, une restauration de configuration ne fonctionne que sur une instance neuve. Déployez un nouveau conteneur Portainer avec un volume de données vide (un VPS jetable ou votre ordinateur portable fera l'affaire) et choisissez Restore Portainer from backup lors de la configuration initiale. Vérifiez ensuite que vous pouvez vous connecter avec vos anciens identifiants et voir les définitions de vos stacks. Cet exercice ne couvre que le volet 1, la configuration de Portainer. Les volets 2 et 3 nécessitent leur propre test, application par application : restaurez une archive dans un volume neuf, démarrez l'application dessus et vérifiez que les données sont bien là. Une sauvegarde non testée n'est qu'un espoir avec un nom de fichier.

Combien coûte Portainer ? (Et quand le gratuit cesse-t-il d'être gratuit ?)

Portainer est doublement gratuit. La Community Edition est gratuite et open source (licence zlib), sans clé de licence requise. Et la Business Edition de Portainer est gratuite à vie jusqu'à 3 nœuds : toutes les fonctionnalités Business, sans limite de durée ni carte bancaire. Au lieu de payer, vous vous inscrivez pour obtenir une clé de licence gratuite.

Prix issus de la page de tarifs de Portainer en août 2026 ; les offres Starter et Scale nécessitent un engagement annuel.

Alors, laquelle choisir ? Pour un seul VPS avec un seul administrateur, Community Edition : elle est open source, ne demande aucune inscription et fait tout ce que décrit ce guide, déploiements Git compris. Si vous voulez un contrôle d'accès basé sur les rôles (RBAC) pour un deuxième utilisateur, ou si vous gérez déjà deux ou trois machines, optez plutôt pour l'offre Business gratuite jusqu'à 3 nœuds. C'est le même logiciel, avec les fonctionnalités Business débloquées, et il reste gratuit tant que vous ne dépassez pas trois nœuds. Les offres payantes n'ont de sens que si vous gérez un vrai parc de nœuds en équipe. Vérifiez aussi le niveau de support avant de supposer que payant veut dire accompagné : en août 2026, la page de tarifs de Portainer indique un support communautaire pour l'offre Starter, un support 9×5 avec réponse le jour ouvré suivant à partir de l'offre Scale et un support prioritaire pour Enterprise.

Faut-il ajouter Portainer ou s'en passer ?

Voici la réponse honnête, en deux phrases :

✅ Si vous comptez partager ce serveur, déployer depuis Git ou faire tourner plus de trois conteneurs d'ici un an, installez Portainer tant que l'hôte est neuf et que vos habitudes sont encore en train de se former.

❌ Si vous faites tourner une seule application tranquille et que le terminal vous convient très bien, l'interface que vous n'avez pas installée ne vous manquera pas.

La vraie question n'est pas « Portainer ou pas de Portainer ». C'est de savoir si l'auto-hébergement vous convient tout court, et vous y avez répondu en ouvrant cet onglet.

Un VPS de 4 Go, Docker et Portainer CE suffisent pour vous lancer pour de bon dans l'auto-hébergement. Choisissez vos applications et additionnez leurs exigences documentées. Ensuite, laissez le calcul (et non votre liste d'envies) décider quand la machine doit grandir.

Plutôt une bonne affaire, non ?

Questions fréquentes sur Docker et Portainer