Repositories
Repository Settings
Repository Display Name and Description
You can change the display name or description of a repository at any time.
The repository display name is just a descriptive value and is not the repository slug/identifier. Changing the repository display name will not affect configurations used by client programs or other users.
For information about changing the repository slug/identifier, see Potentially Dangerous Actions.
Note
When changing or modifying repository settings, you must click the Update settings button to apply your changes.
Repository Privileges
Repository privileges let you configure which permissions are required to perform actions on a repository.
You assign a permission level to a team or user when you grant them access to a repository. After that, you can use the repository privileges to set precisely which actions that permission level can perform. For more information about granting access to a repository, see Access Control.
Example:
If you want a team to only be able to see or use entitlement tokens, then you could set the permission level required for See/Use entitlements to Read, and all other actions to Write or higher.
In the repository Access control settings, you would then set the team to have only Read permissions on the repository. As a result, they would be able to see and use entitlement tokens, but would not have permission to perform any other repository actions.
User/Self Privileges
Note
These settings override the repository privilege level setting.
User entitlements enabled
If checked, users can use and manage their own user-specific entitlement token for the repository (if the repository is a private repository).
If not checked, user-specific entitlement tokens are disabled for all users.
Scan / Copy / Move / Delete / Resync
If checked, users with Write access to the repository can scan, copy, move, delete, and resync packages that they have uploaded.
Miscellaneous Settings
Use/configure noarch packages
If checked, noarch packages (if supported) are enabled in installations/configurations. A noarch package is one that is not tied to specific system architecture (like i686).
Serve index for generic packages
Lists all available generic packages in the repository through an index.
Serve index for raw packages
If checked, HTML and JSON indexes will be generated that list all available raw packages in the repository.
Use/configure source packages
If checked, source packages (if supported) are enabled in installations/configurations. A source package is one that contains source code rather than built binaries.
Display generated GPG signatures for the raw package index?
If checked, the HTML and JSON indexes will display raw package GPG signatures alongside the index packages.
Index package file contents
If checked, files contained in packages will be indexed, which increases the synchronization time required for packages. It is recommended that you keep this setting enabled unless the synchronization time is significantly impacted.
Replace packages by default
If checked, uploaded packages will overwrite/replace any others with the same attributes (e.g. version) by default. This only applies if the user has the required privilege for republishing AND has the required privilege to delete packages that they do not own.
Docker auth refresh
If checked, refresh tokens will be issued in addition to access tokens for Docker authentication. This allows unlimited extension of the lifetime of access tokens.
Use Debian repository labels
If checked, a Label field will be present in Debian-based repositories. It will contain a string that identifies the entitlement token used to authenticate the repository, in the form of source=t-<identifier>, or source=none if no token was used. You can use this to help with pinning.
Scan for vulnerabilities
If checked, vulnerability scanning will be enabled for all supported packages within this repository.
Contextual authentication realm
If checked, missing credentials for this repository where basic authentication is required shall present an enriched value in the 'WWW-Authenticate' header containing the namespace and repository. This can be useful for tools such as sbt, where the authentication realm is used to distinguish and disambiguate credentials.
Use crates.io as default Cargo upstream
If checked, dependencies of uploaded Cargo crates which do not set an explicit value for registry will be assumed to be available from crates.io. If unchecked, dependencies with unspecified registry values will be assumed to be available in the registry being uploaded to.
Uncheck this if you want to ensure that dependencies are only ever installed from Cloudsmith unless explicitly specified as belonging to another registry.
Strict npm validation
If checked, npm packages will be validated strictly to ensure that they match the specification. You can turn this on if you want to guarantee that the packages will work correctly with npm-cli and other tools.
Apply "Latest" tag for pre-release versions
If checked, packages pushed with a pre-release component on that version will be marked with the latest tag. If unchecked, a repository containing ONLY pre-release versions will have no version marked latest, which may result in incompatibility with native tools.
NuGet native signing
When enabled, all pushed (or pulled from upstream) NuGet packages and artifacts will be signed using the repository's X.509 RSA certificate. Additionally, the NuGet RepositorySignature index will list all of the repository's signing certificates, including those from configured upstreams.
Cosign signing
When enabled, all pushed (or pulled from upstream) OCI packages and artifacts will be signed using cosign with the repository's ECDSA key. This generates a distinct cosign signature artifact per artifact.
NPM upstream tags take precedence
If checked, npm distribution tags from configured upstreams will take precedence over matching local tags when fetching natively. When upstream and local repositories have the same tag name, such as latest, the upstream tag is used instead of the local one, even if the local repository has a semantically higher version.
Custom GPG Signing Key
You can specify a custom GPG key for signing repository metadata and packages. We will automatically derive the public key and fingerprint for any custom GPG key specified.
If your custom GPG key is encrypted, please also provide the passphrase for it.
Custom RSA Signing Key
You can specify a custom RSA key for signing repository metadata and packages. We will automatically derive the public key and fingerprint for any custom RSA key specified. The private key must be in PKCS8 format.
If your custom RSA key is encrypted, please also provide the passphrase for it.
Note
Adding a custom GPG or RSA key will take effect immediately, but will not affect any existing packages that were signed with the previous key. Packages signed with the previous key will still be available and the previous key can still be fetched.
Potentially Dangerous Actions
Potentially dangerous actions
The actions in this section are reversible, but may have broader impacts.
For example, renaming a repository slug/identifier will impact configurations that use the original slug/identifier. Transferring a repository to a new storage region may affect region-specific compliance requirements.
Exercise caution before making changes here.
Start broadcasting
Broadcasting a repository creates a public page where users can browse, search, and download repository packages. You can customize the branding of the page and control which package information to display. Broadcasting doesn't make any changes to your repository, and can be changed or turned off at any point.
For more information, see Broadcasts.
Rename repository slug/identifier
The repository slug/identifier is what clients and users see in the URI when connecting to a repository. Renaming the slug/identifier will immediately impact any existing clients/users.
The slug/identifier rename occurs immediately, but you can rename it back if you change your mind.
Transfer repository to a new storage region
Transferring a repository to a new storage region will move all packages and files to a storage location in the selected region.
During the transfer, you will be unable to upload any new packages or change existing ones. Downloads will continue to work normally.
Note
Storage in the non-default region is available only to users on Ultra and Enterprise plans.
Dangerous Actions
Dangerous actions
Actions in this section may result in data loss.
A repository deletion is irreversible and will prevent existing users from accessing the repository. Before performing a repository deletion, confirm the potential user impact and any communication required.
Deleted packages can be restored within 7 days of deletion. You can restore deleted packages from the Recently deleted packages section on the Deleted tab of the repository.
For more information, see Recently Deleted Packages.
Important
You cannot reuse a repository slug within 24 hours of deleting a repository.
