What SrvYard stores about you and how secrets are protected
SrvYard can log in to your servers, deploy your code, talk to your cloud provider and send your backups to a bucket. To do that it has to keep some secrets. This article says plainly which ones, how each is protected, what you can see in the dashboard and what you never can, so you can judge the trade-off for your own team.
It is written for the person who has to answer "where does our key go?" in a security review. It describes behaviour that is visible in the product and its documentation; it is not a certification, and it says where responsibility passes to you.
Before you begin
- Know the two kinds of protection. Some values are hashed: SrvYard keeps only a one-way fingerprint, so it cannot read the value back, only check it. Others are encrypted: SrvYard needs the value to work (an SSH key to log in), so it stores it encrypted with the application's key and decrypts it only inside the job that uses it.
- Know what you can do about it. Rotation, revocation and deletion are in your hands. The related articles show how.
Encryption at rest protects a leaked database, not a compromised application server. Treat the credentials you give SrvYard like any other account with access to your servers: give each the least permission it needs and rotate it.
1. What is hashed: you can check it, not read it
| What | Protection |
|---|---|
| Your account password | Hashed. It is never stored in a form that can be read back. |
| API tokens | Only a hash of the token is stored. The full token is shown once, in the dialog after you create it, and cannot be recovered. |
Because of this, nobody at SrvYard can tell you a lost token or password. You create a new one.
- The hint. A token appears as
srv_and its last four characters. That is enough to recognise it and not enough to use it.
2. What is encrypted: needed to work, never shown again
These secrets are stored encrypted and decrypted only when a job needs them:
- SSH keys of your servers. SrvYard generates a key pair for each server. The private key is encrypted and used only inside the job that connects. It is never sent to your browser.
- Cloud provider tokens (the token of your hosting account) and DNS integration tokens.
- Git host credentials, deploy keys and the access tokens of connected GitHub, GitLab and Bitbucket accounts.
- Storage provider keys for backups (access key, secret key and the other fields) and backup passphrases.
- Site secrets: the
.envfile, Composer and npm credentials, basic-auth credentials, monitoring tokens. - Database user passwords, server Redis and search keys, certificate private keys, daemon environment values and the signing secrets and addresses of webhooks.
- Notification channel settings, such as a Slack webhook address.
The dashboard treats them accordingly: you see a hint, never the value.
- Access key. Only
••••and four characters. The secret key is not displayed at all. - Verified. SrvYard checks the credentials when you save them, and again later, and tells you if the provider rejects them.
Provider connections behave the same way.
- Access. The kind of credential in use, here Token.
- Needs reconnecting. A provider that rejected its credentials. You replace the token; the old one is not shown to you.
If you replace or delete a credential, the old value is gone from SrvYard. It still exists at the provider, so revoke it there too.
3. What is shown only once
Some secrets are generated for you and displayed in the response that creates them, then never again:
- The API token after you create it.
- The webhook signing secret after you save the webhook, and again after a rotation. A webhook table keeps only a short hint.
- New database passwords and similar generated values, where the product generates them.
Copy them into your own secret store at that moment. If you did not, rotate or regenerate: that is by design, and it is why the dialogs carry a warning.
Public keys are different, because they are meant to be shared. A server's page shows SrvYard's public key and the key the server uses to pull your repositories, so you can add them to a git host.
- SrvYard's public key. If it is ever removed from the machine, you put it back from the provider's console.
- The server's own key. Add it as a deploy key where your repository lives.
4. What SrvYard does not store
- Your card number in the dashboard. Billing shows the plan, the payment method summary and the invoices, never a full card number. See Change your plan, update payment details, invoices.
- Terminal keystrokes. Web terminal input is not recorded.
- Secrets in logs. Command and deployment output is scrubbed as it is written: values that SrvYard knows are secret (passwords, tokens,
.envvalues it was told about, deploy keys) are masked before the line is stored, including when a value is split across two chunks of output. A secret that your own script prints in a form SrvYard does not recognise can still appear, so do not print secrets. Server logs are visible to every member who can view the server. - Environment values in AI explanations. If Explain failed deployments with AI is on, the end of a failed deployment's output is sent for analysis with secrets removed, and environment values are never sent. The switch is in the organisation's general settings.
5. Where else it matters
- Sign-in. Passwords are checked against hashes; two-factor, passkeys and a sign-in history are available. See Turn on two-factor authentication and manage your sessions.
- The servers. SrvYard logs in as its own user with its own key and can run commands as root through it. Treat the ability to manage a server as root-equivalent. See Hardening checklist.
- Isolation between organisations. Every record belongs to one organisation, and a request for another organisation's record answers as if it did not exist.
- Transport. SrvYard serves HTTPS with HSTS in production, and security headers on every page.
- Retention. Webhook deliveries are kept for 30 days, the activity feed for 14 days, and deployment history and logs according to your plan.
6. Removing your data
- A credential: delete the provider, storage provider, token or integration. It is removed from SrvYard immediately.
- A server: deleting it removes it and its key from SrvYard. You can choose whether the machine at the provider is kept.
- Your account: the profile page can export your data and delete the account. See Cancel, export data and delete the organisation for what happens to an organisation.
Troubleshooting
- I need to see an API token I lost. It cannot be shown again. Create a new one and revoke the old. See Rotate tokens and review the sign-in log.
- A provider says "Needs reconnecting". The token was revoked or expired at the provider. Create a new token there and reconnect.
- A secret appears in a deployment log. Revoke or rotate that secret now, then stop your script printing it.
- Can SrvYard staff read my
.env? The value is encrypted at rest. Ask support about your organisation's requirements for administrative access. - A webhook secret was committed to a repository. Use Rotate secret in the webhook's menu and update your receiver within the 24-hour grace period.
Related
- Rotate tokens and review the sign-in log: keep the secrets you create short-lived.
- Least privilege and auditing: who in your team can touch what.
- Add an S3-compatible storage provider: the keys SrvYard keeps for backups.
- Add a server provider and its API token: the token SrvYard keeps for your cloud account.