Cup

Docker container update monitoring, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: A lightweight, self-hosted CLI and web dashboard that checks which of your running Docker containers have image updates available — nothing more, nothing less [1][2].
• Who it’s for: Homelab operators, indie developers, and small DevOps teams managing 10–100+ containers who want a fast, low-overhead way to know when updates exist without burning Docker Hub rate limits [1][2].
• Cost savings: Cup is free (AGPL-3.0). The main alternative, What’s up Docker?, is also free, but Cup was explicitly built to solve the rate limit exhaustion problem that WUD causes [2]. There’s no SaaS tier and no pricing to compare.
• Key strength: Written in Rust, profiled aggressively — 3.7 seconds to check 58 images on a Raspberry Pi 5. The binary is 5.4 MB. No 100 MB container image required [1][2].
• Key weakness: Cup is intentionally pull-based. It does not automatically trigger deployments, send alerts, or act on updates. You retrieve the data; Cup doesn’t push it [1]. Also, a prominent NOTICE in the README warns of significant development changes — read that before betting Cup on a production setup [1].

---

What is Cup

Cup is a single-binary utility that connects to your Docker socket, reads your running containers’ image tags, queries the relevant registries, and tells you which images have newer versions available. You get a clean web UI, a CLI, and JSON output for anything you want to wire up yourself [1][2].

That’s the whole thing. It’s not a deployment tool. It’s not a container manager. It’s not Watchtower, which auto-updates containers behind your back. It’s specifically the tool you run when you want to know that nginx:1.25.3 is out of date without having to log into every registry and check manually [2].

The author’s stated reason for building it: What’s up Docker? would reliably exhaust Docker Hub rate limits. Cup was designed from the ground up to be polite to registries — checking images efficiently without hammering pull-count APIs [2]. With Docker Hub tightening pull limits for unauthenticated users in 2024, that original motivation has only gotten more relevant [1].

As of this review, Cup has 1,260 GitHub stars and is licensed under AGPL-3.0 [1]. It’s a solo-developer project with a small Discord community, not a YC-backed company, so expectations about support velocity should be calibrated accordingly.

---

Why People Choose It

Independent third-party reviews of Cup specifically don’t exist yet — the project is small enough that the tech press hasn’t covered it. What follows is based on the project’s own documentation and README, with the usual caveat that self-reported advantages deserve skepticism [1][2].

The pitch is simple and the problem is real. If you run a homelab or a small production setup with 30–50 containers, you’ll periodically want to know what’s stale. The options before tools like Cup were: manually checking each image on Docker Hub, running something heavyweight like Portainer, or using What’s up Docker? and accepting that it would occasionally lock you out of Docker Hub pulls for six hours.

The specific README claim: “I feel that this feature [rate limit awareness] is especially relevant now with Docker Hub reducing its pull limits for unauthenticated users” [1]. That’s an honest framing of the problem. It’s also the differentiator that shows up first in the docs.

The Rust choice is meaningful here. The binary is 5.4 MB [1][2]. Competing tools typically ship as Docker images themselves — pulling 100+ MB to run something that checks container updates is a bit absurd. Cup avoids that entirely: you download the binary or pull a minimal container, and you’re done.

The speed benchmark — 58 images in 3.7 seconds on a Raspberry Pi 5 — is plausible given the Rust implementation and parallel registry queries [1]. No independent verification is available, but Rust + async concurrency is exactly the architecture you’d use to max out network I/O on a registry API.

---

Features

Based on the README and documentation [1][2]:

Core checking:

• Queries Docker Hub, ghcr.io, Quay.io, lscr.io (LinuxServer), and Gitea and its forks [1][2]
• Checks all running containers’ image tags against registry latest versions [2]
• Respects rate limits — the original design constraint [1][2]
• Supports insecure registries (self-signed TLS, local Harbor instances) [2]

Interfaces:

• Web UI with light and dark mode [1][2]
• CLI for terminal-native workflows [1][2]
• JSON output from both, suitable for piping into other tools [1][2]
• REST API (/api/v3/json) for programmatic polling [2]

Deployment modes:

• Standalone binary (no Docker required) [1][2]
• Docker container (minimal image) [2]
• Agent mode: run Cup on remote hosts, aggregate results through a central instance [2]

Configuration options:

• Authentication (access control on the web UI) [2]
• Automatic refresh interval [2]
• Ignore specific registries, update types, or individual images [2]
• Include/exclude image filters [2]
• Custom Docker socket path [2]
• Multiple server support (one UI, many Cup instances) [2]

Integrations:

• Webhooks (you configure these; Cup exposes the data) [1]
• Home Assistant integration (community-maintained) [2]
• Homepage widget (community-maintained) [2]
• Any tool that can hit an HTTP endpoint or parse JSON [1]

What it deliberately doesn’t do:

• Auto-update containers [1]
• Directly trigger webhooks on a schedule — you need a cronjob or external scheduler to poll Cup periodically [1]
• Provide a hosted/SaaS version

---

Pricing: No SaaS, Just a Binary

There’s nothing to compare here in the Zapier-vs-self-hosted sense. Cup doesn’t have a cloud tier. It’s AGPL-3.0 software you run yourself [1].

The real cost question is time: how much effort is setup and ongoing maintenance? The binary install path is documented as a one-command download from the GitHub releases page. Docker Compose setup exists in the community resources section [2]. There’s no database to provision, no Redis cluster to manage.

Self-hosted costs:

• Software: $0 [1]
• Compute: trivially low — Cup is stateless and runs checks on-demand. A $4/mo VPS or a Raspberry Pi runs it without issue [1]
• Your time to set it up: under 30 minutes for anyone who’s deployed a Docker container before

For context on the problem it solves:

• Without Cup or a similar tool: manual update checking across n registries, or risk running stale containers with known CVEs
• With commercial registry tools (like Docker Hub Teams): $9–$15/user/month for features you mostly don’t need
• With Portainer Business: $5/node/month with features that go far beyond update checking

Cup sits in the “free tool that does one job well” category. There’s no pricing pressure, no tier lock, and no vendor to raise rates on you.

---

Deployment Reality Check

The README’s install documentation is minimal by design — the project is simple enough that minimal docs work [1][2].

What you actually need:

• A host running Docker (Linux, likely; Windows/Mac possible but not the primary target)
• Access to the Docker socket (/var/run/docker.sock or a custom socket path)
• A network connection to reach the registries you use
• Optional: a reverse proxy for HTTPS on the web UI

CLI install path: Download the binary from GitHub Releases, chmod +x, run cup check. That’s it for the one-shot check use case.

Server mode: Run the binary or container with server flags, configure a reverse proxy (Caddy or nginx), optionally set up authentication. Community Docker Compose examples exist in the docs [2].

What can go sideways:

First and most important: the README opens with a prominent notice — “There have been some important changes regarding Cup’s development.” — linking to a NOTICE.md file [1]. The contents of that file weren’t captured in the data available for this review, but any project that opens its README with an important development notice warrants reading that notice before adopting the tool. This could be anything from a license change to a change in maintenance status to a breaking architectural change. Check it [1].

Second, Cup is a solo-developer project. The GitHub issues list is the support channel; the Discord exists for community questions [1]. If you hit a registry-specific bug on, say, a private Harbor instance, you’re filing an issue and waiting — not calling support.

Third, the AGPL-3.0 license matters if you’re thinking about embedding Cup in a commercial product or SaaS. AGPL requires that modifications to the source be published if you distribute the software or run it as a network service for others. For personal homelab use, irrelevant. For a startup wanting to resell container monitoring, check with your lawyer [1].

---

Pros and Cons

Pros

• Rate-limit-aware by design. This was the founding constraint, not an afterthought. Cup queries registries efficiently and won’t get your IP throttled by Docker Hub [1][2].
• Tiny footprint. 5.4 MB binary written in Rust. No runtime dependencies, no database, no external services required [1][2].
• Genuinely fast. 3.7 seconds for 58 images on Raspberry Pi 5 hardware [1][2]. Concurrency is built into the design.
• Multiple server aggregation. Run Cup on several hosts, view everything through one web interface [2]. This is useful for homelab setups with multiple machines.
• JSON-first output. Both the CLI and the REST API return structured JSON, which means any integration is possible if you’re willing to write a small script or use a webhook receiver [1][2].
• No auto-update behavior. If you’ve been burned by Watchtower silently pulling a breaking image version at 3am, Cup’s pull-based model is a feature, not a bug [1].
• Community integrations for Home Assistant and Homepage widget — the projects homelab operators actually use [2].

Cons

• Development status warning. The README’s opening notice about “important changes regarding Cup’s development” is unspecified and raises uncertainty [1]. This alone warrants caution before adopting Cup for anything production-critical.
• Solo developer. 1,260 stars is respectable, but it’s not a funded company. Long-term maintenance is a single-point-of-failure risk [1].
• No automatic notifications. Cup won’t email you, Slack you, or page you when an update appears. You have to poll the API yourself or run cup check on a cron [1][2]. If you want that behavior, What’s up Docker? or Diun are closer fits.
• AGPL-3.0, not MIT. The license is more restrictive than MIT for anyone thinking about commercial use [1].
• No digest pinning or vulnerability scanning. Cup tells you when a newer image tag exists. It doesn’t tell you if your current image has a CVE, and it doesn’t track image digests to detect tag mutations [1][2].
• Limited registry support compared to alternatives. Docker Hub, ghcr.io, Quay, lscr.io, and Gitea are covered. Custom private registries using different auth schemes may require workarounds [1][2].
• No multi-user access control. Authentication exists for the web UI, but it’s single-credential, not RBAC [2].

---

Who Should Use This / Who Shouldn’t

Use Cup if:

• You run a homelab or small VPS setup with 10–100 containers and want a lightweight dashboard to track stale images.
• Docker Hub rate limits have already burned you with another tool, particularly What’s up Docker?.
• You want JSON output you can pipe into a custom script, Home Assistant automation, or Homepage widget.
• You’re running Cup on constrained hardware (Raspberry Pi, old mini-PC) where binary size and memory overhead actually matter.
• You want a read-only update checker and explicitly don’t want anything automatically touching your containers.

Skip it (use What’s up Docker? instead) if:

• You want automatic push notifications — email, Slack, Telegram — when updates are available without writing your own integration.
• You need triggering of update actions directly from the tool.
• You want a single tool that handles both detection and notification in a GUI-configurable way.

Skip it (use Diun instead) if:

• Your primary workflow is watching specific images — not running containers — and you want notification-first design.
• You prefer a tool with more explicit multi-notifier support out of the box.

Skip it (use Portainer instead) if:

• You need full container lifecycle management: deploy, restart, logs, update — not just update detection.
• Team access control and audit logging matter to you.

Don’t use it if:

• The development notice in the README is a blocker you can’t resolve by reading NOTICE.md and making peace with whatever it says [1].
• You need a supported, commercially-backed tool with an SLA.

---

Alternatives Worth Considering

• What’s up Docker? (WUD) — the project that inspired Cup. More feature-complete: built-in notifiers (email, Slack, Webhooks, Gotify), supports auto-triggering. The trade-off: known to exhaust Docker Hub rate limits under load, which is why Cup exists [1][2].
• Diun — another lightweight Go binary for Docker image update notifications. Notification-focused with 20+ notifier backends, Docker Hub rate limit awareness, and active maintenance. Closer to WUD than Cup in philosophy.
• Portainer — a full container management platform. Update detection is one feature among many. Community Edition is free; Business is $5/node/month. More than most homelabs need.
• Watchtower — auto-updates containers without asking. If you want that, Watchtower. If you don’t want that (most people in production don’t), it’s not relevant here.
• Renovate / Dependabot — if the update tracking problem is really about your docker-compose.yml or Kubernetes manifests in a git repo, automated PR-based tools like Renovate are a better fit than runtime checkers.

---

Bottom Line

Cup is a Rust binary that does one thing well: tells you which of your running containers have image updates available, without hammering registry APIs in the process. For homelab operators who’ve been burned by rate-limit exhaustion from heavier tools, or who just want a clean dashboard without a 150 MB container image to run it, Cup is the most efficient answer currently available.

The honest caveats: it’s a solo-developer project with a development-status warning in the README that deserves investigation before you commit [1]. It’s intentionally passive — no alerts, no triggers, no automation — which is the right design for some users and a deal-breaker for others. And AGPL-3.0 closes some commercial doors that MIT would leave open.

For the target use case — a developer or small ops team wanting a fast, lightweight, read-only view of container update status — nothing in the alternatives list beats Cup’s binary size and speed at this price point ($0). Just read NOTICE.md first.

If deploying this kind of infrastructure is the blocker, upready.dev handles that for clients as a one-time setup.

---

Sources

1. Cup — GitHub Repository (sergi0g/cup, 1,260 stars, AGPL-3.0). https://github.com/sergi0g/cup
2. Cup — Official Website and Documentation. https://cup.sergi0g.dev / https://cup.sergi0g.dev/docs