I built Versentry to scratch my own itch: I run Docker across several self-hosted boxes and wanted to know when images have updates - without anything auto-pulling or restarting my containers behind my back.

Before that, I used WUD, but at the time Versentry was created, it didn’t have a proxy for Telegram notifications, which was the impetus. As a result, I ended up with a micro‑service that fully meets my needs.

What it does: reads running containers from the local Docker socket, compares their tags and digests against OCI registries, and sends a notification when something’s newer. It never pulls images or touches containers. That’s the whole point - notify-only by design.

A few things that set it apart:

  • Central tag-filter rules in config (regex by image repo), so you’re not forced to label every container. Per-container versentry.include labels also work if you prefer them.
  • Built-in proxy (SOCKS5/HTTP) for notifier delivery and registry traffic - handy behind network restrictions.
  • Any OCI registry - Docker Hub, GHCR, Quay, GitLab out of the box; private/self-hosted via type: oci.
  • Notifiers: stdout, Telegram, Discord, Gotify, ntfy, and a generic webhook.
  • Readable notifications out of the box - sensible default messages, no template-wrangling required; Go text/template overrides are there if you want to customize.
  • semver/numeric detection (cross-major updates get flagged) plus digest comparison for floating tags like latest.
  • Tiny ~5 MB scratch-based image, MIT licensed.

It’s probably not for you if you need: a web UI (try WUD), automatic pull-and-restart (that’s Watchtower’s job), non-Docker providers like Kubernetes/Podman (Diun covers more), or Slack/email as first-class notifiers.

It’s a young project - fewer battle-tested deployments than the established tools - so I’d genuinely welcome feedback from anyone who runs it.

GitHub: https://github.com/BlackRaincoat/versentry

AI Disclosure:

  • Design - Pair
  • Implementation - Generated
  • Testing - Assisted
  • Documentation - Generated
  • Review - Assisted
  • Deployment - Generated

Note: The idea, the architecture decisions, and all real-world testing were mine - I ran it across multiple live servers and that’s what caught the actual bugs. The AI wrote the implementation, the test code, docs, and CI config from my prompts. I reviewed behavior on real deployments rather than reading every line, so code-level review leaned on the AI.

  • squeeb@quokk.au
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    11 hours ago

    On face value it doesn’t look too different to dockcheck. What you’ve described (CLI, read-only, no auto updates, sends notifications via channel of your choosing) sounds exactly like how my dockcheck is set up. Were you aware of dockcheck and if so, how would you say your project differs?

    • BlackRaincoat@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      8 hours ago

      On face value it doesn’t look too different to dockcheck. What you’ve described (CLI, read-only, no auto updates, sends notifications via channel of your choosing) sounds exactly like how my dockcheck is set up. Were you aware of dockcheck and if so, how would you say your project differs?

      Honestly, no - I hadn’t come across dockcheck before now, so thanks for pointing it out. I didn’t do a big survey of what’s out there; I just had an itch (notify-only update checks across a few hosts, with a proxy, no auto-updating) and nothing I’d tried quite fit how I wanted it, so I ended up writing my own. Sounds like dockcheck lands in a similar space - I’ll take a look at how it does things. Not trying to claim mine’s better; different paths to the same problem.