> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Registry encryption

> Control the key used for new layers without changing existing image references.

Layers are encrypted at rest. The default uses a platform-managed key. You can
select an enabled symmetric KMS encryption key in the same account and region.
The setting is account-wide because repositories share deduplicated layers.

Read `GET /v1/encryption-configuration`. A customer-managed configuration returns
`encryption_type: kms` and `kms_key` as a resource reference containing its ID,
CRN, and name. A deleted key retains its ID and CRN without a name; the binding
never silently falls back to platform encryption.

Replace the configuration with `PUT /v1/encryption-configuration`:

```json theme={null}
{"encryption_type":"kms","kms_key":"registry-key"}
```

`kms_key` accepts a UUID, account-scoped name, or CRN. The service checks that the
key can wrap a layer key before saving the selection. For platform encryption,
use `{"encryption_type":"platform_managed"}` and omit `kms_key`.

Changing this setting applies to newly stored layers. Existing layers retain
the key that encrypted them, including when deduplication reuses those layers
in a later push. Keep old keys available for as long as their layers are needed.
Disabling or deleting an old key can make those images unreadable.

Deleting the configuration requires the account to have no retained registry
data. Inspect `/v1/encryption-configuration/retained-data` when decommissioning
registry storage. Configuration changes require
`registry:PutEncryptionConfiguration`; reading requires
`registry:GetEncryptionConfiguration`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.