Features and capabilities
Filesystem, S3, cleanup, and storage transfer
Verified scope for storing, cleaning, archiving, and transferring artifact content.
Storage model
Metadata and audit records live in PostgreSQL; artifact content lives in the selected filesystem or S3-compatible storage component.
Lifecycle
- Manual or cron-based cleanup
- Dry run, archiving, progress, and failure records
- Repository-locked storage transfer
- Recovery by re-upload
Integrity and ownership
The backend creates storage object keys under repository ownership; clients do not choose keys directly. Artifact metadata tracks checksum, size, state, and storage reference in PostgreSQL. A file present only in storage is not served as an ACTIVE artifact.
Cleanup behavior
A cleanup policy combines repository or repository-type scope with retention, match or exclude, and keep-last rules. Dry run reports targets without changing them; real execution produces item-level results plus lifecycle, audit, and operation evidence.
- With archiving disabled, verify metadata and active-object deletion together.
- With archiving enabled, the object moves to the archive namespace and is not served by the active package endpoint.
- Recovery uses normal publish or upload to re-upload content rather than directly reactivating archive metadata.
Storage-transfer behavior
Transfer streams between Local or S3 storage components while preserving the repository-owned key. The storage reference is not updated until size and SHA-256 verification succeeds; source-repository writes are locked during the operation and durable task progress is recorded.
Operational boundaries
A filesystem or bucket backup alone is not a consistent restore. PostgreSQL metadata and relevant raw SBOM or data scope must be planned at the same recovery point. Because a public coordinated backup and restore runbook is not complete, the production procedure must be established with the organization's own acceptance evidence.