Hub
Monetization

Early 2024, Docker's multi-year bet on its security platform was falling short of expectations. The executive team made a decisive call: generate new revenue through Docker Hub by monetizing pull usage and storage. Hub was already carrying enormous load, roughly 5.5 PB of pulls daily from public repositories alone, plus around 21 PB of private repository storage. None of it was being directly monetized.

The initiative had three parts: Pulls to surface usage data, Storage to show consumption, and Image Management to give admins a way to clean house. The mandate from leadership was to ship fast.

The data told a clear story: only about 3% of Hub users would actually be affected, mostly large enterprise accounts managed directly by sales. The problem was that Docker wanted to surface this broadly, to all users, rather than targeting the accounts that actually mattered.

The team raised concerns. The direction held.

That left the other 97% as our real design problem. That's 26.6 million users. Would they understand they weren't affected? Or would it trigger panic? Hub had a history of user backlash when communication missed. Getting the messaging right wasn't a nice-to-have. It was the thing standing between a quiet rollout and a PR problem.

I started by facilitating a brainstorm between the Hub UX and Registry teams. We mapped every pain point a user or admin might hit when pull and storage metering went live, then dot-voted on the hairiest ones. We ran HMW exercises, grouped patterns into three buckets (Technical Challenges, Optimization and Cleanup, and Monitoring and Management), and used that to shape the MVP, a second release, and a longer backlog with leads from both teams.

The sequencing wasn't a preference. It was a dependency. Engineering estimates put pull metering readiness in October and storage in January, gated on the metadata store reaching production. Pulls had to come first because storage data wasn't reliable enough yet, even for internal use. That constraint shaped everything.

With Pulls leading, I made a deliberate call to treat it as the pattern-setting surface for the whole initiative. When we moved to Storage, the design direction was explicit: replicate what we built for Pulls so the experience would feel coherent across both pillars when they eventually landed together. I was designing consciously ahead of the data. As I put it at the time, "I attempted to lay this page out as how it would be for when we get the live data." Waiting for the metadata store wasn't an option.

To limit the blast radius of the initial release, we scoped it to org admins only. Before launch, I worked with Docker Captains, the DevRel team, and Marketing to pressure-test the messaging and shape the rollout campaign. One early discovery: the usage data was bucketed, not real-time, which made the "current usage" framing less accurate than we'd assumed. We adjusted.

The design goal for the next release was a dashboard where an admin could scan at a glance and know whether they were in the green or the red. I defined six pull-metering states, from No Usage through Surpassed Limit, mirroring the state model we'd built for Docker Build Cloud to create a more coherent product experience. Customer 0 sessions and Docker Captain feedback gave me a tight iteration loop. The designs were ready. Then Docker's pricing and packaging decisions stalled, and the release stalled with them.

The Miro working session I'd run earlier, with its pain-point mapping, competitive tooling research, and HMW outputs, mapped almost directly to the 13 problem statements that ended up in the Image Management PRD. The session did real work: storage doesn't shrink the way users expect because of shared layers, no ability to filter by last-pulled date, no audit trail for deletions, no undo. Those became the requirements.

We started with an assumption that turned out to be wrong: that deleting an image would free storage. It doesn't. Images are tied to index and manifest digests, and you have to delete the digest itself, not just the image. One digest can link to multiple images, so removing it can take out others you didn't intend to touch.

I spent several weeks working through this with the Registry engineers. I interrogated the model, designed through it, and shared each version back with both teams. What does an index digest's size actually represent? Does it absorb the tags from its manifests? I was writing out the mental model in notes to myself before I could design something that communicated it clearly: "Manifests can point to multiple indexes. A tag can only point to one manifest, but a manifest can have many tags." The PRD's engineering constraints landed directly from that collaboration. I was told later that the designs helped the engineers better conceptualize what they needed to build. That wasn't something I'd planned, but it mattered.

Then the pricing and packaging timeline slipped further. Storage enforcement was eventually pushed to January 2026 and pulls charging was in question. The mitigation the working team landed on was leaning harder into Image Management tooling as the near-term deliverable. That decision was made above me, but I was responsible for the design response. I absorbed the engineering-driven UX regression that had accumulated during the stall, pulled in earlier concepts rather than restarting, and pushed to protect runway on Docker Hardened Images, which I was now also carrying. The design goal stayed consistent: show admins what to delete and what that deletion would actually impact.