How to rotate app secrets vps no downtime

Rotating app secrets without downtime means replacing a database password, API key, or token while the old one still works, so your application never hits a moment where every credential it's using is suddenly invalid. This guide walks through doing that safely on a VPS, using the dual-secret method.

The core idea is simple: never revoke the old secret until you've confirmed the new one works in production. Skipping straight from "create new secret" to "delete old secret" is the most common cause of rotation-related outages.

Step 1: Generate the New Secret

Create the new credential without touching the old one yet. For a database password, this means adding a new password without removing the existing one. In MySQL:

ALTER USER 'appuser'@'%' IDENTIFIED BY 'new_secure_password';

Note that changing a user's password this way immediately invalidates the old one in MySQL. For a true zero-downtime rotation, create a second database user instead, so both remain valid at the same time:

CREATE USER 'appuser_new'@'%' IDENTIFIED BY 'new_secure_password';
GRANT ALL PRIVILEGES ON your_database.* TO 'appuser_new'@'%';
FLUSH PRIVILEGES;

For API keys or tokens, generate the new one through the provider's dashboard or API without revoking the old key.

Step 2: Add the New Secret Alongside the Old One

Update your environment configuration to include the new secret as a separate variable, keeping the old one in place:

DB_USER_OLD=appuser
DB_PASSWORD_OLD=old_password

DB_USER_NEW=appuser_new
DB_PASSWORD_NEW=new_secure_password

If your app reads secrets from a .env file, edit it directly on the VPS:

nano /path/to/your/app/.env

Step 3: Update the Application to Use the New Secret

Point your application's configuration at the new credential. Once the .env file is updated, restart the application so it picks up the change:

sudo systemctl restart your-app.service

If your app runs in Docker, recreate the container so it reloads the environment variables:

docker compose up -d --force-recreate

At this point, the old secret is still valid in the background, so if something goes wrong, you can roll back instantly by pointing the app back at the old credential.

Step 4: Verify the New Secret Works

Before removing the old credential, confirm the application is functioning correctly with the new one. Check that the service started without errors:

sudo systemctl status your-app.service

Review the application logs for authentication errors or connection failures:

sudo journalctl -u your-app.service -n 100

Also confirm core functionality manually, logins, key API calls, or database reads and writes, to make sure nothing is silently failing.

Step 5: Revoke the Old Secret

Only after confirming the new secret works reliably, remove the old one. For the MySQL example:

DROP USER 'appuser'@'%';

For API keys, revoke the old key through the provider's dashboard. Then clean up your environment file by removing the old variables:

DB_USER=appuser_new
DB_PASSWORD=new_secure_password

Restart the application one final time to confirm it still runs cleanly with only the new secret in place:

sudo systemctl restart your-app.service

Step 6: Watch for Delayed Failures

Some parts of an application can hold onto old credentials longer than expected, background workers, cron jobs, or cached connections that haven't refreshed yet. Keep an eye on logs for a short period after revoking the old secret:

sudo journalctl -u your-app.service -f

If an unexpected failure appears, having documented exactly what changed makes it far faster to diagnose and, if needed, briefly recreate the old credential while you investigate.

Rotating secrets this way keeps your Linux VPS secure without ever creating a window where the application has no valid credential to authenticate with.

The dual-secret approach turns rotation from a risky, all-or-nothing switch into a controlled, reversible process, keeping your app both secure and continuously available.