How SrvYard keeps your servers and credentials safe
How SrvYard protects sign-in, credentials and your servers, where platform data is stored (UK and EU), which optional features use other companies, and how to report a vulnerability.
- Sign-in
- Two-factor, passkeys, optional social sign-in
- Secrets
- Encrypted at rest, one-time hand-off
- Access
- 5 roles, 102 permissions, audit log
- Servers
- Own key per server, firewall on, no root login
- Data
- Platform data in the UK and EU
- Report
- [email protected]
Your data stays in the UK and EU
SrvYard platform data (accounts, organisation data, deployment logs and backups of the platform) is stored in UK and EU data centres. Your servers and their data live wherever you choose to create them, in your own cloud account.
A few optional features send data to other companies. Which ones, and what leaves the UK and EU.
SrvYard can log in to your servers, deploy your code and talk to your cloud provider, so it holds secrets that matter. This page says what it does with them, in plain terms. It describes how the product behaves; it is not a certification or an audit report, and it says where responsibility passes to you.
Authentication
| Control | How it works |
|---|---|
| Two-factor | Any authenticator app (time-based codes). It is turned on only after you have entered a working code, and you get recovery codes for a lost phone. An owner can require it for every member: a member without it can open only their security settings until they turn it on. |
| Passkeys | WebAuthn sign-in with a fingerprint, face scan or device PIN, so there is no password to phish. Add one per device and remove lost ones from the list. |
| Social sign-in | GitHub, Google, GitLab or Apple, optional. You can disconnect a provider only while another way in remains. |
| Sessions | Every signed-in browser is listed with its IP address and last activity, and can be ended. The sign-in history records successes and failures, including attempts for your email address that never reached your account. |
| Throttling | Sign-in is limited to five attempts a minute, and the Security page asks for your password again after three hours. |
Details: Turn on two-factor authentication and manage your sessions.
Secrets and credentials
| What | How |
|---|---|
| Account passwords | Hashed, never stored in a readable form. |
| API tokens | Only a hash is stored. The token is shown once when you create it; the list shows the prefix and last four characters. |
Server SSH keys, cloud provider and DNS tokens, Git host credentials, storage keys, backup passphrases, .env files, database user passwords, certificate private keys, webhook secrets, notification channel settings |
Encrypted at rest. Decrypted only inside the job that needs them. The dashboard shows a hint, never the value. |
| Generated credentials | The sudo password and the database administrator passwords that SrvYard generates on a server are handed over through a one-time download. The stored copy is encrypted, expires after 24 hours by default and is emptied by the first download. |
| Webhook signing secrets | Shown when you save the webhook and again after a rotation, with a 24-hour grace period for the receiver. |
| Logs | Command and deployment output is scrubbed as it is written: values SrvYard knows are secret are masked before the line is stored, including across two chunks. A secret your own script prints in a form SrvYard does not recognise can still appear, so do not print secrets. |
Encryption at rest protects a leaked database, not a compromised application server. If you miss a one-time credential you regenerate it; nobody can read a lost token back to you. SrvYard generates a key pair for each server: the private key is encrypted, used only inside the job that connects, and never sent to your browser.
Access control
| Control | How it works |
|---|---|
| Roles | Five built-in roles (Owner, Admin, Manager, Developer, Viewer) over 102 permissions. Custom roles and teams are on the Business plan. |
| Teams | Owners and admins see everything; other members see what their teams share plus what they created. |
| API token scopes | Scopes come from the same permission list and a token can never exceed the role of the member who created it. |
| Isolation | Every record belongs to one organisation. A request for another organisation's record answers as if it did not exist. |
| Audit log | Sensitive changes are written with the member, the time and the address. A change made with an API token carries token:<name>. The activity feed on each server and site keeps 14 days and is available through the API if you want to keep it longer. |
| Staff access | A staff action done on your behalf carries the staff member's name. The staff panel is separate from customer accounts. The software's defaults are two-factor for every staff member, sessions that end after 30 minutes idle or 8 hours in total, an optional IP allow-list, and impersonation that starts read-only and ends by itself after 60 minutes. These are configuration defaults of the software, not a statement about the settings of a particular installation. |
Details: Least privilege and auditing.
Server access
| Control | How it works |
|---|---|
| SSH keys | A separate key pair per server, generated by SrvYard. After the first setup SrvYard connects as its own srvyard user, not as root. |
| Management user | srvyard can run commands as root through sudo, so treat the right to manage a server as root-equivalent and keep the number of owners and admins small. |
| Firewall defaults | Provisioning sets ufw to deny incoming traffic except SSH, HTTP and HTTPS. SrvYard keeps SSH open however you edit rules and restores the previous firewall if a new one fails. |
| SSH hardening | Password logins off, root by key only, unattended security upgrades, and a web server that gives no answer to a name that is not one of your sites. |
| Host key changes | SrvYard notices when a server's SSH host key changes, reports it and does not connect until you reset the trusted key. |
See the hardening checklist. You choose the provider and the machines, so the operating system, the software you add and the data in your sites are yours. Removing a connection in SrvYard does not revoke its token at the provider: revoke it there too.
Network and application
| Control | How it works |
|---|---|
| Transport | The console is served over HTTPS with HSTS in production. |
| Response headers | X-Content-Type-Options, X-Frame-Options: DENY, a strict referrer policy, a restrictive permissions policy and Cross-Origin-Opener-Policy. |
| Content Security Policy | Sent in report-only mode while it is tightened. It is not enforced yet. |
| Rate limiting | API tokens are limited to 60 requests a minute, and heavier operations (scans, exports, bulk actions) to 10 a minute. Sign-in, two-factor, passkeys, registration and password resets have their own limits. |
| Webhook signing | Outgoing webhooks carry X-SrvYard-Signature, an HMAC-SHA256 of the timestamp and the raw body with your signing secret. Verify it before you trust a request. |
| API tokens | Bearer tokens bound to one organisation, with scopes, and a token loses its powers if its owner is removed. |
Data residency
Your data stays in the UK and EU. SrvYard platform data (accounts, organisation data, deployment logs, and backups of the platform) is stored in UK and EU data centres. Servers and their data live wherever you choose to provision them, in your own cloud account.
Sub-processors and what leaves the UK and EU
Most of SrvYard sends nothing to other companies. These are the optional or supporting services that do, and what each receives. The same list, with the legal terms, is in Annex III of the Data Processing Agreement.
| Service | What it receives | Where | Used when |
|---|---|---|---|
| Anthropic | The end of a failed deployment's output with secrets removed (never environment values), for AI deployment explanations. The text of questions you type into the support chat. | United States | Only if you switch on Explain failed deployments with AI (Business plan, an organisation setting), or use the chat. |
| OpenAI | Documentation text and your documentation search query, turned into vectors for search. No account or server data. | United States | Documentation search. Search falls back to keywords without it. |
| Stripe | Billing details and payments. SrvYard shows a summary of the payment method and invoices, never a full card number. | United Kingdom, EEA and United States | Paid plans. |
| Cloudflare | The name of a free subdomain and the public IP of your server, as a DNS record. | Global network | Only if you use a free subdomain. |
| iDrive e2 | Documentation and website images and media. No customer data. | Object storage | Always, for images. |
| Email delivery provider | Your address and the content of emails SrvYard sends you (such as sign-in links and notifications). | A provider with data centres in the UK or EU | Always. |
| Platform hosting provider | Everything the platform stores. | A hosting provider with data centres in the UK or EU | Always. |
The deployment explanation is the only AI feature that you can switch off for an organisation; the chat assistant and documentation search are part of the documentation site and are used only when you use them. Servers you create at a cloud provider, and what you back up to your own storage, are not SrvYard platform data: they are in the provider and region you chose. Transfers to the United States use the UK and EU contractual safeguards described in the Privacy Policy.
Disclosure
If you find a vulnerability, please tell us before you tell anyone else, and give us a reasonable time to fix it.
- Send a report through the contact form (choose Security report) or email [email protected]. Do not include secrets, and do not attach other people's data.
- Say what you found, where, and the steps to reproduce it. A proof of concept that does not touch other customers' data is enough.
- We will reply to the report and tell you what we decide.
- Please do not access data that is not yours, degrade the service, or run automated scans against other customers' servers.
Machine-readable contact details are in security.txt.
Security FAQ
Answers checked against the code
Where is my data stored?
SrvYard platform data (accounts, organisation data, deployment logs, backups of the platform) is stored in UK and EU data centres. Your servers and their data live in the cloud account and region you chose. A few optional features use other companies; the sub-processor list says which.
Does SrvYard send my environment variables or secrets to an AI provider?
No. If AI deployment explanations are on (Business plan, an organisation setting), the end of a failed deployment's output is sent with secrets removed, and environment values are never sent. If it is off, nothing is sent for that feature.
Can you read my API token or generated password if I lose it?
No. API tokens are stored as a hash, and generated server passwords are emptied after their first download. You regenerate a lost one.
What happens if the SrvYard database leaks?
Stored credentials (SSH keys, provider tokens, .env files and similar) are encrypted at rest with the application's key, and passwords and API tokens are hashed. Encryption at rest does not help if the application server itself is compromised, which is why tokens should be least-privilege and rotated.
Can SrvYard run commands on my server as root?
Yes, through its own srvyard user with sudo. That is how it installs and updates software. Treat the right to manage a server as root-equivalent and keep the number of owners and admins small.
Does staff impersonation exist, and would I see it?
The software has it: it starts read-only and ends by itself after 60 minutes by default, and an action done on your behalf carries the staff member's name in the audit record.
Is the Content Security Policy enforced?
Not yet. It is sent in report-only mode while it is tightened.
Do you have a security certification?
No. This page describes how the product behaves; it is not a certification or an audit report.
Questions about security? Ask before you connect a server.
Free: 1 server, 3 sites, 100 deploys a month. Read the docs first if you prefer.