Summary

  • Pushing a new image under an existing tag updates the tag while leaving the previous image accessible by its digest and occupying DigitalOcean registry storage.
  • Untagged images count towards the storage quota. Removing a tag, deleting a manifest and collecting unreferenced layers deal with different objects.
  • Opt-in automatic garbage collection is in public preview and works without read-only downtime. Manual collection still includes a read-only phase and can wait up to 15 minutes before the collection itself begins.

The tidiest part of a software release can be its list of names. Yesterday's version disappears from the familiar tag, today's version takes over, and the deployment team closes its ticket. DigitalOcean's storage documentation supplies the less photogenic scene: yesterday's image can still be in the room.

The company's quickstart says that pushing an image with an existing tag updates that tag. The old image remains accessible by its digest and continues taking space in the registry. The name has moved. The contents have stayed behind, entirely within the documented arrangement.

Keeping them may be excellent business. A known working version can be useful after a bad deployment. A particular artifact may be needed for an investigation. An abandoned experiment can occupy space just as successfully. “Untagged” describes a technical condition; it does not appoint a curator for the company's software history.

One release, three claims of success

A tag gives people and deployment tools a convenient name. A digest identifies a particular version. Separating the two lets the everyday name advance while an exact reference to older material survives.

The trouble starts when a release report travels between departments. “We replaced the old version” becomes “we deleted the old version,” then reaches the budget as “we reduced storage.” The first statement can be true while the other two are still waiting for their evidence. One piece of completed work has collected three commendations.

DigitalOcean's pricing page explicitly counts untagged images towards storage quota. Its cleanup guide distinguishes the subsequent operations. Deleting a digest also removes its associated tags. Deleting a manifest may leave layers that no manifest references any longer. Garbage collection clears those unreferenced layers to free space.

A retained, untagged manifest can still reference its layers. Untagged and unreferenced therefore describe different inventories. Confusing them can give an automatic cleaner a job it was never assigned, or give a savings report credit for capacity that has not been recovered.

An old image with an identified recovery purpose is a deliberate expense. An old image nobody can explain is something closer to rent on institutional forgetfulness. The tag alone cannot tell the difference.

The cleaner has received a narrower brief

DigitalOcean now offers automatic garbage collection in public preview. Customers enrol and enable it. It continuously cleans unreferenced image layers in the background, without putting the registry into the read-only mode needed by manual collection.

That is a useful improvement. Storage housekeeping can consume less space in the release calendar. The published scope also matters: unreferenced layers. The service does not choose which historical versions the company intends to retain for a rollback or an investigation.

Manual collection offers a separate option to delete untagged manifests. That extra choice is where a decision about history meets the machinery of reclamation. Retiring a version and sweeping up material that nothing needs are different responsibilities, even when both appear under the pleasant heading of cleanup.

There are two ways to ask too much of automation. A team may expect every old image to disappear once the automatic feature is enabled, leaving referenced material to accumulate. Another may classify every untagged manifest as rubbish, although a colleague has recorded one of its digests as a recovery point. The first mistake preserves an ownerless expense. The second may retire an option somebody intended to keep.

A cleaner can follow references. It cannot infer the commercial value of the collection from the fact that a label has fallen off.

Ten registries share the cupboard

Professional allows up to ten registries, but storage is shared among them. Its included 100 GiB does not appear afresh in each registry. Dividing projects improves organisation; it does not reproduce the purchased allowance.

Published prices put Basic at $5 a month with 5 GiB and Professional at $20 with 100 GiB. Additional storage is charged at the end of the day and prorated according to the days of quota excess during the month. A saving consequently needs a measured amount of occupied capacity and a period of time.

Counting deleted tags supplies neither. Adding the apparent sizes of old images can also overstate what will be reclaimed, because other manifests may still reference shared layers. The financially useful number comes after retention decisions and actual collection: how much storage has been released?

Keeping selected versions can be a sensible purchase. Keeping every build indefinitely is a more ambitious policy, even if nobody ever approved it. The collection grows with the pace of development and the size of the artifacts. Finance may believe it is paying for a few considered fallback points while the team is quietly building a museum without a curator.

Fifteen minutes before the work starts

Manual garbage collection temporarily places the registry in read-only mode. Before collection begins, DigitalOcean waits for previous write authorisations to expire. Depending on when the last write operation started, that wait can take up to 15 minutes.

The interval belongs to the wait before collection. It supplies no completion deadline for the entire job. Teams using the manual path need to coordinate it with writes. The availability of an automatic preview also says nothing about whether a particular registry has actually enrolled; its enabled mode determines the operational arrangement.

Cancellation has an equally tangible boundary. The guide says the interface can report blobs already deleted and space already freed when collection is cancelled. Stopping the remaining work does not return material removed earlier. Versions that must survive need to be identified before destructive cleanup starts.

Another clock applies to unfinished uploads. With automatic collection enabled, image uploads that have not completed within 24 hours are treated as partial uploads, and their layers become eligible for collection. That is an eligibility rule, rather than an exact deletion appointment or a one-day lifetime for completed images.

Release records should therefore distinguish starting an upload from having an available version. An intention to preserve an artifact is weaker than the artifact itself. The distinction becomes expensive when somebody eventually needs to fetch what the record says is safely stored.

Give the remaining history an owner

RIPE NCC's primary membership record identifies DigitalOcean, LLC. DigitalOcean's own documents supply the product and pricing rules examined here. A particular customer's excess storage or savings would require its digest-level reference inventory, retention purposes and before-and-after storage measurements; those customer records are absent from this evidence.

The purchasing decision can still be stated plainly. Pay to retain useful history, authorise retirement of history that has served its purpose, and verify that the resulting spare material has actually been collected. Experiments, deployed versions and investigation artifacts may deserve different lives.

A well-run registry can contain plenty of old software. What makes it well run is the ability to explain why each version remains. Losing a label should confer neither an automatic death sentence nor a tenancy for life.

Primary sources