Encryption Key Rotation
Rotate the ENCRYPTION_KEY used for upstream credentials without downtime using the change-encryption-key CLI command.
Using an AI assistant? Give it this file.
/llms.md is a single Markdown file covering installation, configuration, quickstart, clients, upstreams, permissions, TLS, and production deployment. Copy it and paste it into your AI chat, or tell the AI to fetch https://drevnix.tech/llms.md.
Encryption Key Rotation
Upstream registry credentials are encrypted at rest using AES256-GCM with the ENCRYPTION_KEY you set at startup. If you need to rotate this key, for example as part of a periodic secret rotation policy or because the key was potentially compromised, use the change-encryption-key CLI command.
This command re-encrypts all stored upstream credentials under the new key. It does not require downtime.
How it works
- You provide the current key and the new key
- Drevnix reads each stored upstream credential, decrypts it with the current key, and re-encrypts it with the new key
- All credentials are updated atomically
- You update
ENCRYPTION_KEYin your environment to the new value and restart Drevnix
Performing a rotation
Step 1: Generate a new key:
openssl rand -hex 32
# Example output: a3f8c2d1e4b7...
Step 2: Run the rotation command:
docker exec -it drevnix java -jar /opt/drevnix.jar change-encryption-key --config=/etc/drevnix/config.edn
The command prints a confirmation when all credentials have been re-encrypted.
Step 3: Update your environment:
Update ENCRYPTION_KEY in your secrets manager or environment configuration to the new key value.
Step 4: Restart Drevnix:
docker restart drevnix
Drevnix now reads the new key from the environment and all stored credentials decrypt correctly.
Important notes
- Run the rotation command before updating
ENCRYPTION_KEYin the environment. If you change the environment variable first, Drevnix will fail to decrypt stored credentials on restart - If the rotation command fails partway through (e.g. database connection lost), re-run it. The command is idempotent and safe to retry
- Back up the current key before rotating, in case you need to roll back
- The proxy continues serving requests during rotation. There is no downtime
Key storage
Store ENCRYPTION_KEY in a proper secrets manager:
- AWS Secrets Manager / Parameter Store
- HashiCorp Vault
- GCP Secret Manager
- Azure Key Vault
Do not store it in a .env file, source control, or container environment variables that are logged or visible in orchestrator UIs.