Automatic Credential Rotation: The Security Work Nobody Markets
Imagine an API key for your hosting platform is leaked — exposed in a git commit, a logged error, a phishing email reply. It happens. What happens next depends almost entirely on how old that key is.
If the key is current, an attacker can use it right now. They can access your server, your database credentials, your files. If the key is stale — already rotated out — it doesn't work. The damage window closed when the rotation happened.
That's the entire argument for credential rotation. It's not complicated. It just requires discipline.
What gets rotated, and how often
On SrvBot, platform credentials rotate automatically every 30 days. This includes the agent tokens that authenticate between our platform components and your server environment. The rotation happens without any action from you and without any downtime.
Thirty days is a balance. Rotate too frequently and you add operational complexity with diminishing returns. Rotate too infrequently and the window for a compromised credential stays open longer than it should. Monthly rotation is a common standard in security-conscious environments.
The rotation is automatic, not scheduled-reminder-based. The distinction matters: scheduled reminders produce rotation when someone remembers to act on them. Automatic rotation produces rotation regardless of what else is happening. On a hosting platform with dozens of customer environments, "remember to rotate" is not an operational model.
Blast radius reduction
Credential rotation doesn't prevent every attack — it limits the damage when something goes wrong. Security professionals call this blast radius reduction.
If a token is compromised on day 1 of a 30-day rotation cycle, an attacker has at most 30 days before that token stops working. If the compromise is discovered before the next rotation, the token can be revoked immediately. The rotation doesn't replace incident response — it limits what's at stake while incident response is happening.
Compare that to a token with no rotation policy. A credential leaked in a forgotten git commit from two years ago is still valid. The exposure window is indefinite.
This is why rotation matters at the platform level, not just the application level. If your hosting platform's agent credentials never rotate, a one-time compromise becomes a permanent foothold.
What most hosts do
Most managed hosting providers don't rotate credentials automatically. Not because it's technically difficult — rotation is a solved problem. Because it's invisible work that doesn't appear in a marketing comparison table.
When you evaluate a hosting provider, you compare uptime, price, support tiers, included features. Nobody asks "what is your credential rotation policy?" Because of that, most hosts have no rotation policy to speak of. The credentials provisioned when your account was created are the credentials that will exist indefinitely.
We built rotation in because it's the right operational baseline, not because customers were asking for it. That's the category of work we think a managed host should be doing automatically.
SSRF and platform isolation
Credential rotation works in combination with other isolation measures. One we've built explicitly is blocking server-side request forgery (SSRF) to cloud metadata endpoints.
On cloud-hosted infrastructure, every server can reach the cloud provider's internal metadata API — the endpoint that returns instance credentials, configuration, and secrets. An SSRF vulnerability in a customer application could, without protection, reach that endpoint and return platform-level credentials.
We block those requests at the platform layer. A compromised customer application can't reach internal metadata endpoints. Combined with credential rotation, a compromise in one environment doesn't become a foothold across the platform.
The boring work
None of this appears in a headline feature comparison. Credential rotation and SSRF protection aren't things you see in a product demo. They're the operational baseline that determines whether your hosting environment is genuinely secure or just marketed as secure.
The work most hosts skip is exactly the work that matters when something goes wrong. We'd rather do it quietly and reliably than make it a headline we haven't earned.
Read more about how we approach platform security at /security.