​
When to rotate

Rotate immediately if:
  • The secret was pasted in a chat, commit, screenshot, or support ticket
  • You suspect a contractor / former employee has a copy
  • Your local password manager was compromised
  • You’re rotating on a policy schedule (quarterly is reasonable)
  • You see unexpected 429 / 402 activity in your dashboard
Rotation is free and instant. There is no cool-down, no penalty, and no downtime when done correctly.

​
Rotation via the dashboard

  1. Sign in at app.atlasvpn.live/developer.
  2. Find the key row. Click the 🔄 rotate icon.
  3. Confirm the “this will stop the current secret within 30 seconds” warning.
  4. Copy the new secret from the shown-once modal.
  5. Update your environment / secrets manager.
The keyId stays the same. Only the secret changes. So your proxy URL structure http://<keyId>:<secret>@api.atlasvpn.live:7777 only needs the secret portion updated.

​
Rotation via the API

curl -X POST https://api.atlasvpn.live/api/v1/proxy/keys/<id>/rotate \
     -H "Authorization: Bearer $SUPABASE_JWT"
Response: 
{
  "key": {
    "keyId": "avp_live_abc123...",    // unchanged
    "secret": "new64charhex...",       // new, shown ONCE
    "basicAuth": "avp_live_abc123...:new64charhex...",
    "rotatedAt": "2026-04-25T14:30:00Z"
  }
}

​
Zero-downtime rotation pattern

The gateway flushes the key-validator cache on rotate, so the OLD secret stops being accepted within milliseconds. If you have many production clients using the old secret, you need to update them all BEFORE rotating — otherwise they’ll 407 until they pick up the new secret. Recommended pattern:
  1. Add a second key in parallel: POST /api/v1/proxy/keys with label “prod-v2”.
  2. Deploy your app with the v2 credentials to a staging slot. Verify with a smoke test.
  3. Roll out v2 to production via your normal blue/green or canary process.
  4. Wait 15 minutes to confirm no clients are still using v1 (check lastUsedAt for the old key).
  5. Revoke the old key via DELETE /api/v1/proxy/keys/<v1-id>.
This is the same pattern Stripe / AWS / Twilio recommend for production secret rotation.

​
Emergency rotation (key leaked publicly)

If the secret is in a public GitHub commit, social media post, or equivalent:
  1. Rotate immediately at /developer. Don’t wait for a zero-downtime rollout.
  2. Accept the downtime — ~30 seconds of 407 while clients fail + you update their config.
  3. Review the proxy_usage_events log via GET /api/v1/proxy/usage/<keyId>/events to see if anyone used the leaked secret. Unusual target hosts = possible abuse.
  4. If abuse is confirmed, email security@atlasvpn.live — we can suspend specific abuse-flagged events in our audit trail.

​
Automating scheduled rotation

# scheduled-rotation.py — cron this monthly
import os
import requests
from supabase import create_client

sb = create_client(os.environ['SUPABASE_URL'], os.environ['SUPABASE_SERVICE_KEY'])
session = sb.auth.sign_in_with_password({
    'email': os.environ['AVP_BOT_EMAIL'],
    'password': os.environ['AVP_BOT_PASSWORD'],
})

r = requests.post(
    f"https://api.atlasvpn.live/api/v1/proxy/keys/{os.environ['AVP_KEY_ID']}/rotate",
    headers={'Authorization': f"Bearer {session.session.access_token}"},
)
new_secret = r.json()['key']['secret']

# Push the new secret to your secrets manager
# (AWS Secrets Manager / GCP Secret Manager / Vault / 1Password Connect)
update_secret_in_vault('AVP_SECRET', new_secret)

# Wait 60s for rolling restart, then confirm nothing still uses the old secret
Don’t commit the AVP_BOT_PASSWORD to source. Store it in the same secrets manager you’re rotating into — CI should pull it from there at rotation-cron time.