Rotate Fluxo Keys During a Kubernetes Rollout

Rotate the credential, not your running traffic

My rule for rotating API keys: prove the replacement works before touching the credential serving traffic. The sequence is overlap, validate, deploy, observe, revoke. Revoking first turns routine maintenance into an incident.

Fluxo gives your tools one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more. It works with Claude Code, Codex, Gemini CLI and any OpenAI SDK. This walkthrough rotates a Kubernetes application's Fluxo key; editor sessions and CLI processes need their own credential reloads afterward.

If you want to follow along, create a Fluxo account. Billing follows real tokens, including cache reads and writes, without a monthly fee; smoke tests still consume tokens. Invited users' payments also earn you a referral share, which is separate from credential management.

1. Check the deployment before creating another secret

Assume the current kubectl context targets the right cluster and namespace, your Deployment is named api, and its OpenAI SDK already uses https://api.fluxorelay.com/v1. The application must read OPENAI_API_KEY from its environment. Its readiness probe must reflect whether it can serve requests, and shutdown must drain in-flight work.

Run: kubectl config current-context — Run: kubectl get deployment api -o yaml

Configure overlapping pods: kubectl patch deployment api --type merge -p '{"spec":{"replicas":2,"minReadySeconds":10,"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'

Wait: kubectl rollout status deployment/api --timeout=180s — This requires capacity for a third pod. Zero unavailable pods does not guarantee zero failed requests: readiness, graceful termination, connection draining, and sufficient capacity all matter. Reconcile these settings with your deployment repository if GitOps manages this workload.

2. Validate the replacement key without exposing it in history

Create a second key in your signed-in Fluxo account without revoking the first. Confirm the account permits both keys to remain valid; without an overlap window, this procedure cannot guarantee uninterrupted access. Use Bash for the following commands, and keep shell tracing disabled.

Run: set +x; umask 077; ROTATION_DIR=$(mktemp -d); trap 'rm -rf "$ROTATION_DIR"; unset NEW_KEY' EXIT

Run: read -r -s -p 'Paste replacement Fluxo key: ' NEW_KEY; printf '\n'; printf '%s' "$NEW_KEY" > "$ROTATION_DIR/key"; printf 'Authorization: Bearer %s\n' "$NEW_KEY" > "$ROTATION_DIR/header"; unset NEW_KEY

Discover the actual model identifiers rather than guessing a slug: curl --fail-with-body --silent --show-error --max-time 30 -H @"$ROTATION_DIR/header" https://api.fluxorelay.com/v1/models | jq '.data[] | {id, name}'

Choose the returned identifier for Claude Sonnet 5.5, then run: read -r -p 'Model ID from the response: ' MODEL_ID

Run a small authenticated generation: jq -n --arg model "$MODEL_ID" '{model:$model,messages:[{role:"user",content:"Reply with OK."}],max_tokens:32}' | curl --fail-with-body --silent --show-error --max-time 60 -H @"$ROTATION_DIR/header" -H 'Content-Type: application/json' --data-binary @- https://api.fluxorelay.com/v1/chat/completions

Stop if either request fails. A model listing alone does not prove that generation succeeds.

3. Roll a versioned Kubernetes secret into new pods

Use a fresh secret name, preserving the previous secret for rollback. These commands require kubectl and jq locally.

Run: NEW_SECRET="fluxo-key-$(date -u +%Y%m%d%H%M%S)"; kubectl create secret generic "$NEW_SECRET" --from-file=OPENAI_API_KEY="$ROTATION_DIR/key"

Record the current revision: OLD_REVISION=$(kubectl get deployment api -o jsonpath='{.metadata.annotations.deployment\.kubernetes\.io/revision}')

Update the environment reference: kubectl set env deployment/api --from="secret/$NEW_SECRET" --keys=OPENAI_API_KEY

Watch replacement pods: kubectl rollout status deployment/api --timeout=300s

Old pods retain the old credential while new pods receive the replacement. Kubernetes does not refresh environment variables inside existing processes.

4. Exercise production traffic before revoking the old key

Send a normal application request that actually invokes Fluxo. Check application metrics for authentication failures, latency changes, and failed generations. Rollout completion proves pod readiness, not upstream authorization.

If verification fails, leave the old key active and run: kubectl rollout undo deployment/api --to-revision="$OLD_REVISION"

Then wait: kubectl rollout status deployment/api --timeout=300s

After successful verification, update every other consumer, including scheduled jobs and terminal sessions. Allow old requests to finish, then revoke the old key in Fluxo. Revocation closes the rollback window for that credential. Remove its Kubernetes secret only after confirming nothing references it, and delete the temporary files by exiting this shell.