Mise à niveau
cd /path/to/conzent
bash scripts/backup.sh && bash scripts/install.sh --update
Ou, de n'importe où :
curl -sSL https://getconzent.com/install | sh -s -- --update
Faites d'abord la sauvegarde. Les migrations s'exécutent automatiquement et ne sont pas réversibles.
Ce que fait la mise à jour
| Étape | Effet |
|---|---|
git fetch + git reset --hard | Les fichiers suivis sont réinitialisés à la version publiée. Les modifications locales sont abandonnées |
docker compose down | Les conteneurs s'arrêtent. Les volumes sont conservés — votre base de données survit |
Supprime le volume app-public | Les fichiers CSS/JS/média obsolètes sont supprimés afin que les actifs de la nouvelle version soient servis |
docker compose build --no-cache --pull | Reconstruction complète, en ignorant le cache des couches |
docker compose up -d | Tout redémarre |
migrations:migrate | Applique uniquement les migrations de schéma en attente |
scanner:register | Réenregistre le scanner intégré (idempotent) |
| Vidage de Redis + effacement du cache de template | Supprime les sessions obsolètes et les templates compilés |
| Création d'admin | Ignoré — vos utilisateurs ne sont pas touchés |
Attendez quelques minutes pour la reconstruction sans cache.
Ce qui survit : la base de données, les scripts de consentement générés, et chaque fichier non suivi — .env, .conzent-credentials, docker-compose.override.yml, backups/.
Ce qui ne survit pas : les modifications apportées aux fichiers suivis tels que docker-compose.yml, la configuration nginx, les templates et les fichiers source ; le volume app-public ; et le contenu de Redis, donc tout le monde est déconnecté.
Personnaliser sans perdre
La règle : ne jamais modifier un fichier suivi. Il y a deux endroits pris en charge pour vos modifications.
.env contient toute la configuration — APP_URL, APP_PORT, SMTP, réglages du scanner, clés tierces.
docker-compose.override.yml contient tout ce qui concerne la pile elle-même. Compose le fusionne automatiquement et il est ignoré par git :
services:
# Publier le scanner afin que les installations distantes puissent y accéder
scanner:
ports:
- "8300:8300"
# Donner plus de mémoire à MariaDB
mariadb:
command: --innodb-buffer-pool-size=1G
# Monter la configuration nginx personnalisée
nginx:
volumes:
- ./docker/nginx/custom.conf:/etc/nginx/conf.d/default.conf:ro
Les fichiers que vous ajoutez — un Caddyfile, une configuration nginx personnalisée — ne sont pas suivis et survivent aux mises à jour. Les fichiers que vous modifiez ne le sont pas.
Vérifier une mise à niveau
docker compose ps
docker compose exec app php bin/oci health
docker compose exec app php bin/oci scanner:health
Ensuite, chargez le tableau de bord et confirmez que vos personnalisations sont intactes. Si une bannière sur un site en direct semble incorrecte par la suite, exécutez docker compose exec app php bin/oci scripts:regenerate.
Si une mise à niveau échoue
# 1. Qu'est-ce qui a échoué
docker compose logs --tail=100 app
# 2. Revenir en arrière sur le code et les données ensemble
git checkout <previous-tag>
docker compose build --no-cache && docker compose up -d
bash scripts/restore.sh backups/<archive-taken-before-the-upgrade>.tar.gz --yes
Restaurer la sauvegarde d'avant la mise à niveau annule une migration — revenir en arrière sur le code seul laisse le nouveau schéma en place. C'est la raison de la règle de sauvegarde d'abord.
Désinstaller
bash scripts/install.sh --uninstall
Cela exécute docker compose down -v, supprimant chaque volume y compris la base de données, puis supprime le répertoire d'installation. Il demande d'abord une confirmation. Faites une sauvegarde s'il y a une chance que vous souhaitiez récupérer les données.
La référence complète se trouve avec le code : docs/upgrading.md sur GitHub.