Installer Nextcloud avec Docker Compose sur Linux : le guide complet

Une installation Nextcloud Docker sur Linux tient en quatre conteneurs, orchestrés par Docker Compose : l’application, la base de données MariaDB, Redis pour le cache, et un conteneur cron dédié aux tâches planifiées. La méthode officiellement mise en avant par Nextcloud est All-in-One (AIO), mais elle impose son propre reverse proxy : si vous utilisez déjà Nginx Proxy Manager ou un autre reverse proxy, l’image Docker classique (nextcloud/docker) reste le bon choix. Ce guide couvre l’installation complète : reverse proxy, cache Redis, protection fail2ban avec la configuration officielle, sauvegarde et mise à jour.

L’essentiel

• Commande clé : docker compose up -d après avoir écrit le fichier compose.yaml
• Prérequis : Docker Engine et le plugin Compose installés, un nom de domaine pointé vers votre serveur, un reverse proxy pour le HTTPS
• Distributions couvertes : Debian, Ubuntu, Fedora/RHEL, Arch Linux, openSUSE (via l’installation de Docker — la suite est identique sur toutes)
• Vérifié le : 13 septembre 2026 · Nextcloud 34.0.4, image nextcloud:apache, mariadb:lts, redis:alpine
• Niveau de vérification : le compose.yaml, le filtre fail2ban, le bloc nginx, les blocs config.php et les trois commandes de sauvegarde ont été exécutés sur un banc de test. Les commandes occ et le démarrage de la pile sont conformes à la documentation officielle, sans exécution de notre côté. Le détail figure en fin d’article.

Prérequis

Comptez 30 à 45 minutes pour l’installation complète, reverse proxy et fail2ban inclus. Il vous faut :

• Un serveur Linux avec Docker Engine et le plugin Docker Compose installés — si ce n’est pas encore fait, la procédure complète par distribution (apt, dnf, pacman, zypper) est détaillée dans notre guide d’installation de Docker sur Linux ;
• Un nom de domaine ou sous-domaine pointé vers l’adresse IP de votre serveur (cloud.exemple.fr, par exemple) ;
• Un reverse proxy déjà en place pour gérer le certificat HTTPS. Ce guide part du principe que vous utilisez Nginx Proxy Manager, déjà couvert sur le site ;
• Au moins 2 Go de RAM disponibles et 20 Go d’espace disque pour un usage personnel — bien plus si vous comptez stocker des volumes de photos ou vidéos importants.

AIO ou micro-services : quelle méthode choisir

Nextcloud propose deux méthodes d’installation par conteneur, et les confondre est l’erreur la plus fréquente chez les débutants.

Nextcloud All-in-One (AIO) est, selon la documentation du projet, « la méthode d’installation officielle », gérée par Nextcloud GmbH elle-même. Elle déploie une pile complète (serveur, base de données, Redis, Collabora, sauvegardes intégrées) dans un jeu de conteneurs préconfigurés et optimisés. En contrepartie, AIO gère lui-même son reverse proxy et son certificat HTTPS : le placer derrière un reverse proxy tiers déjà existant désactive son HTTPS intégré, impose de configurer manuellement les variables APACHE_PORT et APACHE_IP_BINDING, et limite l’installation à un seul nom d’hôte dédié — pas de sous-dossier, pas de personnalisation du conteneur Apache.

L’image Docker classique (nextcloud/docker, celle utilisée dans ce guide) est décrite par ses propres mainteneurs comme « maintenue par des volontaires de la communauté et conçue pour un usage expert ». Elle demande d’assembler soi-même base de données, cache et reverse proxy, mais s’intègre nativement à une infrastructure Docker existante : le même hôte que vos autres conteneurs, le même réseau Docker, le même Nginx Proxy Manager.

Critère	AIO	Image classique (ce guide)
Reverse proxy existant (Nginx Proxy Manager, Traefik)	Compatible, mais avec pertes (HTTPS interne désactivé, un seul hôte)	Compatible nativement
Base de données	Imposée (PostgreSQL)	Choisie (MariaDB recommandée)
Complexité de départ	Faible	Moyenne
Personnalisation (thème, apps, config.php)	Limitée	Totale
Recommandé pour	Une première installation isolée	Un serveur qui héberge déjà d’autres services Docker

Si vous avez suivi nos guides Portainer, Vaultwarden ou Immich, votre serveur a déjà Docker, un réseau partagé et un reverse proxy configurés : l’image classique s’y intègre directement, quand AIO redemande sa propre pile.

Étape 1 : préparer l’arborescence et les volumes

Créez un dossier dédié et les volumes qui accueilleront les données. Un volume nommé pour Nextcloud et un pour la base de données suffisent pour démarrer ; vous pourrez affiner plus tard.

# Créer le dossier du projet
mkdir -p ~/docker/nextcloud
cd ~/docker/nextcloud

Le dossier /var/www/html du conteneur Nextcloud contient l’application, la configuration, les données et les applications installées. Pour pouvoir sauvegarder finement (voir plus bas) et pour que fail2ban puisse lire le journal des connexions depuis l’hôte, montez le sous-dossier data sur un chemin de l’hôte plutôt que de laisser Docker gérer un volume anonyme.

Étape 2 : écrire le fichier compose.yaml

Le fichier compose.yaml de cette installation Nextcloud Docker reprend la structure de l’exemple officiel du dépôt nextcloud/docker (services app, db, redis, cron), adaptée pour un déploiement derrière Nginx Proxy Manager plutôt que derrière le reverse proxy nginx-proxy utilisé dans l’exemple GitHub.

Avant d’écrire la configuration, voici comment ces conteneurs communiquent entre eux une fois la pile démarrée : le visiteur ne parle jamais directement à Nextcloud, seulement à Nginx Proxy Manager, qui relaie vers le conteneur app sur le réseau Docker interne.

# compose.yaml
services:
  db:
    image: mariadb:lts
    restart: always
    command: --transaction-isolation=READ-COMMITTED
    volumes:
      - db:/var/lib/mysql
    environment:
      - MARIADB_AUTO_UPGRADE=1
      - MARIADB_DISABLE_UPGRADE_BACKUP=1
      - MYSQL_ROOT_PASSWORD=changez_ce_mot_de_passe
      - MYSQL_PASSWORD=changez_ce_mot_de_passe_aussi
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  redis:
    image: redis:alpine
    restart: always

  app:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html
      - ./data:/var/www/html/data
    environment:
      - MYSQL_HOST=db
      - REDIS_HOST=redis
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.exemple.fr
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=changez_ce_mot_de_passe_admin
    depends_on:
      - db
      - redis
    networks:
      - default
      - proxy

  cron:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html
      - ./data:/var/www/html/data
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis

volumes:
  db:
  nextcloud:

networks:
  proxy:
    external: true
    name: nginx-proxy-manager_default

Remplacez changez_ce_mot_de_passe par un mot de passe robuste et unique, cloud.exemple.fr par votre domaine réel, et nginx-proxy-manager_default par le nom réel du réseau Docker de votre installation Nginx Proxy Manager — vérifiez-le avec docker network ls.

NEXTCLOUD_ADMIN_USER et NEXTCLOUD_ADMIN_PASSWORD sont ce qui déclenche réellement l’installation automatisée. C’est un point que beaucoup de tutoriels basés sur ce compose.yaml oublient : sans ces deux variables, le script de démarrage du conteneur ne configure ni la base de données ni le domaine de confiance tout seul, même si MYSQL_HOST et NEXTCLOUD_TRUSTED_DOMAINS sont bien définis plus bas — ces derniers ne sont exploités que si un compte administrateur est fourni en même temps. Sans NEXTCLOUD_ADMIN_USER/NEXTCLOUD_ADMIN_PASSWORD, l’assistant web s’ouvre en configuration manuelle et vous demande de ressaisir vous-même l’hôte, le nom, l’utilisateur et le mot de passe de la base (les mêmes valeurs que dans le service db). Remplacez changez_ce_mot_de_passe_admin par un mot de passe robuste : une fois l’installation terminée, changez-le depuis l’interface Nextcloud (Paramètres personnels) plutôt que de le laisser en clair dans compose.yaml — ou passez par un fichier .env non versionné, voire par les secrets Docker (NEXTCLOUD_ADMIN_PASSWORD_FILE, documentés dans le dépôt officiel) si plusieurs personnes ont accès au serveur.

Sur Fedora, RHEL et toute distribution avec SELinux en mode enforcing (le réglage par défaut sur ces systèmes), la documentation Docker réserve le suffixe SELinux :z/:Z aux montages de type bind mount — un chemin de l’hôte monté tel quel, comme votre dossier ./data — et non aux volumes nommés gérés par Docker (nextcloud, db dans ce compose.yaml), pour lesquels Docker gère lui-même le contexte SELinux de son espace de stockage interne. Ajoutez donc :z uniquement sur le bind mount partagé par les conteneurs app et cron : ./data:/var/www/html/data:z (le z minuscule signale un contenu partagé entre plusieurs conteneurs). Sans ce label, SELinux peut bloquer les écritures dans ./data avec des erreurs « Permission denied » même si les permissions Unix sont correctes. Sur Debian, Ubuntu, Arch et openSUSE (SELinux absent ou inactif par défaut), ce suffixe est ignoré par la plateforme et peut être omis sans risque.

Pourquoi un conteneur cron séparé. Nextcloud exécute des tâches de fond (notifications, nettoyage, indexation) qui doivent tourner régulièrement. C’est le conteneur cron, avec son propre entrypoint /cron.sh, qui s’en charge — pas une tâche cron sur l’hôte, qui n’aurait pas accès à l’environnement PHP du conteneur.

Pourquoi mariadb:lts et pas un numéro de version figé. L’exemple officiel du dépôt nextcloud/docker recommande explicitement le tag lts, qui suit la dernière version de support long terme de MariaDB, plutôt qu’un numéro de version que vous devriez mettre à jour manuellement. Pour l’image Nextcloud elle-même, en revanche, figez une version précise (nextcloud:34-apache plutôt que nextcloud:apache ou nextcloud:latest) une fois l’installation stabilisée, pour ne jamais subir une mise à jour majeure sans l’avoir décidée — voir la section mise à jour plus bas.

Le tag lts évolue avec le temps : au moment de votre installation, il peut pointer vers une version de MariaDB plus récente que celle testée par l’équipe Nextcloud pour la version de Nextcloud que vous installez. Vérifiez la version de base de données recommandée dans la documentation officielle avant de démarrer, et si vous constatez une incompatibilité après une mise à jour de mariadb:lts (erreur SQL inhabituelle après un docker compose pull), figez temporairement une version de MariaDB explicite le temps que Nextcloud rattrape la compatibilité.

Démarrez ensuite la pile :

docker compose up -d

Vérifiez que les quatre conteneurs tournent :

docker compose ps
# Sortie attendue : app, db, redis et cron avec le statut "Up"

Étape 3 : vérifier l’installation automatisée

Grâce à NEXTCLOUD_ADMIN_USER et NEXTCLOUD_ADMIN_PASSWORD définis à l’étape précédente, Nextcloud s’installe entièrement seul au premier démarrage : pas d’assistant web à remplir. Une fois le domaine branché derrière Nginx Proxy Manager (étape suivante), ouvrez https://cloud.exemple.fr et connectez-vous directement avec le compte admin et le mot de passe défini dans compose.yaml.

Pour confirmer que l’installation automatisée s’est bien déroulée avant même d’avoir branché le reverse proxy, vérifiez l’état directement dans le conteneur :

docker compose exec -u33 app ./occ status
# Sortie attendue : installed: true

Si installed répond false, ou si l’assistant web classique s’affiche au lieu de la page de connexion, NEXTCLOUD_ADMIN_USER/NEXTCLOUD_ADMIN_PASSWORD n’ont pas été pris en compte (variable mal orthographiée, ou conteneur démarré avant leur ajout au fichier) — consultez docker compose logs app pour identifier l’erreur, et repartez au besoin d’un volume vide (docker compose down, puis docker volume rm sur le volume nextcloud, avant de relancer docker compose up -d).

Étape 4 : brancher Nextcloud derrière Nginx Proxy Manager

Dans l’interface de Nginx Proxy Manager, ajoutez un nouveau « Proxy Host » : nom d’hôte cloud.exemple.fr, adresse de destination app (le nom du service Docker, puisque les deux conteneurs partagent maintenant le même réseau), port 80. Activez le certificat Let’s Encrypt et le forçage SSL dans l’onglet dédié. Pour l’onglet « Advanced », ajoutez la configuration suivante, nécessaire au bon fonctionnement des applications de synchronisation et de la découverte automatique de service :

client_max_body_size 10G;
proxy_hide_header Upgrade;

location /.well-known/carddav {
  return 301 $scheme://$host/remote.php/dav;
}
location /.well-known/caldav {
  return 301 $scheme://$host/remote.php/dav;
}

client_max_body_size conditionne la taille maximale d’un fichier envoyé via l’interface web ou WebDAV. Nextcloud lui-même limite la taille d’upload PHP côté conteneur (PHP_UPLOAD_LIMIT) : les deux valeurs doivent être cohérentes.

proxy_hide_header Upgrade n’est pas optionnel. La documentation officielle de Nextcloud le précise nommément pour Nginx Proxy Manager : sans cette ligne dans l’onglet Advanced, les clients mobiles (iPad, iPhone) reçoivent une erreur « Connection Closed » à la connexion, alors que l’accès web classique fonctionne normalement. C’est un réglage propre à NPM que la plupart des tutoriels généralistes sur Nextcloud, écrits pour Nginx ou Traefik, ne mentionnent pas.

Étape 5 : configurer trusted_proxies et le domaine de confiance

Avertissement — sans cette étape, Nextcloud voit toutes les requêtes comme provenant de l’adresse IP interne de Nginx Proxy Manager, pas de vos visiteurs réels. Deux conséquences concrètes : les journaux de connexion sont inutilisables (toutes les tentatives, légitimes ou non, semblent venir de la même IP), et fail2ban, configuré plus bas, finit par bannir votre propre reverse proxy plutôt que l’attaquant.

Éditez config/config.php (accessible via le volume nextcloud:/var/www/html/config, ou directement avec docker compose exec -u33 app ./occ config:system:set pour chaque valeur) pour ajouter :

'trusted_proxies' => ['<adresse IP du conteneur ou réseau de Nginx Proxy Manager>'],
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://cloud.exemple.fr',

Trouvez l’adresse IP interne du conteneur Nginx Proxy Manager sur le réseau partagé avec docker network inspect nginx-proxy-manager_default, ou indiquez directement la plage du réseau Docker (par exemple 172.18.0.0/16) si elle est stable. Sans ces réglages, trusted_proxies reste vide et Nextcloud fait de la détection automatique, ce qui échoue silencieusement derrière un reverse proxy.

Sur overwritehost : ne l’ajoutez pas par défaut. La documentation officielle est explicite sur ce point : dans une configuration à un seul domaine, Nextcloud lit correctement le nom d’hôte depuis l’en-tête transmis par le reverse proxy, et overwritehost n’est pas nécessaire. Ne l’ajoutez que si vous constatez que l’auto-détection échoue (redirections vers la mauvaise URL, liens de partage incorrects) ou si vous exposez la même instance sous plusieurs domaines et devez forcer un nom d’hôte particulier.

Vérifiez la configuration réellement appliquée — et pas seulement le contenu du fichier, puisque l’image ajoute ses propres réglages automatiques par-dessus :

docker compose exec -u33 app ./occ config:list system

Étape 6 : activer Redis pour le cache et les verrous

Pour un serveur personnel unique (le cas visé par ce guide), la documentation officielle recommande APCu pour le cache local et Redis pour le cache distribué et le verrouillage des fichiers. Ajoutez dans config.php :

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'redis',
    'port' => 6379,
],

host vaut redis — le nom du service défini dans compose.yaml — et non localhost, puisque Redis tourne dans un conteneur séparé sur le même réseau Docker. Sans verrouillage de fichiers actif, deux processus qui modifient le même fichier en même temps (synchronisation desktop et upload web, par exemple) peuvent le corrompre : ce réglage n’est pas un simple gain de performance.

Ce bloc config.php est distinct de la variable REDIS_HOST=redis déjà présente dans compose.yaml : celle-ci configure uniquement le stockage des sessions PHP dans Redis, pas le cache ni le verrouillage des fichiers. Les deux réglages sont complémentaires, pas redondants — l’un ne remplace pas l’autre.

Vérifier que tout fonctionne

• docker compose exec -u33 app ./occ status doit répondre installed: true, avec le numéro de version installé.
• Dans l’interface d’administration (Paramètres > Administration > Aperçu), aucun avertissement sur le cache ou les tâches planifiées ne doit apparaître.
• docker compose exec -u33 app ./occ config:list system doit afficher les valeurs trusted_proxies et overwriteprotocol que vous venez de définir.

Sécuriser l’accès avec fail2ban (configuration officielle)

Avertissement — fail2ban agit au niveau du pare-feu de l’hôte (iptables). Une règle mal ciblée peut bloquer votre propre accès ou celui de votre reverse proxy. Testez toujours avec un bantime court avant de passer à la valeur définitive, et gardez un accès console (SSH direct, ou console du fournisseur) qui ne dépend pas du service que vous protégez.

Deux prérequis, documentés par Nextcloud lui-même et souvent oubliés dans les tutoriels : l’étape 5 (trusted_proxies) doit être en place pour que les adresses IP journalisées soient les vraies adresses des visiteurs, et le niveau de journalisation doit être suffisant. Ajoutez dans config.php :

'loglevel' => 2,

Nextcloud journalise alors les échecs de connexion dans nextcloud.log, à l’intérieur du dossier data — celui que vous avez monté sur l’hôte à l’étape 1 (./data). C’est ce chemin hôte qu’utilisera fail2ban, qui tourne lui-même sur l’hôte et non dans un conteneur, puisqu’il doit manipuler le pare-feu du système.

Installez fail2ban selon votre distribution :

# Debian / Ubuntu
sudo apt install fail2ban

# Fedora / RHEL
sudo dnf install fail2ban

# Arch Linux
sudo pacman -S fail2ban

# openSUSE
sudo zypper install fail2ban

Créez le filtre officiel Nextcloud dans /etc/fail2ban/filter.d/nextcloud.conf :

[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
            ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Two-factor challenge failed:
            ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"

Puis la prison associée dans /etc/fail2ban/jail.d/nextcloud.local :

[nextcloud]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = nextcloud
maxretry = 3
bantime = 86400
findtime = 43200
logpath = /home/<votre_utilisateur>/docker/nextcloud/data/nextcloud.log

Remplacez logpath par le chemin absolu réel de votre dossier data sur l’hôte. bantime et findtime sont en secondes : 86400 secondes (24 heures) de bannissement pour 3 échecs en 43200 secondes (12 heures). Redémarrez le service et vérifiez la prison :

sudo systemctl restart fail2ban
sudo fail2ban-client status nextcloud

Ce filtre a été passé dans fail2ban-regex avant publication : sur des lignes de journal reconstruites à partir de l’exemple officiel de la documentation Nextcloud, les trois motifs se déclenchent bien, en IPv4 comme en IPv6, et une connexion réussie n’est pas capturée — pas de bannissement d’utilisateur légitime. La prison ci-dessus passe également fail2ban-client -t.

Ce filtre couvre trois cas distincts, dans l’ordre où ils apparaissent dans la documentation officielle : l’échec de mot de passe classique, l’échec de la double authentification, et une tentative d’accès via un nom de domaine non déclaré dans trusted_domains — ce dernier cas est spécifique à Nextcloud et absent des filtres fail2ban génériques que certains tutoriels recopient pour d’autres applications web.

Notre guide de configuration de fail2ban sous Linux détaille la logique générale du service et sa protection d’autres services conteneurisés, si vous voulez étendre cette protection au-delà de Nextcloud.

Sauvegarder et restaurer Nextcloud

La documentation officielle identifie cinq éléments à sauvegarder : le dossier config, le dossier custom_apps (si vous avez installé des applications tierces), le dossier data, le dossier theme (si personnalisé), et la base de données. Dans cette installation, data correspond au bind mount ./data ; config, custom_apps et theme vivent, eux, à l’intérieur du volume Docker nommé nextcloud — un point que plusieurs guides omettent, alors que ce volume contient aussi votre configuration trusted_proxies et Redis : l’oublier revient à perdre toute votre configuration en cas de restauration.

Avant toute sauvegarde à chaud, activez le mode maintenance pour éviter les écritures concurrentes :

docker compose exec -u33 app ./occ maintenance:mode --on

Sauvegardez la base de données avec mariadb-dump, en précisant la transaction isolée pour ne pas verrouiller les tables en cours de dump. Utilisez -T pour désactiver l’allocation d’un pseudo-terminal — sans quoi la sortie redirigée vers un fichier peut voir ses fins de ligne altérées — et transmettez le mot de passe par la variable MYSQL_PWD plutôt que par -p, pour que la commande s’exécute sans invite interactive :

docker compose exec -T -e MYSQL_PWD='changez_ce_mot_de_passe_aussi' db \
  mariadb-dump --single-transaction -u nextcloud nextcloud > nextcloud-sqlbkp_$(date +%Y%m%d).bak

Remplacez changez_ce_mot_de_passe_aussi par la valeur réelle de MYSQL_PASSWORD. Le fichier .bak est créé dans le répertoire courant de votre hôte, pas dans le conteneur : la redirection > s’applique à la sortie de docker compose exec sur votre machine. MYSQL_PWD évite l’invite interactive, mais la documentation MariaDB rappelle que transmettre un mot de passe par variable d’environnement reste moins sûr qu’un fichier d’identifiants dédié (~/.my.cnf, droits 600) : sur un serveur multi-utilisateurs, préférez cette dernière méthode.

Sauvegardez ensuite le contenu applicatif (config, custom_apps, theme) du volume nextcloud, en passant par le conteneur app déjà en cours d’exécution :

docker compose exec -T -u33 app tar czf - -C /var/www/html config custom_apps themes > nextcloud-appdata_$(date +%Y%m%d).tar.gz

Cette commande suppose que tar est disponible dans l’image nextcloud:apache (c’est le cas de l’image officielle au moment de la rédaction, basée sur Debian) — vérifiez-le au préalable avec docker compose exec -u33 app which tar, et signalez-le-nous si ce n’est plus vrai sur une image future.

Les deux commandes ci-dessus ont été exécutées avant publication, sans leur préfixe docker compose exec : le dump SQL a été restauré avec succès dans une base vide, et l’archive tar réextraite est identique à l’originale. Détail de la méthode en fin d’article.

Sauvegardez enfin les fichiers utilisateurs, avec rsync pour ne recopier que ce qui a changé d’une sauvegarde à l’autre — notre guide sur l’automatisation des sauvegardes Linux avec rsync et crontab détaille la mise en place d’une rotation complète :

rsync -Aavx ~/docker/nextcloud/data/ ~/backups/nextcloud-data_$(date +%Y%m%d)/

-x empêche rsync de franchir un point de montage : si votre dossier data contient lui-même un disque ou un point de montage séparé (stockage dédié aux photos, par exemple), retirez ce drapeau pour ne rien oublier.

Désactivez enfin le mode maintenance :

docker compose exec -u33 app ./occ maintenance:mode --off

Pour restaurer : recréez la pile avec des volumes vides, réimportez le dump SQL dans le conteneur db, extrayez l’archive nextcloud-appdata dans le volume nextcloud, puis restaurez le dossier data avant de redémarrer — testez systématiquement une restauration sur un environnement séparé avant d’en avoir besoin en urgence. Si votre serveur héberge déjà Proxmox Backup Server ou une sauvegarde programmée de VM/LXC, sauvegarder l’hôte entier couvre aussi les volumes Docker : les deux approches sont complémentaires, pas concurrentes.

Mettre à jour Nextcloud

Nextcloud n’autorise qu’une mise à jour majeure à la fois : passer de la version 32 à la 34 exige de transiter par la 33, jamais un saut direct. Le script de démarrage du conteneur détecte l’écart de version au démarrage et déclenche automatiquement la migration si les volumes sont conservés.

# Modifier le tag d'image dans compose.yaml (ex : nextcloud:34-apache)
docker compose pull
docker compose up -d

Comptez un temps d’indisponibilité de quelques minutes le temps que le conteneur applique les migrations de base de données. Sauvegardez systématiquement avant une mise à jour majeure, avec la procédure ci-dessus.

Nextcloud ou OwnCloud : faut-il chercher ailleurs ?

Nextcloud et OwnCloud partagent une origine commune, mais ont divergé depuis plusieurs années. Nextcloud propose un App Store plus fourni (Talk, Office intégré via Collabora ou OnlyOffice, gestion de projet) ; OwnCloud (désormais recentré sur sa version « Infinite Scale », ou oCIS) cible davantage les déploiements d’entreprise à grande échelle : son éditeur la présente comme une architecture cloud-native en microservices, pensée pour unifier plusieurs sources de stockage à grande échelle plutôt que pour un serveur personnel unique. Pour un usage personnel ou familial auto-hébergé sous Linux — l’audience de ce guide —, c’est cette différence d’échelle qui tranche en faveur de Nextcloud et de l’image nextcloud/docker : elle s’intègre directement à une pile Docker existante (Nginx Proxy Manager, MariaDB, Redis), sans l’infrastructure de stockage objet qu’Infinite Scale suppose.

Désinstaller Nextcloud

Avertissement — docker volume rm supprime définitivement le contenu des volumes ciblés : votre base de données et toute la configuration applicative (config, custom_apps, theme). Il n’y a pas de corbeille ni de confirmation supplémentaire. Faites une sauvegarde récente (section précédente) avant de continuer si vous n’êtes pas certain de vouloir tout effacer.

Pour revenir en arrière proprement, arrêtez la pile et supprimez les volumes nommés. Vérifiez d’abord leur nom exact : Docker Compose préfixe chaque volume nommé avec le nom du projet, dérivé par défaut du nom du dossier (nextcloud dans ce guide), mais ce préfixe change si vous avez renommé le dossier ou défini COMPOSE_PROJECT_NAME.

docker volume ls | grep nextcloud
# Confirmez que les noms affichés correspondent bien à ceux utilisés ci-dessous

docker compose down
docker volume rm nextcloud_db nextcloud_nextcloud

Le dossier ./data monté sur l’hôte n’est pas supprimé par ces commandes : effacez-le manuellement si vous ne comptez pas le conserver.

Erreurs courantes

« Access through untrusted domain » apparaît quand le domaine utilisé pour accéder à Nextcloud n’est pas listé dans trusted_domains. Ajoutez-le avec docker compose exec -u33 app ./occ config:system:set trusted_domains 1 --value=cloud.exemple.fr.

Erreur 502 via le reverse proxy signale le plus souvent que Nginx Proxy Manager pointe vers le mauvais port ou que les deux conteneurs ne partagent pas le même réseau Docker — vérifiez le nom du réseau déclaré dans compose.yaml avec docker network ls.

« Connection refused » côté Redis dans les journaux Nextcloud indique généralement un host resté à localhost dans config.php au lieu du nom du service (redis), ou un conteneur Redis non démarré (docker compose ps pour vérifier).

FAQ

Nextcloud Talk fonctionne-t-il avec cette installation Docker ? Oui, mais la visioconférence a besoin d’un serveur TURN pour fonctionner correctement derrière la plupart des connexions internet domestiques (NAT). L’application Talk elle-même s’installe depuis le App Store de Nextcloud une fois le serveur en ligne ; la configuration du serveur TURN est un sujet à part qui dépasse ce guide d’installation.

Faut-il OnlyOffice ou Collabora pour l’édition de documents ? Aucun des deux n’est inclus par défaut dans l’image Docker classique. Les deux s’installent comme des conteneurs séparés, connectés à Nextcloud via l’application correspondante dans le App Store. OnlyOffice comme Collabora demandent des ressources supplémentaires notables (plusieurs centaines de Mo de RAM au repos).

Peut-on installer Nextcloud sur un Raspberry Pi avec l’image Docker classique ? Oui, à condition d’utiliser un Raspberry Pi 4 ou plus récent avec au moins 4 Go de RAM et un stockage sur SSD externe plutôt que sur carte SD, dont les performances d’écriture aléatoire limitent fortement la réactivité de Nextcloud.

Nextcloud peut-il remplacer complètement Google Drive ? Pour le stockage et la synchronisation de fichiers, oui : les clients desktop et mobiles couvrent les mêmes usages. Pour les fonctions annexes de l’écosystème Google (édition collaborative en temps réel avancée, Google Meet), les applications complémentaires (OnlyOffice, Talk) apportent des équivalents fonctionnels mais pas identiques trait pour trait.

Nextcloud est-il gratuit une fois auto-hébergé ? Le logiciel serveur est open source et gratuit. Le coût réel est celui de votre infrastructure : serveur, stockage, et le temps passé à l’administrer — ce que ce guide cherche justement à réduire.

Conclusion

Cette installation Nextcloud Docker, assemblée avec MariaDB, Redis et un conteneur cron dédié, s’intègre directement à une infrastructure qui utilise déjà Nginx Proxy Manager, sans les concessions qu’impose All-in-One sur le reverse proxy. Configurez trusted_proxies (étape 5) avant d’activer fail2ban : dans l’ordre inverse, vous bannirez votre propre reverse proxy plutôt que les tentatives de connexion malveillantes. Une fois ces deux points réglés, l’essentiel de la maintenance se résume à sauvegarder avant chaque mise à jour majeure et à ne jamais sauter une version intermédiaire. Pour la suite de votre pile self-hosting, Nginx Proxy Manager et Tailscale couvrent respectivement l’exposition sécurisée et l’accès distant sans ouvrir de port sur votre box.

Comment ces commandes ont été vérifiées

Un tutoriel qui affirme « commandes testées » sans dire lesquelles ne vous apprend rien. Voici donc le détail, élément par élément, de ce qui a réellement tourné sur notre banc de test et de ce qui repose uniquement sur la documentation officielle.

Élément	Niveau	Vérification
compose.yaml (étape 2)	Testé	docker compose config : les quatre services, les deux volumes nommés et le réseau externe sont résolus sans erreur
Filtre fail2ban nextcloud.conf	Testé	fail2ban-regex sur des lignes reconstruites depuis l’exemple de journal officiel : les trois motifs se déclenchent, en IPv4 et IPv6 ; une connexion réussie n’est pas capturée
Prison fail2ban nextcloud.local	Testé	fail2ban-client -t : configuration acceptée, maxretry, findtime et bantime relus aux valeurs attendues
Bloc « Advanced » nginx (étape 4)	Testé	nginx -t : syntaxe acceptée à l’intérieur d’un bloc server
Blocs config.php (étapes 5 et 6)	Testé	php -l, puis relecture des valeurs : les antislashs de \OC\Memcache\Redis et les entiers 6379 et 2 sont préservés
Sauvegarde mariadb-dump	Testé	Dump réel d’une base MariaDB, puis restauration complète dans une base vide. Sans MYSQL_PWD, la même commande échoue en « Access denied » : le mot de passe vient bien de la variable
Sauvegarde tar du volume applicatif	Testé	Archive créée puis réextraite : config, custom_apps et themes sont identiques à l’original
Sauvegarde rsync	Testé	Copie vérifiée identique à la source
docker compose up -d, docker compose ps	Conforme à la doc	Non exécuté : les registres d’images étaient inaccessibles depuis le banc de test
Commandes occ (status, config:list, config:system:set, maintenance:mode)	Conforme à la doc	Non exécutées, même raison. La syntaxe docker compose exec -u33 app ./occ est celle du README officiel de nextcloud/docker
Installation automatisée par NEXTCLOUD_ADMIN_USER	Conforme à la doc	Comportement lu dans le docker-entrypoint.sh officiel, pas observé en fonctionnement
Présence de tar dans l’image nextcloud:apache	Variable	À confirmer avec docker compose exec -u33 app which tar avant de compter sur la sauvegarde applicative

Banc de test : Ubuntu 24.04, Docker Compose v5.1.3, fail2ban 1.0.2, nginx 1.24.0, MariaDB 10.11.14, PHP 8.4, GNU tar 1.35, rsync 3.2.7, le 13 septembre 2026. Les trois commandes de sauvegarde ont été exécutées sans leur préfixe docker compose exec : c’est la commande interne qui a été testée, pas le passage par le conteneur. Le comportement de -T (désactivation du pseudo-terminal) et de -e reste, lui, conforme à la référence Docker Compose citée en sources.

Sources officielles

• nextcloud/docker — dépôt GitHub officiel
• nextcloud/all-in-one — dépôt GitHub officiel
• Reverse proxy configuration — Nextcloud 34 Administration Manual
• Memory caching — Nextcloud 34 Administration Manual
• Hardening and security guidance (fail2ban) — Nextcloud 34 Administration Manual
• Backup — Nextcloud 34 Administration Manual
• Nextcloud changelog officiel
• Bind mounts — Configure the SELinux label — Docker Docs
• docker compose exec — Docker Docs
• MariaDB Environment Variables (MYSQL_PWD) — MariaDB Documentation