Retention Policies for Packages and Builds

Retention policies help manage package storage, build data, and repository growth over time.

By removing, archiving, or relocating older artifacts, retention workflows help maintain repository performance, reduce unnecessary storage usage, and limit long-term exposure to outdated or deprecated components.

Both Sonatype and ProGet support retention policies, but they differ in how cleanup workflows, deleted data, and build retention are managed.

This article covers:

• package and feed retention workflows
• build and SCA retention management

Package and Feed Retention

Sonatype Nexus Repository uses scheduled cleanup and retention tasks to manage older or unused components.

Components marked for deletion are first soft-deleted before being permanently removed during later cleanup operations. During this process, deleted components may still occupy storage until cleanup tasks complete.

Retention workflows are managed through scheduled cleanup policies that automatically enforce repository retention rules.

ProGet supports similar package retention capabilities while using a more direct file-based cleanup model.

Retention policies can be configured using criteria such as:

• package age
• disk usage
• version count
• feed-specific retention rules

ProGet also supports dry-run retention workflows, allowing administrators to validate retention behavior before applying permanent changes.

Instead of relying on soft deletion workflows, ProGet can automatically relocate older package data to lower-cost storage tiers while maintaining package accessibility when needed.

Build and SCA Retention

In Sonatype Lifecycle environments, deleted scan and analysis data may remain within temporary retention or trash workflows before final removal occurs.

Because cleanup operations may occur separately from deletion events, storage recovery timing can become less predictable, particularly when managing older scan results, reports, and historical build data.

ProGet manages build and SCA retention through pipeline-based workflows.

Rather than relying primarily on age-based deletion policies, ProGet allows retention decisions to align with build stages and release workflows. This allows organizations to:

• retain important archived or production builds
• remove temporary CI or intermediate builds
• manage SCA and compliance history more selectively

This approach provides more granular operational control over how build, dependency, and compliance data are retained across environments.

Retention and Recovery Workflows

When retention policies remove data in ProGet, storage is reclaimed immediately rather than delayed through soft-deletion or trash-based workflows.

If recovery is required, retained backup data can still be restored through standard backup and package restoration workflows.

Because ProGet stores packages and build artifacts using readable file-based storage structures, retained and restored data remains easier to verify and manage operationally.

Conclusion 

Both Sonatype and ProGet provide retention workflows designed to manage long-term repository growth and storage usage.

While the overall goals remain similar, ProGet combines file-based storage, pipeline-oriented retention, and centralized governance workflows to provide more direct visibility into package, build, and compliance retention behavior.

To help synchronize packages and artifacts across environments after retention and storage workflows are established, the next article covers replication and feed synchronization in ProGet.