[{"data":1,"prerenderedAt":215},["ShallowReactive",2],{"seo-verification":3,"blog-mise-a-jour-automatique-docker-watchtower-diun-2-ma-en":6,"promo-bar-likely":126},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-mise-a-jour-automatique-docker-watchtower-diun-2-ma-en",{"id":9,"slug":10,"slugs":11,"title":14,"excerpt":15,"readTime":16,"views":17,"isPinned":18,"noindex":18,"publishedAt":19,"updatedAt":20,"category":21,"categories":26,"featuredImage":28,"bgImage":29,"posterImage":30,"relatedSolution":28,"intro":31,"sections":32,"ctaTitle":111,"ctaBody":112,"ctaButton":113,"ctaUrl":114,"relatedPosts":115},350,"mise-a-jour-automatique-docker-watchtower-diun-2",{"fr":12,"en":10,"ar":10,"es":13},"mise-a-jour-automatique-docker-watchtower-diun","watchtower-vs-diun-actualizaciones-docker-en-vps-sin-sorpresas","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,5,false,"2026-09-11T00:00:00+00:00","2026-09-17T14:09:38+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":24},3,"Deployment","deploiement","bg-success\u002F10 text-success",[27],{"id":22,"name":23,"slug":24,"color":25,"icon":24},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.",[33,37,40,44,47,77,80,96,99,102],{"type":34,"title":35,"body":36},"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":34,"title":38,"body":39},"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":41,"title":42,"body":43},"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":34,"title":45,"body":46},"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":48,"title":49,"headers":50,"rows":54},"comparison","When to choose one or the other",[51,52,53],"Context","Watchtower","Diun",[55,59,63,66,70,73],[56,57,58],"Dev \u002F staging environment","Acceptable (convenience)","Overkill",[60,61,62],"Prod with versioned tags (not :latest)","Avoid — recreates on same tag","Recommended",[64,65,62],"Prod with third-party API dependencies","Risky without prior testing",[67,68,69],"Homelab \u002F personal services","Practical","Good if alerts are active",[71,72,62],"Stack managed by Coolify, Dokploy, Portainer","Possible conflict with orchestrator",[74,75,76],"Project without a deployment pipeline","Acceptable with monitor-only","Recommended with ntfy\u002FSlack",{"type":34,"title":78,"body":79},"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":81,"title":82,"steps":83},"steps","Deploy Diun on your VPS",[84,87,90,93],{"title":85,"body":86},"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":88,"body":89},"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":91,"body":92},"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":94,"body":95},"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":34,"title":97,"body":98},"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":41,"title":100,"body":101},"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":103,"title":104,"items":105},"ul","Key takeaways from this comparison",[106,107,108,109,110],"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",[116,140,156,179,201],{"id":117,"slug":118,"slugs":119,"title":123,"excerpt":124,"readTime":22,"views":125,"isPinned":18,"noindex":126,"publishedAt":127,"updatedAt":128,"category":129,"categories":135,"featuredImage":28,"bgImage":29,"posterImage":137,"relatedSolution":138},136,"installing-docker-on-a-vps-a-clean-base-for-your-apps",{"fr":120,"en":118,"ar":121,"es":122},"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.",1,true,"2026-02-10T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":130,"name":131,"slug":132,"color":133,"icon":134},4,"Development","developpement","bg-warning\u002F10 text-warning","dev",[136],{"id":130,"name":131,"slug":132,"color":133,"icon":134},"\u002Fblog\u002Fcovers\u002Fdemarrer-avec-docker-vps-poster.svg",{"categorySlug":134,"appSlug":139},"docker-starter",{"id":141,"slug":142,"slugs":143,"title":147,"excerpt":148,"readTime":149,"views":125,"isPinned":18,"noindex":18,"publishedAt":150,"updatedAt":151,"category":152,"categories":153,"featuredImage":28,"bgImage":29,"posterImage":155,"relatedSolution":28},229,"docker-compose-in-production-10-point-checklist",{"fr":144,"en":142,"ar":145,"es":146},"docker-compose-production-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","checklist-docker-compose-en-produccion","Docker Compose in Production: 10-Point Checklist","Docker Compose in production: 10 settings, health checks, secrets, rollback, troubleshooting and moving from docker-compose v1 to docker compose on Ubuntu 26.04.",12,"2026-08-06T00:00:00+00:00","2026-10-23T13:27:09+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":24},[154],{"id":22,"name":23,"slug":24,"color":25,"icon":24},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":157,"slug":158,"slugs":159,"title":163,"excerpt":164,"readTime":130,"views":165,"isPinned":18,"noindex":18,"publishedAt":166,"updatedAt":128,"category":167,"categories":173,"featuredImage":28,"bgImage":29,"posterImage":175,"relatedSolution":176},167,"how-to-self-host-dozzle-on-a-vps-real-time-docker-log-viewer",{"fr":160,"en":158,"ar":161,"es":162},"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.",2,"2026-07-06T00:00:00+00:00",{"id":168,"name":169,"slug":170,"color":171,"icon":172},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[174],{"id":168,"name":169,"slug":170,"color":171,"icon":172},"\u002Fblog\u002Fcovers\u002Fself-host-dozzle-vps-poster.svg",{"categorySlug":177,"appSlug":178},"monitoring-observability","dozzle",{"id":180,"slug":181,"slugs":182,"title":186,"excerpt":187,"readTime":188,"views":165,"isPinned":18,"noindex":18,"publishedAt":189,"updatedAt":190,"category":191,"categories":196,"featuredImage":28,"bgImage":29,"posterImage":198,"relatedSolution":199},194,"self-host-ntfy-on-a-vps-push-notifications-for-scripts-and-cicd",{"fr":183,"en":181,"ar":184,"es":185},"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.",16,"2026-07-28T00:00:00+00:00","2026-11-04T16:30:26+00:00",{"id":16,"name":192,"slug":193,"color":194,"icon":195},"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[197],{"id":16,"name":192,"slug":193,"color":194,"icon":195},"\u002Fblog\u002Fcovers\u002Fself-host-ntfy-vps-poster.svg",{"categorySlug":177,"appSlug":200},"ntfy",{"id":202,"slug":203,"slugs":204,"title":208,"excerpt":209,"readTime":130,"views":125,"isPinned":18,"noindex":126,"publishedAt":210,"updatedAt":128,"category":211,"categories":212,"featuredImage":28,"bgImage":29,"posterImage":214,"relatedSolution":28},224,"self-hosted-apps-the-patching-routine",{"fr":205,"en":203,"ar":206,"es":207},"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":16,"name":192,"slug":193,"color":194,"icon":195},[213],{"id":16,"name":192,"slug":193,"color":194,"icon":195},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",1794270454909]