The root password
Generated at provision, emailed to you once, and stored encrypted. The account owner can read it on the server's page while signed in.
That means anyone with access to your portal account can read the root password of every server on it. Two consequences:
- Put a second factor on the portal account.
- Change the password after first login and rely on SSH keys instead.
passwd
Changing it in the guest does not update the portal's copy. That is fine and expected: the stored value becomes a stale artefact of provisioning.
API keys
The secret half of a Client API key is shown once, at creation, and stored only as a one-way digest. Nobody, including support, can recover it. Lost it means revoke and mint a new one.
An API key can deploy servers that spend your credit and destroy servers that hold your data. Treat it as a password:
- Environment variable or secret store, never in source control
- Never in browser JavaScript or a mobile app, where it is readable
- One key per integration, so revoking one does not break the others
- Read-only scope wherever a write is not needed
Never send a secret in a ticket or in chat
Support does not need your root password or your API key, and a ticket thread is not a secure channel. If you have already pasted one, rotate it.
There is a mechanism for the rare case where a credential genuinely has to be handed over: staff can attach one to a ticket in a store that purges itself after 14 days. Ask rather than pasting.
If something leaked
| Leaked | Do this |
|---|---|
| API key | Revoke it under Developer, mint a new one |
| Root password | passwd on the server, and check ~/.ssh/authorized_keys |
| Portal password | Change it, then revoke other sessions under Account |
| Anything, and you see odd activity | If a server is compromised |