[{"data":1,"prerenderedAt":209},["ShallowReactive",2],{"seo-verification":3,"blog-mise-a-jour-automatique-docker-watchtower-diun-2-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-mise-a-jour-automatique-docker-watchtower-diun-2-en",{"id":9,"slug":10,"slugs":11,"title":13,"excerpt":14,"readTime":15,"views":16,"isPinned":17,"publishedAt":18,"updatedAt":19,"category":20,"categories":25,"featuredImage":27,"bgImage":28,"posterImage":29,"relatedSolution":27,"intro":30,"sections":31,"ctaTitle":110,"ctaBody":111,"ctaButton":112,"ctaUrl":113,"relatedPosts":114},350,"mise-a-jour-automatique-docker-watchtower-diun-2",{"fr":12,"en":10,"ar":10,"es":10},"mise-a-jour-automatique-docker-watchtower-diun","Watchtower vs Diun: managing Docker image updates on a VPS","Watchtower updates your containers automatically. Diun notifies you and lets you decide. Compare both to choose the right approach for your VPS.",8,0,false,"2026-09-11T00:00:00+00:00","2026-09-11T11:34:13+00:00",{"id":21,"name":22,"slug":23,"color":24,"icon":23},3,"Deployment","deploiement","bg-success\u002F10 text-success",[26],{"id":21,"name":22,"slug":23,"color":24,"icon":23},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmise-a-jour-automatique-docker-watchtower-diun-poster.svg","Docker images age silently: security patches accumulate, dependencies are affected, and nothing alerts you. Without a process in place, you either never patch or do it manually the day an incident hits. Watchtower and Diun address this problem with two opposing philosophies — one acts for you, the other informs you. This comparison helps you choose based on your context, and accounts for a recent fact: Watchtower was archived by its maintainers at the end of 2025.",[32,36,39,43,46,76,79,95,98,101],{"type":33,"title":34,"body":35},"h2","The problem: Docker images aging in silence","On a production VPS, Docker containers often run for weeks or months without being updated. This is not negligence — there is simply no signal. The `nginx:latest` image you pulled in January is still there in September, carrying vulnerabilities that have since been patched.\n\nThe cost of inaction is documented: unpatched CVEs in base images are one of the most common entry vectors on self-hosted Docker infrastructure. Manual updates — connecting to the VPS, running `docker pull`, recreating the container — are the default practice. They are also the least reliable: you postpone, forget, and only update the \"important\" services.\n\nTwo tools have emerged to structure this process: **Watchtower**, which automates the update itself, and **Diun** (Docker Image Update Notifier), which sends an alert when a new image is available and leaves the action to your pipeline. They do not do the same thing, and confusing the two philosophies can cost you a production outage.",{"type":33,"title":37,"body":38},"Watchtower: automatic updates, but archived since late 2025","Watchtower monitors your running containers, queries registries at regular intervals, and as soon as a new image is available, pulls the new tag, stops the existing container and recreates it with the same options — volumes, environment variables, network. All without human intervention.\n\n**What it does in practice:**\n\n- Configurable polling by duration (every N seconds) or cron expression\n- Private registry support with authentication\n- `WATCHTOWER_NOTIFICATIONS` mode to receive alerts without performing updates\n- Docker label filtering to include or exclude specific containers\n\n**The risk in production is real.** If a `:latest` image introduces an incompatible API change or breaking behavior, Watchtower will recreate your container with that image — without testing, without a maintenance window, potentially at 3 AM. The container restarts with the wrong version, and discovery happens through a monitoring alert or a support call.\n\n**Important status update:** the Watchtower GitHub repository was **archived by its maintainers on late 2025**. It is now read-only. The last published version is `v1.7.1`. The project remains functional and existing Docker images continue to run, but it will no longer receive security fixes, new features, or support for future Docker versions. For a tool whose role is to update your images, the irony is not insignificant.\n\nFor development environments or homelabs where convenience outweighs stability, Watchtower remains a legitimate choice. For production, its archival reinforces a conclusion that already existed: automatic updates without a validation pipeline are an operational risk.",{"type":40,"title":41,"body":42},"tip","Watchtower in notify-only mode","If you already use Watchtower and want to disable automatic updates while keeping notifications, set the variable `WATCHTOWER_MONITOR_ONLY=true`. The container monitors images and sends alerts but does not act. This is a useful transition configuration if you are migrating to Diun.",{"type":33,"title":44,"body":45},"Diun: alerts only, you stay in control","Diun (Docker Image Update Notifier) approaches the problem from the other direction: it monitors your images on registries and sends you a notification when a new version is available. It does not act. Your containers keep running unchanged — the decision to update stays in your pipeline.\n\nLicensed under MIT, Diun is actively developed: version `la version actuelle` was published on recently. The project covers a wide range of sources (Docker, Containerd, Kubernetes, Swarm, Nomad, Dockerfile, configuration file) and notification channels.\n\n**Supported notification channels:**\n\n- Email, Slack, Telegram, ntfy, Gotify\n- Microsoft Teams, Discord, generic webhooks\n- Healthchecks.io to monitor the watcher itself\n\n**What Diun does not do:**\n\n- It never pulls an image\n- It never restarts a container\n- It never modifies any configuration file\n\nThis philosophy is precisely what makes it suitable for production. When Diun signals that a new image is available, you can trigger your usual deployment pipeline — with its tests, prior backup, and maintenance window. You remain in a controlled posture.\n\nDiun is also compatible with stacks managed by tools like Portainer, Coolify or Dokploy: it observes images without interfering with their orchestration.",{"type":47,"title":48,"headers":49,"rows":53},"comparison","When to choose one or the other",[50,51,52],"Context","Watchtower","Diun",[54,58,62,65,69,72],[55,56,57],"Dev \u002F staging environment","Acceptable (convenience)","Overkill",[59,60,61],"Prod with versioned tags (not :latest)","Avoid — recreates on same tag","Recommended",[63,64,61],"Prod with third-party API dependencies","Risky without prior testing",[66,67,68],"Homelab \u002F personal services","Practical","Good if alerts are active",[70,71,61],"Stack managed by Coolify, Dokploy, Portainer","Possible conflict with orchestrator",[73,74,75],"Project without a deployment pipeline","Acceptable with monitor-only","Recommended with ntfy\u002FSlack",{"type":33,"title":77,"body":78},"Installing Diun on a VPS: practical example","Installing Diun takes a few minutes with Docker Compose. The following example monitors all containers on the local Docker socket and sends notifications via ntfy.",{"type":80,"title":81,"steps":82},"steps","Deploy Diun on your VPS",[83,86,89,92],{"title":84,"body":85},"Create the docker-compose.yml file","Create a dedicated directory and the Compose file:\n\n```bash\nmkdir -p \u002Fopt\u002Fdiun && cd \u002Fopt\u002Fdiun\n```\n\nContent of the `docker-compose.yml` file:\n\n```bash\nservices:\n  diun:\n    image: crazymax\u002Fdiun:latest\n    restart: unless-stopped\n    volumes:\n      - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock\n      - .\u002Fdata:\u002Fdata\n    environment:\n      - TZ=Europe\u002FParis\n      - LOG_LEVEL=info\n      - DIUN_WATCH_WORKERS=20\n      - DIUN_WATCH_SCHEDULE=0 *\u002F6 * * *\n      - DIUN_PROVIDERS_DOCKER=true\n      - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true\n      - DIUN_NOTIF_NTFY_ENDPOINT=https:\u002F\u002Fntfy.example.com\n      - DIUN_NOTIF_NTFY_TOPIC=diun-updates\n```\n\nReplace `ntfy.example.com` with the URL of your ntfy instance (self-hosted on the same VPS or external).",{"title":87,"body":88},"Enable label-based monitoring (optional)","By default, Diun monitors all containers. For finer control, switch to label mode:\n\n```bash\n- DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=false\n```\n\nThen add the label to the containers you want to monitor:\n\n```bash\nlabels:\n  - \"diun.enable=true\"\n```\n\nThis approach is useful for excluding system containers (proxies, databases) from notifications, and only monitoring application containers.",{"title":90,"body":91},"Start and verify","```bash\ndocker compose up -d\ndocker compose logs -f diun\n```\n\nDiun performs an initial discovery pass at startup. The logs confirm the images detected and the next monitoring cycle. A test notification can be triggered with:\n\n```bash\ndocker compose exec diun diun notif test\n```",{"title":93,"body":94},"Trigger the update from your pipeline","When Diun sends a notification, the update should not be done by hand. The right approach is to trigger your usual pipeline — a Gitea webhook, a GitHub Action, or a Woodpecker job that pulls the new image, runs your tests, and recreates the container.\n\nIf you do not yet have a pipeline, the minimum viable option is a script called from the ntfy webhook:\n\n```bash\n#!\u002Fbin\u002Fbash\n# update-container.sh \u003Ccontainer_name>\nCONTAINER=$1\ndocker compose -f \u002Fopt\u002F${CONTAINER}\u002Fdocker-compose.yml pull\ndocker compose -f \u002Fopt\u002F${CONTAINER}\u002Fdocker-compose.yml up -d\n```\n\nThe key point is that the update is **triggered intentionally**, not silently.",{"type":33,"title":96,"body":97},"Going further: pin versions and stay in control","Automatic updates without a fixed tag are the real risk — whether you use Watchtower or a pipeline triggered by Diun. The `:latest` tag is an alias that can point to any version published by the maintainer. An update to `:latest` can introduce a breaking change without anything in your configuration changing.\n\n**The practice recommended by the Docker community:**\n\nPin versions in your production `docker-compose.yml` files:\n\n```bash\n# Avoid in prod\nimage: nginx:latest\n\n# Prefer a version tag\nimage: nginx:1.27\n```\n\nReserve `:latest` for development and staging environments, where a regression is detectable before it touches production.\n\nWith versioned images, Diun detects new releases (new tags) and notifies you — you choose the version to migrate to, update your `docker-compose.yml`, and deploy with full control. This is what the \u003Ca href=\"\u002Fblog\u002Fdocker-compose-production-checklist\">Docker Compose production checklist\u003C\u002Fa> calls \"declaring your dependencies explicitly\".\n\nIf you manage multiple containers on the same VPS, a log monitoring tool like \u003Ca href=\"\u002Fblog\u002Fself-host-dozzle-vps\">Dozzle\u003C\u002Fa> usefully complements Diun: Diun monitors images upstream, Dozzle observes container logs after an update.",{"type":40,"title":99,"body":100},"Diun also monitors stopped images","By default, Diun ignores stopped containers. Enable `DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true` to also monitor images of paused or stopped containers — useful if you manage batch services or maintenance containers that you restart periodically.",{"type":102,"title":103,"items":104},"ul","Key takeaways from this comparison",[105,106,107,108,109],"Watchtower acts without asking — useful in dev, risky in prod, and archived since late 2025.","Diun informs without acting — compatible with any existing deployment pipeline and actively maintained (la version actuelle).","For production, Diun coupled with your pipeline is the most robust choice.","Pinning versions in docker-compose.yml remains the foundation — neither Watchtower nor Diun replaces explicit tag management.","If you have Watchtower in place, `WATCHTOWER_MONITOR_ONLY=true` mode is an immediate transition to safer behavior.","Launch your Docker stack on a ServOrbit VPS","Root access, NVMe SSD, dedicated IPv4: the conditions to reproduce these examples exactly. Diun and your deployment pipeline run on the same machine as your application containers.","See Linux VPS plans","\u002Fsolutions\u002Fdeveloppeurs",[115,137,151,174,195],{"id":116,"slug":117,"slugs":118,"title":122,"excerpt":123,"readTime":21,"views":16,"isPinned":17,"publishedAt":124,"updatedAt":125,"category":126,"categories":132,"featuredImage":27,"bgImage":28,"posterImage":134,"relatedSolution":135},136,"installing-docker-on-a-vps-a-clean-base-for-your-apps",{"fr":119,"en":117,"ar":120,"es":121},"demarrer-avec-docker-vps","تثبيت-docker-على-vps-قاعدة-نظيفة-لتطبيقاتك","instalar-docker-en-un-vps","Installing Docker on a VPS: A Clean Base for Your Apps","Set up a reliable Docker VPS: isolation, Compose, volumes, networking and best practices to deploy without improvising.","2026-02-10T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":127,"name":128,"slug":129,"color":130,"icon":131},4,"Development","developpement","bg-warning\u002F10 text-warning","dev",[133],{"id":127,"name":128,"slug":129,"color":130,"icon":131},"\u002Fblog\u002Fcovers\u002Fdemarrer-avec-docker-vps-poster.svg",{"categorySlug":131,"appSlug":136},"docker-starter",{"id":138,"slug":139,"slugs":140,"title":144,"excerpt":145,"readTime":15,"views":16,"isPinned":17,"publishedAt":146,"updatedAt":125,"category":147,"categories":148,"featuredImage":27,"bgImage":28,"posterImage":150,"relatedSolution":27},229,"docker-compose-in-production-10-point-checklist",{"fr":141,"en":139,"ar":142,"es":143},"docker-compose-production-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","checklist-docker-compose-en-produccion","Docker Compose in Production: 10-Point Checklist","10 Docker Compose settings to verify before any production deployment: restart, healthchecks, limits, secrets and logs.","2026-08-06T00:00:00+00:00",{"id":21,"name":22,"slug":23,"color":24,"icon":23},[149],{"id":21,"name":22,"slug":23,"color":24,"icon":23},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":152,"slug":153,"slugs":154,"title":158,"excerpt":159,"readTime":127,"views":160,"isPinned":17,"publishedAt":161,"updatedAt":125,"category":162,"categories":168,"featuredImage":27,"bgImage":28,"posterImage":170,"relatedSolution":171},167,"how-to-self-host-dozzle-on-a-vps-real-time-docker-log-viewer",{"fr":155,"en":153,"ar":156,"es":157},"self-host-dozzle-vps","استضافة-dozzle-على-vps-عارض-سجلات-docker-لحظيا","alojar-dozzle-en-un-vps","How to Self-Host Dozzle on a VPS: Real-Time Docker Log Viewer","Deploy Dozzle on your VPS — a stateless, open-source Docker log viewer. Stream, search and tail logs from all your containers in the browser, without SSH or log storage.",1,"2026-07-06T00:00:00+00:00",{"id":163,"name":164,"slug":165,"color":166,"icon":167},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[169],{"id":163,"name":164,"slug":165,"color":166,"icon":167},"\u002Fblog\u002Fcovers\u002Fself-host-dozzle-vps-poster.svg",{"categorySlug":172,"appSlug":173},"monitoring-observability","dozzle",{"id":175,"slug":176,"slugs":177,"title":181,"excerpt":182,"readTime":127,"views":16,"isPinned":17,"publishedAt":183,"updatedAt":184,"category":185,"categories":190,"featuredImage":27,"bgImage":28,"posterImage":192,"relatedSolution":193},194,"self-host-ntfy-on-a-vps-push-notifications-for-scripts-and-cicd",{"fr":178,"en":176,"ar":179,"es":180},"self-host-ntfy-vps","استضافة-ntfy-على-vps-إشعارات-فورية-من-سكريبتاتك-وcicd","autoalojar-ntfy-en-un-vps","Self-host ntfy on a VPS: push notifications for scripts and CI\u002FCD","Deploy ntfy on your VPS and send push notifications from any script, cron job or CI\u002FCD pipeline with a plain curl — no SaaS, no API key, no subscription.","2026-07-28T00:00:00+00:00","2026-09-11T11:34:11+00:00",{"id":15,"name":186,"slug":187,"color":188,"icon":189},"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[191],{"id":15,"name":186,"slug":187,"color":188,"icon":189},"\u002Fblog\u002Fcovers\u002Fself-host-ntfy-vps-poster.svg",{"categorySlug":172,"appSlug":194},"ntfy",{"id":196,"slug":197,"slugs":198,"title":202,"excerpt":203,"readTime":127,"views":160,"isPinned":17,"publishedAt":204,"updatedAt":125,"category":205,"categories":206,"featuredImage":27,"bgImage":28,"posterImage":208,"relatedSolution":27},224,"self-hosted-apps-the-patching-routine",{"fr":199,"en":197,"ar":200,"es":201},"routine-correctifs-apps-self-hosted","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","apps-self-hosted-rutina-de-parches","Self-hosted apps: the patching routine","Inventory, security advisories, a patch window, backups and post-checks: the routine most self-hosted estates are missing.","2026-08-05T00:00:00+00:00",{"id":15,"name":186,"slug":187,"color":188,"icon":189},[207],{"id":15,"name":186,"slug":187,"color":188,"icon":189},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",1789126851095]