Docker container management is a battlefield. You’re either fighting with outdated images, wrestling with security patches, or trying to avoid the chaos of an automatic update that breaks your production stack. Now, a new open-source tool has entered the ring: a Docker update notifier that does exactly what it says on the tin — but with a twist. It uses a proxy and deliberately avoids auto-updates.
Let’s be honest: the Docker ecosystem already has tools like Watchtower for automatic updates, Diun for notifications, and Ouroboros for self-healing containers. So why would anyone need yet another notifier? The answer lies in the fine print: this one is built for environments where control and security are paramount, and where a proxy is not a luxury but a necessity.
What Makes This Notifier Different?
The core idea is refreshingly simple: the tool monitors Docker registries (like Docker Hub, GitHub Container Registry, or private registries) for new versions of running containers. When an update is detected, it sends a notification — but it does not pull or restart anything. No automatic rollouts, no silent restarts, no surprises.
The standout feature is native proxy support. Many organizations run Docker behind corporate proxies, air-gapped networks, or VPNs. Most existing notifiers either ignore proxy settings or require complex workarounds. This tool integrates proxy configuration directly, allowing it to work in restricted environments without manual tunneling.
How It Works: Under the Hood
According to the original article on Habr, the tool is written in Go and uses a YAML configuration file. Here’s a simplified breakdown:
- Configuration: You define a list of containers to monitor, along with proxy settings (HTTP/HTTPS/SOCKS5).
- Polling: At a configurable interval, it queries the registry for the latest image digest or tag.
- Comparison: It compares the current running image digest with the latest available digest.
- Notification: If a newer version exists, it sends an alert via a supported channel (currently Telegram is mentioned, with extensibility for others).
- No Actions: It never pulls, stops, or restarts containers. That’s left to the admin.
| Feature | This Notifier | Watchtower | Diun |
|---|---|---|---|
| Auto-update | No | Yes | No |
| Proxy support | Native (HTTP/HTTPS/SOCKS5) | Limited (env vars) | Limited (env vars) |
| Notification channels | Telegram (extensible) | Webhook, email | Telegram, Slack, email |
| Configuration | YAML | CLI flags/env | YAML |
| Architecture | Single binary | Docker container | Docker container |
The table above shows that while Watchtower is great for automated environments, it can be dangerous in production. Diun is closer in spirit, but lacks the same level of proxy integration. This new tool fills a niche for teams that need to know about updates without automation risks.
Why No Auto-Updates? A Deliberate Choice
The absence of auto-updates is not a limitation — it’s a philosophy. In many real-world scenarios, automatic updates can be disastrous:
- Database containers: Updating PostgreSQL or MySQL without migration planning can corrupt data.
- Custom applications: A new base image might introduce breaking API changes.
- Compliance: Regulated industries (finance, healthcare) require manual approval for any software change.
The authors explicitly state that the tool is designed for “human-in-the-loop” workflows. You get notified, you review the changelog, you test in staging, and then you update. This is exactly what DevOps teams in regulated environments need.
Proxy Support: More Than a Feature
Enterprise networks often route all traffic through a proxy for security monitoring and policy enforcement. Many Docker tools struggle with this. For example, Watchtower can use environment variables like HTTP_PROXY, but this doesn’t always work with SOCKS5 or authenticated proxies. The new notifier makes proxy configuration a first-class citizen in its YAML file.
Example configuration snippet from the project:
proxy:
http: http://proxy.company.com:8080
https: https://proxy.company.com:8443
socks5: socks5://proxy.company.com:1080
auth:
username: user
password: pass
This level of detail is rare in Docker monitoring tools. For teams behind strict firewall rules, this alone is a reason to adopt it.
Real-World Use Cases
Case 1: Financial Services
A fintech company runs Docker containers on private cloud infrastructure behind a SOCKS5 proxy. They cannot allow any tool to pull images automatically due to audit requirements. They deploy this notifier to all hosts. When a new version of Redis is available, the tool sends a Telegram message to the ops channel. An engineer reviews the release notes, tests in a staging environment, and then manually updates production.
Case 2: Healthcare
A hospital’s IT department manages a containerized EHR system. The network is segmented and all outbound traffic goes through an authenticated HTTP proxy. Existing tools fail because they don’t support proxy authentication in the config. This notifier works out of the box. The team now receives daily digest notifications about available updates without any automation risk.
Case 3: Air-Gapped Environment
An energy company has Docker registries mirrored in a local network. The notifier is configured to poll the local registry, not the public internet. It uses the proxy only for notification delivery (Telegram). This hybrid approach keeps the monitoring lightweight and secure.
Limitations and Trade-offs
No tool is perfect. The current version has a few caveats:
- Notification channels: Only Telegram is confirmed working in the initial release. The architecture supports adding others, but you might need to write custom code for Slack or email.
- Scalability: It’s designed for single-host monitoring or small clusters. For large Kubernetes deployments, tools like Keel or Flux may be more appropriate.
- No web UI: Configuration is YAML-only. No dashboard, no GUI. This is fine for DevOps teams but may be a barrier for less technical ops staff.
How to Get Started
If you’re intrigued, here’s a quick start (based on the project documentation):
- Clone the repository from GitHub.
- Create a
config.ymlfile with your containers and proxy settings. - Build the binary with Go (or use the provided Docker image).
- Run it as a systemd service or inside a Docker container.
- Configure your Telegram bot token and chat ID.
- Wait for the first notification.
The entire setup takes about 10 minutes for experienced Docker users.
The Bigger Picture: A Trend Toward Controlled Automation
This tool is part of a broader movement in DevOps: moving away from “set and forget” automation toward informed, human-approved updates. The rise of supply chain attacks (like the compromise of popular Docker images) has made teams cautious. Tools that notify without acting are becoming essential for security-conscious organizations.
ASI Biont supports connecting to Docker registries and monitoring tools via API — learn more at asibiont.com/courses. While this notifier is a standalone project, integrating it with a centralized monitoring platform can provide even better visibility.
Conclusion
Another Docker update notifier? Yes. But this one is built for the real world — where proxies are mandatory, auto-updates are dangerous, and control is non-negotiable. It won’t replace Watchtower for hobbyists, but for enterprise teams with strict security policies, it’s a breath of fresh air. The choice to avoid auto-updates is not a weakness; it’s a feature that respects the complexity of production environments.
If you’re tired of fighting with proxy configurations or fearing the next automatic restart, give this tool a try. Sometimes the simplest solutions are the most effective.
Comments