Installer Nextcloud sur Ubuntu avec Docker Compose

Résumé express

• Angle retenu : Docker Compose avec MariaDB et Redis, avec une séparation nette entre application, base de données et cache.
• Objectif : obtenir une instance saine, testable et simple à reprendre plus tard, plutôt qu une installation rapide mais opaque.
• Points clés : prérequis, méthode retenue, vérifications après démarrage, puis points d attention avant exposition ou sauvegarde.

Monter un cloud perso ne se résume pas à faire apparaître une page de connexion. Pour que Nextcloud reste agréable à utiliser dans la durée, il faut choisir une méthode de déploiement claire, séparer les briques critiques et vérifier dès le premier démarrage que la base est saine.

Nextcloud a du sens quand on veut reprendre la main sur ses fichiers, ses partages et une partie de sa vie numérique sans dépendre complètement d un service tiers. Le vrai sujet n est pas seulement l installation, mais la maintenabilité, les sauvegardes et la cohérence de la pile.

Pourquoi utiliser cet outil ou cette approche

Nextcloud reste une des options les plus crédibles quand on veut reprendre la main sur le stockage de fichiers, les partages, les agendas, les contacts et quelques extensions utiles autour du travail collaboratif. Ce qui le rend intéressant dans un homelab, ce n est pas seulement son catalogue d’applications, mais le fait qu’il permette de construire un cloud perso lisible et évolutif.

L’intérêt réel apparaît surtout si vous voulez maîtriser l’emplacement des données, choisir votre logique de sauvegarde et garder un point d accès unique pour plusieurs usages. En revanche, ce type de service demande une base saine dès le départ, sinon les mises à jour, les performances et le support deviennent vite pénibles.

• Centraliser fichiers, partages et accès distants sur une pile que vous contrôlez.
• Garder une logique de sauvegarde adaptée au homelab plutôt qu un service opaque.
• Faire évoluer la plateforme par étapes, sans repartir de zéro à chaque changement.

Dans quels cas c’est pertinent

Cette approche devient pertinente si vous avez déjà un serveur Linux à la maison, un mini PC, un NUC ou un VPS privé et que vous voulez une instance propre pour vous, votre foyer ou un petit groupe. Elle est également logique si vous avez déjà un reverse proxy dans le labo et une stratégie simple pour les sauvegardes.

• Cloud perso pour synchroniser ses documents, photos et dossiers de travail.
• Plateforme familiale pour partager des fichiers sans dépendre complètement d un tiers.
• Brique de self-hosting à intégrer dans une pile plus large avec reverse proxy, supervision et sauvegardes.

Pre-requis

Si certains termes vous sont encore peu familiers, ce guide doit justement vous aider a poser une base propre avant d empiler les optimisations. L’idee est d avancer étape par étape, sans supposer que tout le vocabulaire d exploitation est déjà acquis.

Avant de lancer le déploiement, le plus utile est de verrouiller quelques bases simples : où seront stockées les données, comment le service sera exposé, et comment vous allez vérifier qu il fonctionne vraiment après le premier démarrage.

• Un hôte Ubuntu récent, mis à jour, avec Docker Engine et le plugin Docker Compose déjà fonctionnels.
• Un emplacement de stockage persistant pour les données applicatives et la base.
• Au moins un accès HTTP interne pour le premier test, puis idéalement un reverse proxy propre pour l exposition externe.
• Une enveloppe mémoire raisonnable : 2 Go minimum pour tester, plus confortable si vous ajoutez prévisualisations, suite bureautique ou plusieurs utilisateurs.
• Des mots de passe forts et une sauvegarde prévue avant toute mise en production réelle.

Méthode retenue et mise en place

La méthode retenue est volontairement linéaire : on met d abord en place une base minimale qui démarre proprement, puis on ajoute les couches de confort une fois le premier test valide.

La mise en place doit rester minimale et compréhensible. L idée n est pas de produire une stack parfaite dès le premier jet, mais d obtenir un service sain, puis d ajouter le reverse proxy, la sauvegarde et les intégrations secondaires une fois la base validée.

Exemple de compose.yaml

services:
  db:
    image: mariadb:11
    restart: unless-stopped
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    environment:
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: change-me-db-password
      MYSQL_ROOT_PASSWORD: change-me-root-password
    volumes:
      - db:/var/lib/mysql

  redis:
    image: redis:7-alpine
    restart: unless-stopped

  app:
    image: nextcloud:apache
    restart: unless-stopped
    ports:
      - "8080:80"
    depends_on:
      - db
      - redis
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: change-me-db-password
      REDIS_HOST: redis
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: change-me-admin-password
    volumes:
      - nextcloud:/var/www/html

volumes:
  db:
  nextcloud:

Gardez ces identifiants comme des placeholders et remplacez-les avant le démarrage. Pour une installation exposée, vous pouvez ensuite sortir les secrets du fichier Compose et les gérer via des variables ou des secrets Docker.

docker compose up -d

Configuration

Une fois l instance accessible, la vraie configuration commence. Il faut vérifier les domaines de confiance, le comportement derrière un reverse proxy, les tâches de fond, puis les quelques réglages qui rendent l exploitation plus confortable au quotidien.

• Ajouter le bon nom de domaine ou l URL interne selon votre mode d exposition.
• Vérifier les paramètres liés au reverse proxy si le trafic passe par Nginx, Traefik ou Caddy.
• Configurer les tâches de fond de manière fiable plutôt que de rester sur un mode trop approximatif.
• Activer SMTP, quotas ou stockage externe seulement une fois la base validée.

Le retour terrain le plus classique : une pile qui démarre vite mais dont personne ne sait plus expliquer le fonctionnement six mois plus tard finit toujours par coûter plus cher qu une installation un peu plus cadrée au départ.

Vérifications

Le service peut sembler opérationnel alors qu un détail réseau, une permission ou la base de données pose déjà problème. Une vraie vérification couvre donc l état des conteneurs, les logs utiles et le statut applicatif côté Nextcloud.

• Confirmer que la page d accueil répond et que l assistant de première connexion se termine sans alerte critique.
• Vérifier que les conteneurs restent stables après quelques minutes, sans boucle de redémarrage.
• Contrôler l accès aux données, les uploads et le comportement après un redémarrage du service.

docker compose ps
docker compose logs --tail=50 app
docker compose exec --user www-data app php occ status

Pour un lecteur débutant, la bonne approche est de vérifier chaque point dans l ordre : page accessible, conteneurs stables, connexion possible, puis test simple d’upload ou de fonctionnement.

Limites, pièges et points d attention

Les erreurs les plus pénibles au début viennent souvent d un prérequis implicite ou d une commande lancée trop vite. Mieux vaut ralentir un peu et valider chaque étape.

• Traiter les volumes comme un détail alors que permissions, emplacement et taille conditionnent déjà la stabilité.
• Exposer l instance publiquement sans HTTPS propre, domaines de confiance corrects et sauvegarde déjà testée.
• Sous-estimer la base de données en pensant que le dossier de fichiers suffit pour une vraie restauration.
• Ajouter Office, antivirus, prévisualisations lourdes ou stockage externe avant d avoir validé la base applicative.

Le piège classique consiste à vouloir tout faire en une fois : proxy, suite bureautique, sauvegarde distante, SMTP et durcissement avancé. Pour un article utile, mieux vaut montrer une base propre puis nommer clairement les extensions possibles.

FAQ

Pourquoi retenir Docker Compose ici plutôt que toutes les autres méthodes ?

Parce que cette approche garde une pile lisible pour un homelab : les services sont clairement séparés, les volumes sont explicites et la sauvegarde reste plus simple à raisonner. Cela n empêche pas d utiliser AIO ou une installation native dans d autres contextes, mais un bon article gagne à choisir une seule méthode et à la mener proprement.

Redis est-il vraiment utile sur une petite instance ?

Oui, si vous voulez une base plus saine dès le départ. Redis est couramment utilisé pour le verrouillage de fichiers et le cache, ce qui limite certains comportements peu agréables sur les accès concurrents.

Peut-on commencer en HTTP interne puis ajouter le reverse proxy ensuite ?

Oui, et c est souvent la meilleure approche. Validez d abord la pile en local ou sur le LAN, puis ajoutez HTTPS, le domaine public et le reverse proxy une fois les vérifications applicatives terminées.

Conclusion

Nextcloud mérite surtout une méthode claire et assumée. En choisissant dès le départ une pile lisible, des vérifications simples et une vraie logique de sauvegarde, vous obtenez une instance qui peut vivre dans le temps au lieu d un montage fragile difficile à reprendre.

Prochaine étape : valider la procédure sur un environnement de test puis documenter les choix retenus dans votre homelab.

📡 Soutenir le labo

Sephy-Lab est un projet libre et gratuit. Si tu veux soutenir les expériences et maintenir le système en ligne, tu peux m’aider ici.

Payez-moi un café !