Railyard

Security

How we protect Railyard and your data.

Overview

Security is built into Railyard rather than bolted on. This page describes the controls that are actually in place today — how the Service is protected, how we authenticate you without passwords, how we keep one organisation's data separate from another's, and how we handle logging and deletion. If you have a question we don't answer here, contact us at [email protected]. To report a vulnerability, use [email protected] — see Reporting a vulnerability at the end of this page.

This page is also Annex II to our Data Processing Agreement: it is the description of technical and organisational measures that Article 32 requires, and we keep it accurate for that reason rather than as marketing copy. Where we have not done something, this page says so.

Infrastructure and hosting

  • The hosted Service runs in the United Kingdom. Your account data and designs — the database and its encrypted backups — are stored there. The providers we use, and the safeguards for the limited data that leaves the UK, are listed on our sub-processors page.
  • Railyard is served over HTTPS in hosted environments, with TLS termination handled by the deployment's ingress or edge proxy.
  • The application is designed to run behind a reverse proxy or Kubernetes ingress, so the app server can stay inside the operator's private network.
  • Application data is stored in a PostgreSQL database. Encryption at rest depends on the host storage configuration, so we do not make a blanket at-rest guarantee. Contact our support address for the current hosted environment's storage controls.
  • Self-hosted and private deployments are available under a separate written agreement. Availability, hosting controls and support terms are agreed directly rather than assumed from the hosted service.

Authentication

  • Passwordless by design. There are no passwords to phish, guess or leak. You sign in either with a one-time sign-in code sent to your email, or through single sign-on (OIDC/OAuth with providers such as Google, GitHub or Okta). Single sign-on is available to any user whose provider we support; it is not a capability an organisation has to switch on, and it is not limited to a paid plan.
  • Credentials are stored hashed. Session identifiers and personal API-token secrets are never stored in plaintext; only their SHA-256 hashes are kept, so a read-only database exposure does not yield usable credentials. A six-digit email sign-in code is too short for a plain hash to protect, so it is stored as a keyed hash (HMAC-SHA-256) whose key is held by the application servers and never written to the database; codes also expire after 15 minutes and work once. API-token secrets are shown once, at creation, and never again.
  • Hardened session cookie. The session cookie is HttpOnly, Secure, set with SameSite=Lax and, on the hosted service, uses the __Host- prefix so no other site or subdomain can plant one. Sessions expire, and account settings lets you review and revoke browser sessions, or revoke every session, API token and connected AI app at once. A new API token or connected AI app is announced by email. Changing your email address or disconnecting a sign-in method signs out your other browsers.
  • API tokens are limited and expire. A personal API token acts as you for everyday API work — reading, designing and exporting the projects you can reach — so treat it like a password. Every token expires (after 90 days unless you choose another lifetime of up to a year) and can be revoked at any time. Owner-level, reviewer and irreversible actions need an interactive browser session and cannot be performed with a token: deleting your account; creating, renaming or deleting an organisation; deleting a project; listing, restoring or permanently deleting a recently deleted organisation or project; moving a project to another organisation; changing a project's sharing, visibility, version control or branch protection, or recovering access to it; pruning project history; reviewing, approving, merging or declining a merge request, or withdrawing someone else's; changing members, roles or invitations; accepting or declining an invitation; opening billing; and minting or revoking tokens. Finer-grained token scopes are planned.
  • SSO account-linking is verified-email gated. A new single sign-on identity only creates an account, or is linked to an existing one, when the provider reports the email address as verified (Google and Okta via their email_verified claim; GitHub by returning only addresses it has verified).
  • Abuse controls. Sign-in code requests are rate limited per email address and per source IP so an inbox cannot be spammed and a single source cannot blast many addresses.

Access control and tenant isolation

  • Access within an organisation is governed by role-based access control with three roles: owner, editor and viewer. Viewers are read-only; editors can change designs; owners additionally manage membership and billing.
  • Every request is authorised against the caller's membership and role in the specific organisation it targets, so one organisation cannot read or write another's data.
  • Role checks are enforced server-side, and plan checks are also enforced server-side when paid billing is enabled. A plan check only ever limits paid features and growth: a lapsed or downgraded plan never makes designs read-only or removes access to them.

Data protection in transit

  • Hosted traffic is encrypted in transit with TLS.
  • HTTP Strict Transport Security (HSTS) is enforced on HTTPS responses with a one-year max-age and includeSubDomains, so returning browsers refuse to connect over plain HTTP.
  • The app honours the trusted HTTPS signal from its ingress or reverse proxy, so session cookies keep their Secure flag when TLS is terminated before the app process.

Network and application hardening

The Service ships with a strict set of browser security headers applied by the app:

  • Content-Security-Policy — default-src 'self' with script-src 'self' (only the static structured-data block is hash-authorised, and no eval scripts are permitted), object-src 'none', frame-ancestors 'none', base-uri 'self', form-action 'self' and connect-src 'self' plus the app's own ws(s):// origin. img-src is limited to the app itself, data: and blob: URLs, and the Google and GitHub avatar hosts. style-src is 'self' 'unsafe-inline': the canvas positions racks, devices and cables with inline style attributes, so inline styles cannot be forbidden. We state that rather than implying a stricter policy than we have — scripts, which are what matter for code execution, remain origin-restricted with no unsafe-inline and no unsafe-eval. The single-page app is fully self-hosted and talks only to its own origin: there are no CDN scripts, remote fonts or third-party tags to compromise.
  • Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy — same-origin, isolating the app from other sites' windows and embeds.
  • Cache-Control: private, no-store on every API response, so account and design data is not kept in browser or shared caches.
  • X-Frame-Options: DENY and frame-ancestors 'none' — the app cannot be framed, preventing clickjacking.
  • X-Content-Type-Options: nosniff — blocks MIME-type sniffing.
  • Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage.
  • Permissions-Policy — geolocation, microphone, camera and payment browser features are disabled.
  • No application version banner. The app server does not advertise its software or version in response headers. The edge in front of it — our CDN and ingress proxy — sets its own Server header, which you will see on a live response; that identifies the edge, not the application or its version.
  • The edge must not weaken these headers. The security headers above are emitted by the application. Our deployment checks on every release that the edge has not replaced or relaxed them.

Privacy by design

  • No third-party trackers. Railyard includes no third-party analytics, advertising or cross-site tracking scripts.
  • Minimal cookies. We use a single strictly-necessary session cookie, plus a short-lived cookie used only during single sign-on. Interface preferences are stored locally in your browser and never sent to us.
  • Data minimisation. We collect only what the Service needs, and expired sign-in codes and sessions are pruned automatically.

See our Privacy Policy for the full detail on what we collect and why.

Billing security

The Community plan is free of charge. If you choose a paid plan, payments are processed by Stripe through hosted Checkout and Customer Portal pages, so we will not receive or store your full card number. One-off Project Pass purchases use the same hosted Checkout. We will hold only Stripe customer, subscription and Project Pass payment references and plan status, and verify incoming billing webhooks by signature before acting on them.

Audit logging

Significant account and organisation actions are recorded to an append-style audit log, capturing the actor, a timestamp, the action and the source IP address. This trail supports incident investigation and accountability, and is retained for up to one year before being deleted. Account deletion removes or pseudonymises identifying fields sooner.

Backups and recovery

  • The database is backed up and backups are encrypted and stored in the same jurisdiction as the Service. They exist to recover the Service after an infrastructure failure.
  • Backups are not a per-customer undo. We do not restore an individual organisation, project or document from a backup on request — a restore replays the whole database to a point in time, which would roll back every other customer too. The undo for a deleted organisation or project is its 30-day restore window in the Service (below), not a backup. Keep your own exported copies of anything you could not afford to lose; the raw Project JSON export is free and unlimited on every plan.
  • Deletions persist through backups. A deletion you make in the live Service is not undone by a backup: backups age out of retention, and if we ever restore the Service as a whole we re-apply erasures afterwards.
  • Retention period and restore rehearsal: to be published. We are documenting the hosted deployment's backup and point-in-time-recovery window and the date of our last rehearsed restore, and will state both here. Ask [email protected] for the current figures in the meantime. We would rather leave this blank than publish a number we have not verified.

Data deletion and portability

  • Export. You can export your design data from within the Service as the raw Project JSON, free on every plan, including after a paid plan ends. You can also download your account data from User settings. Terms §17 sets out what is exportable and for how long after your plan ends.
  • Deletion. Deleting your account is a hard delete from the live Service: your personal workspace and its projects are removed, along with your sessions, memberships, linked identities and API tokens, and personal data keyed to your email such as pending sign-in codes and invitations. A pseudonymised security and audit record may be retained for the remainder of its one-year retention period, then deleted. Copies in encrypted backups persist until those backups age out of retention, as described above.
  • Deleted organisations and projects can be restored for 30 days. Deleting an organisation or a project takes it away from everyone at once: it leaves every list, link and search, API, personal access token and MCP access, export and live editing, and anyone who has it open is told it was deleted. Its data is kept, unreachable, for 30 days. In that time an organisation's owners can restore it from Account settings › Data & deletion, and a project's administrators from Organisation settings › Recently deleted; restoring brings back its members, access settings, history, branches and field links as they were. After 30 days it is permanently deleted from the live Service, and an owner or administrator can delete it permanently sooner from the same list. Listing, restoring and permanently deleting are open only to a signed-in browser session, never a token.
  • Permanent deletion is not reversible. Once an organisation or project has been permanently deleted we cannot bring it back for you. Deleting your account permanently deletes, at once, any deleted organisation you alone own. Export anything you may need before deleting it permanently.

Compliance and standards

Our security practices are designed to align with recognised industry standards and the principles of UK GDPR. We do not currently claim formal certification against ISO 27001 or SOC 2.

Incident response

We have a named incident owner and a documented breach-response runbook. If we detect or are told about a personal data breach we assess it against the UK GDPR Article 33 criteria, report it to the Information Commissioner's Office within 72 hours where the threshold is met, and keep an internal breach register as Article 33(5) requires.

For data you control — your designs and the records around them — our Data Processing Agreement commits us to telling the affected organisation's owners within 48 hours of becoming aware, with what we know at the time and updates as we learn more. We do not wait for a complete picture before telling you.

Reporting a vulnerability

We welcome reports from security researchers and treat them as a priority.

  • Where to send it: [email protected]. This is a monitored mailbox for security reports only, kept separate from general support so a report is not queued behind product questions. Machine-readable contact details are published at /.well-known/security.txt.
  • What to include: enough detail to reproduce the issue — the affected URL or endpoint, the steps, and what you observed. Tell us if you believe customer data was exposed.
  • What we commit to: we acknowledge within 3 working days, give you an initial assessment within 10 working days, and keep you updated until the issue is resolved. We will tell you when a fix ships, and credit you if you would like to be credited.
  • Disclosure: please give us a reasonable opportunity to investigate and remediate — 90 days as a default — before any public disclosure, and talk to us if you need to move faster. We do not currently run a paid bug bounty.

Safe harbour. We will not pursue or support legal action against a researcher who acts in good faith under this policy: that means testing only against your own accounts and data, not accessing, modifying, exfiltrating or deleting data that is not yours, not degrading the Service for others (no denial-of-service, no mass automated scanning, no social engineering of our staff or customers), and reporting to us promptly rather than exploiting or disclosing what you find.