How to determine Docker repository/image sizes and reclaimable disk space in Nexus Repository OSS 3.69.0-02?

Sonatype Nexus Repository
,
1

Title: How to determine Docker repository/image sizes and reclaimable disk space in Nexus Repository OSS 3.69.0-02?

Hi Sonatype Community,

We are using Sonatype Nexus Repository OSS 3.69.0-02 and have a Docker repository containing a large amount of data.

We would like to understand:

  1. Is there a way to get the total size of a specific Docker repository?

  2. Is there a way to identify which Docker images are consuming the most disk space?

  3. Can we determine the size consumed by each image/version/tag?

  4. Before deleting a Docker tag, is there a way to determine how much disk space will actually be freed by deleting that tag?

  5. Since Docker images can share layers, how can we identify the actual reclaimable space for a specific tag? For example, if a tag is deleted but its layers are still referenced by other images/tags, we understand that the full image size may not be freed.

  6. Is there any way to perform a dry run or generate a report showing:

    • Tag/image size

    • Shared layer size

    • Unique layer size

    • Estimated disk space that would be freed after deleting the tag

  7. Is there any supported REST API, script, database query, or built-in reporting option in Nexus Repository OSS 3.69.0-02 to retrieve this information?

For example, we would like to generate a report similar to:

Repository: docker-internal
Total size: XXX GB

Image                 Tag/Version     Image Size    Reclaimable Space
-----------------------------------------------------------------------
my-app                1.0.0           15 GB         10 GB
my-app                1.0.1           12 GB         2 GB
another-app           latest          8 GB          8 GB
...

Our goal is to identify the largest images/versions and, before deleting them, estimate how much actual disk space will be reclaimed, especially considering shared Docker layers and blob deduplication.

If anyone has implemented this for Nexus Repository OSS 3.69.0-02, please share the recommended or supported approach.

Thanks!