Nextcloud Docker Compose : déployer un cloud privé avec Nginx, Ansible et Restic

Nextcloud Docker Compose permet de déployer un cloud privé complet en quelques minutes. Avec l’image All-in-One, vous obtenez Nextcloud, Collabora, Talk et un système de backup intégré dans un seul conteneur maître. Ce guide couvre l’installation, la configuration Nginx, les certificats SSL et les sauvegardes automatiques.

J’héberge mon instance Nextcloud en production sur un VPS Linux depuis plus d’un an. Au fil des itérations, j’ai construit une stack reproductible que je déploie avec Ansible et que je livre via GitLab CI. Si vous cherchez un guide pratique pour automatiser le déploiement d’une application Docker avec Ansible, vous êtes au bon endroit.

Pourquoi Nextcloud All-in-One plutôt qu’une installation classique

L’image Docker classique de Nextcloud demande de configurer séparément la base de données, Redis, le cron, Collabora et le stockage objet. Nextcloud AIO (All-in-One) simplifie tout ça en orchestrant automatiquement les conteneurs nécessaires à partir d’un seul mastercontainer.

Concrètement, AIO gère pour vous :

• PostgreSQL comme base de données (plus performant que MySQL pour Nextcloud)
• Redis pour le cache et le file locking
• Collabora Online pour l’édition de documents
• Nextcloud Talk pour la visioconférence
• Imaginary pour la génération de miniatures
• BorgBackup intégré pour les sauvegardes

Le compromis : AIO contrôle le cycle de vie des conteneurs via le socket Docker. Ça veut dire qu’il a un accès privilégié – un point à prendre en compte pour la sécurité.

Prérequis : serveur, DNS et Docker

Avant de lancer le Docker Compose, vous avez besoin de :

• Un VPS Linux (Debian 12/13 ou Ubuntu 22.04+) avec minimum 2 vCPU et 4 Go de RAM
• Docker Engine et Docker Compose v2 installés
• Un nom de domaine avec un enregistrement A pointant vers l’IP du serveur
• Les ports 80 et 443 ouverts dans le firewall

# Installer Docker sur Debian 13
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

# Vérifier l'installation
docker --version
docker compose version

Le fichier Docker Compose détaillé

Voici le docker-compose.yml que j’utilise en production. Le mastercontainer écoute sur 127.0.0.1:8080 pour l’interface d’administration, et Nextcloud lui-même est exposé sur le port 11000 en local – c’est Nginx qui se charge du SSL et du routage public.

services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 127.0.0.1:8080:8080
    environment:
      - DAILY_BACKUP=1
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=127.0.0.1
      - SKIP_DOMAIN_VALIDATION=true
      - NEXTCLOUD_UPLOAD_LIMIT=10G
      - NEXTCLOUD_MAX_TIME=3600
      - NEXTCLOUD_MEMORY_LIMIT=512M
      - NEXTCLOUD_ADDITIONAL_PHP_EXTENSIONS=imagemagick ghostscript
      - NEXTCLOUD_ADDITIONAL_APKS=imagemagick ghostscript

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

Points clés de cette configuration :

• APACHE_PORT=11000 – Nextcloud écoute sur ce port en local, Nginx fait le proxy
• APACHE_IP_BINDING=127.0.0.1 – Empêche l’accès direct sans passer par le reverse proxy
• SKIP_DOMAIN_VALIDATION=true – Nécessaire quand on gère le SSL côté Nginx
• DAILY_BACKUP=1 – Active les sauvegardes BorgBackup quotidiennes intégrées

Nginx en reverse proxy avec SSL

Je gère le SSL avec Let’s Encrypt via Certbot, et Nginx fait office de reverse proxy devant le conteneur Nextcloud. La configuration que j’utilise en production supporte HTTP/2, les WebSockets (indispensables pour Talk et la collaboration en temps réel) et un upload illimité côté Nginx.

# /etc/nginx/sites-available/nextcloud.conf

# Redirection HTTP → HTTPS
server {
    listen 80;
    server_name cloud.example.com;
    return 301 https://$host$request_uri;
}

# Configuration HTTPS
server {
    listen 443 ssl http2;
    server_name cloud.example.com;

    ssl_certificate     /etc/ssl/certs/cert.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 1d;
    ssl_session_cache   shared:MozSSL:10m;
    ssl_session_tickets off;

    location / {
        proxy_pass http://127.0.0.1:11000$request_uri;

        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Port  $server_port;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header Host              $host;

        # Upload illimité côté Nginx
        client_max_body_size 0;
        client_body_buffer_size 512k;
        proxy_read_timeout 86400s;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Les headers X-Forwarded-* sont indispensables pour que Nextcloud détecte correctement le protocole HTTPS et l’IP réelle des utilisateurs. Sans eux, vous aurez des avertissements de sécurité dans l’interface d’administration.

Automatiser le déploiement avec Ansible

Je ne déploie jamais à la main. J’ai conçu un playbook Ansible qui orchestre toute la stack : Certbot pour les certificats, gestion du SSL, Docker, le Docker Compose, Nginx et les sauvegardes Restic. Un seul ansible-playbook et tout est en place.

Voici la structure du playbook :

---
- name: Deploy Nextcloud
  hosts: prod
  become: true
  vars:
    domain_name: "cloud.example.com"
    certbot_create_if_missing: true
    certbot_certs:
      - email: contact@linux-man.fr
        domains:
          - "{{ domain_name }}"
    docker_install_compose: true
    deploy_docker_compose_directory: /opt/my_nextcloud

  roles:
    - certbot
    - manage-ssl-certs
    - docker
    - deploy-docker-compose
    - nginx
    - restic
    - restic-exporter

Chaque rôle est idempotent – je peux relancer le playbook autant de fois que nécessaire sans casser l’installation existante. C’est la base d’une infrastructure maintenable. Si le sujet de la structuration d’un playbook Ansible pour la production vous intéresse, j’ai écrit un guide dédié.

Sauvegardes automatiques avec Restic

AIO intègre BorgBackup, mais je lui préfère Restic pour plusieurs raisons : il supporte nativement le stockage objet (S3, Backblaze B2), il est plus simple à restaurer et je l’utilise déjà sur toute mon infrastructure.

Ma configuration Restic sauvegarde le répertoire /mnt/nextcloud-backup/ qui contient l’export AIO complet :

# Variables Ansible pour Restic
restic_repository: "s3:s3.eu-west-003.backblazeb2.com/lm-nextcloud-backup"
restic_aws_access_key_id: "{{ vault_b2_access_key }}"
restic_aws_secret_access_key: "{{ vault_b2_secret_key }}"
restic_folders:
  - { path: "/mnt/nextcloud-backup/" }
restic_ssh_enabled: false

J’expose aussi un Restic Exporter sur le port 9443 (en HTTPS, filtré par IP) pour surveiller l’état des sauvegardes dans Grafana. Si un backup échoue, je suis alerté dans la minute.

# Procédure de restauration
restic restore latest --target /
# L'arborescence /mnt/nextcloud-backup/ est recréée automatiquement

# Puis dans l'interface AIO (https://localhost:8080) :
# → "Restore" → sélectionner le chemin /mnt/nextcloud-backup/

Pipeline GitLab CI pour le déploiement continu

Chaque modification du docker-compose.yml ou du playbook déclenche un déploiement automatique via GitLab CI. Le pipeline est simple et efficace :

stages:
  - deploy

variables:
  ANSIBLE_HOST_KEY_CHECKING: "False"

deploy:
  stage: deploy
  image: registry.gitlab.com/babidi34/ansible:alpine3.18
  before_script:
    - mkdir /root/.ssh
    - echo "$SSH_PRIVKEY_GITLAB_CI" | tr -d '\r' > /root/.ssh/private_key
    - chmod 600 /root/.ssh/private_key
    - ansible-galaxy install -r requirements.yml
  script:
    - ansible-playbook deploy_nextcloud.yml -e "@$SECRETS_VARS" -D
  rules:
    - if: $CI_COMMIT_REF_NAME == "master"

Le flag -D (--diff) affiche les changements appliqués dans les logs du pipeline – pratique pour un audit rapide de ce qui a changé.

Sécurisation et durcissement

Héberger un cloud privé implique de prendre la sécurité au sérieux. Voici les mesures que j’applique systématiquement :

• Firewall UFW – Seuls les ports 22, 80, 443 et 3478 (Talk) sont ouverts
• Fail2ban – Protection contre le brute-force sur SSH et Nextcloud
• TLS 1.2+ uniquement – Les protocoles obsolètes (TLS 1.0/1.1, SSLv3) sont désactivés
• Headers de sécurité – HSTS, X-Content-Type-Options, X-Frame-Options configurés dans Nginx
• Mise à jour automatique – AIO gère les mises à jour de Nextcloud via Watchtower
• 2FA obligatoire – TOTP activé pour tous les comptes administrateurs

Pour aller plus loin sur le durcissement d’un serveur Debian avec Ansible, j’ai documenté ma méthode complète.

Cas d’usage en entreprise

Erreurs courantes et solutions

Checklist de mise en production

Questions fréquentes