Rotate Region server key

Region server keys can be rotated when the key may be leaked, employees leave, the service architecture changes, or the enterprise's regular security policy requires rotation.

Check before rotation

Confirm before rotation:

• You can modify the environment variables of all related services under the Region.
• Apps, services, and tasks using old keys have been found.
• Prepared deployment plans for test, production and disaster recovery environments.
• Confirmed that key rotation does not conflict with releases, migrations, or sales spikes.
• The team responsible for backend configuration has been notified.

The rotation operation will affect applications using old keys in the same Region. Other Regions are not affected.

Initiate rotation

1. Enter the Server Key page.
2. Find the key card of the target Region.
3. Click Rotate Key.
4. View the list of affected apps.
5. Enter the confirmation text required by the page, for example ROTATE or “confirm rotation.”
6. Check the confirmation item that you are ready to update all server environment variables.
7. Click Confirm Rotation.

This is a high risk operation. Please check the Region and application lists carefully before confirming to avoid accidentally rotating keys in other regions.

Illustration: Rotating server key confirmation

hours transition period

After successful rotation:

• The new key takes effect immediately.
• Old keys can still be recalled during the 48-hour grace period.
• After the grace period, the old key automatically expires.
• During the rotation period, the rotation of the same Region cannot be initiated again.

48 hours is a migration window, not a long period of time when old keys can be retained. It is recommended to complete all server configuration updates as soon as possible.

Update applications in the same region

Update in the following order:

1. Save the new key to the key management system.
2. Update the test environment variables and redeploy.
3. Call the Server API to verify the test environment.
4. Update the production environment and disaster recovery environment variables.
5. Restart or roll out services using the old key one by one.
6. Check the call log to confirm that the request used the new key.
7. Before the grace period ends, confirm that the old key is no longer recalled.

Don’t send new keys in clear text to unwanted people via chat, email, or tickets.

Illustration: The new server key is generated successfully

Confirm that the old key is no longer in use

Before the grace period ends, check:

• Whether the server-side API success rate is normal.
• Whether there are still old version services or scheduled tasks calling old keys.
• Whether there is a disaster recovery or staging environment that has not been updated.
• Whether authentication requests related to the old key still appear in the log.

If it is found that the old key is still in use, priority is given to updating the corresponding service instead of rotating the new key again.