Installer MediaWiki avec Docker Compose (prod) : HTTPS, base de données et volumes
MediaWiki est une excellente base pour une documentation interne, une base de connaissances ou un wiki de projet. Le combo Docker Compose + volumes persistants + reverse proxy HTTPS vous donne une installation reproductible, simple à maintenir, et facile à migrer.
Dans ce guide, on met en place une instance orientée production :
- MediaWiki (conteneur)
- MariaDB (ou MySQL) pour la base
- des volumes pour conserver la base et les fichiers uploadés
- un reverse proxy pour le HTTPS
Si vous cherchez le même type de déploiement “propre” pour d’autres apps, vous pouvez aussi voir : Installer Joomla avec Docker Compose (prod) et Installer Drupal avec Docker Compose (prod).
Prérequis (rapides)
- Une machine (VM ou serveur) avec Docker + Docker Compose
- Un nom de domaine (ex.
wiki.mondomaine.fr) - Des ports ouverts côté reverse proxy (généralement 80/443)
Conseil : même si des images Docker existent, MediaWiki précise qu’il n’y a pas “d’image officielle” dédiée à tous les usages de production. En pratique, pour la majorité des PME/TPE, c’est un excellent point de départ à condition d’appliquer des règles d’exploitation (sauvegardes, mises à jour, durcissement).
1) Créer un dossier de projet
Sur votre serveur :
mkdir -p /opt/mediawiki && cd /opt/mediawiki
Créez ensuite un fichier .env :
# Domaine public de votre wiki
MW_DOMAIN=wiki.mondomaine.fr
# DB
MYSQL_DATABASE=mediawiki
MYSQL_USER=mediawiki
MYSQL_PASSWORD=change-me-strong
MYSQL_ROOT_PASSWORD=change-me-root-strong
# Fuseau horaire
TZ=Europe/Paris
2) Docker Compose (MediaWiki + MariaDB)
Créez compose.yml :
services:
db:
image: mariadb:10.11
restart: unless-stopped
environment:
MYSQL_DATABASE: ${MYSQL_DATABASE}
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
TZ: ${TZ}
volumes:
- db_data:/var/lib/mysql
mediawiki:
image: mediawiki:stable
restart: unless-stopped
depends_on:
- db
environment:
TZ: ${TZ}
ports:
# En prod, exposez plutôt MediaWiki en interne et laissez le reverse proxy gérer l'exposition
- 127.0.0.1:8080:80
volumes:
- mw_images:/var/www/html/images
# Après installation, ajoutez LocalSettings.php (voir étape suivante)
# - ./LocalSettings.php:/var/www/html/LocalSettings.php:ro
volumes:
db_data:
mw_images:
Lancez :
docker compose up -d
Puis ouvrez l’installeur (localement via tunnel SSH, ou via votre réseau) :
http://127.0.0.1:8080
Paramètres à saisir dans l’installeur
- Type de base : MySQL/MariaDB
- Hôte DB : db
- Nom de base : valeur de
MYSQL_DATABASE - Utilisateur / mot de passe :
MYSQL_USER/MYSQL_PASSWORD
3) Rendre la config persistante (LocalSettings.php)
À la fin de l’installation, MediaWiki vous propose de télécharger LocalSettings.php.
- Placez-le dans
/opt/mediawiki/LocalSettings.php - Décommentez le volume correspondant dans
compose.yml:
volumes:
- mw_images:/var/www/html/images
- ./LocalSettings.php:/var/www/html/LocalSettings.php:ro
- Redémarrez :
docker compose up -d
C’est une étape clé : sans ça, vous risquez de “perdre” la configuration à la recreation du conteneur.
4) Ajouter le HTTPS via reverse proxy (Caddy, simple et fiable)
Le plus propre est de terminer le TLS au niveau d’un reverse proxy (Caddy / Traefik / Nginx).
Si vous utilisez déjà un reverse proxy commun à plusieurs applications, gardez-le. Sinon, voici une variante simple avec Caddy.
Variante : Caddy sur la même machine
Ajoutez un service caddy (ou faites-le tourner à côté) qui reverse-proxy vers http://127.0.0.1:8080. Exemple de Caddyfile :
wiki.mondomaine.fr {
encode zstd gzip
reverse_proxy 127.0.0.1:8080
}
Si vous avez déjà publié un site via reverse proxy, la logique est identique à ce que vous feriez pour un CMS : vous pouvez vous inspirer de la partie “HTTPS + reverse proxy” de Déployer WordPress en production.
5) Volumes : ce qui doit survivre (obligatoire)
Deux emplacements doivent rester persistants :
- la base (volume
db_data) - les uploads (volume
mw_images, dossier/images)
Astuce : si vous migrez un serveur, ces deux volumes + LocalSettings.php suffisent, dans la plupart des cas, à restaurer votre wiki.
6) Sauvegardes : la version qui évite les sueurs froides
Pour un PRA minimal, vous voulez :
- un dump MariaDB
- une copie des uploads (
mw_images) - un test de restauration régulier
Exemple de dump :
# dump DB
docker compose exec -T db mysqldump -u"${MYSQL_USER}" -p"${MYSQL_PASSWORD}" "${MYSQL_DATABASE}" > mediawiki-db.sql
Pour les uploads (volume), une approche simple consiste à les exporter dans une archive sur le host (ou vers un stockage externe).
Si vous mettez en place une stratégie “sauvegarde + chiffrement + tests”, la philosophie est proche de ce qu’on recommande pour les automatisations : Sauvegarder / restaurer n8n (PRA).
7) Bonnes pratiques prod (performances + sécurité)
Quelques réglages “à fort ROI” :
- Limiter CPU/RAM sur les services pour éviter l’effet domino en cas de pic
- Mettre en place une routine de mises à jour (image MediaWiki + DB + extensions)
- Centraliser les logs (au minimum, conserver les logs Docker et ajouter une rotation)
- Restreindre l’accès réseau : l’idéal est que la DB ne soit pas exposée et que MediaWiki ne soit pas publié directement sur Internet sans reverse proxy
Côté extensions, installez peu au début, puis ajoutez progressivement (et documentez-les). Chaque extension est un risque potentiel si elle n’est pas maintenue.
Une vidéo (FR) pour bien démarrer avec MediaWiki
Pour la prise en main de l’édition et des pages : 
Déployer MediaWiki sur adgents.cloud (option simple et scalable)
Si vous voulez éviter la gestion serveur (mises à jour, gestion de capacité, sauvegardes), vous pouvez déployer MediaWiki sur adgents.cloud :
- déploiement rapide
- scaling CPU/RAM
- sauvegardes automatisées (jusqu’à 1/h)
- arrêt/démarrage (compute non facturé à l’arrêt)
Découvrez l’app : MediaWiki sur adgents.cloud.
Récapitulatif
- Compose : MediaWiki + MariaDB
- Persistant : DB + uploads + LocalSettings.php
- HTTPS : reverse proxy
- Exploitation : sauvegardes + tests + mises à jour
Vous voulez aller plus loin (SSO, anti-spam, cache) ? Le plus efficace est d’ajouter une brique à la fois, en validant l’impact (et en conservant un plan de retour arrière).
