Skip to content
Craftifact

Repository lifecycle

How repositories are created, deactivated, reactivated, cleaned up, and affected by storage changes.

Create repositories

Repositories are declared in the instance configuration, not created from a separate UI wizard.

The normal flow is:

  1. Add a repository entry under repositories in Effective configuration.
  2. Save and deploy the config.
  3. Use the repository in Craftifact.

Supported repository families are maven, python, npm, oci, and go beta, each with hosted, proxy, and group variants.

Remove repositories safely

Removing a repository from config does not delete its data immediately. On the next config apply, the repository becomes inactive.

Inactive means:

  • It is no longer part of the active config.
  • Reads and writes are blocked.
  • It appears in the Cleanup tab so you can decide what to do next.

In Cleanup, first fetch the inactive lists. Then either:

  • copy a restore snippet if you want to reactivate the repository later, or
  • delete the inactive repository permanently.
Rationale: why removal becomes inactive first
Making a repository inactive is a safer default than immediate deletion. It gives you a review step before binary data is actually removed.

Reactivate repositories

If you want a repository back, paste the restore snippet from Cleanup into Effective configuration and deploy again. That is also the normal follow-up after repository imports: imported repositories are created in Craftifact first, but they stay inactive until you add them to YAML.

Changing storage or type

Two important limits apply here:

  • Changing a repository’s storage backend does not migrate existing data automatically.
  • Changing an existing repository to a different package type in place is not supported.

Treat storage changes as a fresh-start operation unless you have a separate migration plan. If the existing repository contents matter, do not assume that editing storage alone will move them.

Practical notes

  • Proxy and group repositories are effectively read-only.
  • Repository quotas can be defined per repository, but group repositories cannot have quotas.
  • Sum of repository quotas cannot exceed the instance total quota.