On this page
01
What you'll set up
Keys age, people move on, and secrets leak. In about eight minutes you will set a rotation routine for every kind of key and learn the order for an emergency.
- A list of what can be rotated and how
- A calendar routine for each
- An incident order for a suspected leak
- A quarterly review
02
What can be rotated
Four kinds of secret are involved. Each has its own control.
| Secret | Where | Rotate | Revoke |
|---|---|---|---|
| Provider credential | Provider Credentials card | Rotate with a replacement key | Revoke |
| Virtual key | Virtual Keys card | Rotate issues a new secret | Revoke |
| Telemetry key | Telemetry Keys card | Create a new key, then revoke the old | Revoke |
| Edge token | Edge Instances card | Register again, then revoke the old | Revoke |
| Access token | Organization settings → Personal Access Tokens | Create a new token, then revoke the old | Revoke |
03
Rotate a provider credential
Provider credentials rotate without touching your apps.
- 1
Create the replacement at the provider
Keep the old key live.
- 2
Choose Rotate in Cloptima
Enter the replacement key.
- 3
Test
Confirm the credential passes.
- 4
Delete the old key at the provider
Last.
04
Rotate a virtual key
A virtual key's old secret stops working as soon as you rotate, so order matters.
1Open your secret manager
Ready to store the new secret
2Rotate the key
Copy the new secret
3Store and deploy
Update the app
4Confirm traffic
Check the Explorer
For a key that must never fail, create a second key with the same labels, move the app to it, then revoke the first. There is no gap that way.
05
Telemetry keys and edge tokens
These do not rotate in place. Create the replacement first.
- 1
Create the new key or register the edge again
Copy the new secret or token.
- 2
Switch the SDK or the edge to it
Redeploy.
- 3
Check that data flows
Usage events and heartbeats arrive.
- 4
Revoke the old one
It stops working at once.
06
If you suspect a leak
Work from the widest exposure to the narrowest. Cut off first, investigate after.
- 1
Revoke the exposed virtual key
Requests with it stop at once.
- 2
Rotate or revoke the provider credential if it was exposed
Revoke makes bound requests fail, so you notice.
- 3
Revoke the telemetry key or edge token if exposed
Then replace them.
- 4
Check the Explorer for the key
Group by Virtual Key and look at the hours around the exposure.
- 5
Open the Audit tab
Review changes made around the same time.
- 6
Replace and redeploy
Create the new key with the same labels.
07
Set expiries
A key that expires cannot be forgotten.
| Key | A reasonable lifetime |
|---|---|
| Virtual key for a production app | 90 to 365 days, rotated on a schedule |
| Virtual key for a pilot | 30 days |
| Telemetry key | 365 days |
| Access token for a person or script | As short as you can manage |
The console starts virtual keys at 3,650 days. Choose a shorter lifetime when you create the key.
08
What revoking affects
Know the reach of each revoke before you press it.
| You revoke | Stops | Leaves alone |
|---|---|---|
| A virtual key | Requests from the apps that use that key | Other keys, credentials, and policies |
| A provider credential | Requests bound to it, and its provider for model-name choice | Virtual keys, which can use another credential |
| A telemetry key | Usage events sent with it | Gateway traffic |
| An edge token | That edge instance's connection to Cloptima | Your provider keys, which never left your hosts |
09
A rotation calendar
Put the dates where a person will see them.
| When | What |
|---|---|
| Monthly | Read the Virtual Key grouping in the Explorer; revoke keys with no use |
| Quarterly | Test All credentials; review who may create keys and tokens |
| Every 90 to 365 days | Rotate production virtual keys |
| When a provider asks, and once a year at least | Rotate provider credentials |
| When a person with access leaves | Rotate what they could see, and revoke their tokens |
10
Rotation as code
Virtual keys can be managed in Terraform. Changing a key's lifetime replaces the key, which mints a new secret, so a rotation is a reviewed change.
resource "cloptima_llm_virtual_key" "support_chatbot" {
name = "support-chatbot-prod"
expires_in_days = 180
team_id = "support"
app_id = "support-chatbot"
environment = "production"
lifecycle {
create_before_destroy = true
}
}create_before_destroy issues the new key first, so you can store its secret and deploy before the old one is retired. The secret is a sensitive output; write it to your secret manager and nowhere else.
11
A quarterly review
A short routine keeps the list honest.
- 1
List active keys
Open each card and read the last-used time.
- 2
Revoke the unused
Anything with no recent use is a risk.
- 3
Check labels
Every key has a team and an app.
- 4
Retest credentials
Use Test All.
12
If something goes wrong
Most surprises come from order.
| What you see | Likely cause | Fix |
|---|---|---|
| An app fails right after a rotation | The old secret was retired before the app had the new one | Update the app, or create a second key next time |
| Requests are refused after a revoke | The key or credential was revoked on purpose | Create a replacement and update the app |
| A credential test fails after a rotation | The replacement key lacks access | Fix the key at the provider and rotate again |