SSO and an audit log, without an enterprise sales call
Single sign-on gets treated as an enterprise-tier feature on most platforms, gated behind a sales conversation and a price that assumes a few hundred seats. Most teams that actually want it are small — a handful of engineers who’d rather not maintain a separate password for the one tool that can restart production.
Setting it up
Settings → Single sign-on, admins only. Both of the common cases are supported directly, not just one with the other bolted on later:
OpenID Connect — Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak, or any other OIDC provider:
- Create an OpenID Connect web app in your identity provider, using the redirect URI the page shows you.
- Fill in the Issuer URL, Client ID, Client secret, and the email domain this applies to.
- Pick the role new people join as — viewer, deployer, or admin.
- Optionally require SSO for that domain, which turns off password login for it entirely.
SAML 2.0 — pick it on the same page, paste the identity provider’s sign-in URL and certificate, and Railyard shows the ACS URL, entity ID and SP metadata to hand to Okta, Entra, OneLogin, JumpCloud or ADFS. Responses get checked for signature, audience, time and request ID — not just accepted because they parsed.
Before anyone can actually sign in through either method, the domain has to be verified with a TXT record (_railyard-sso.<domain>) — SSO never signs into a site operator account or an account outside the team, and two-factor is still required even for people coming through SSO.
SCIM, once SSO is saved
Point your identity provider’s SCIM 2.0 app at https://app.railyard.run/scim/v2 with a generated bearer token, and team membership stops being a manual step: assigning someone in the identity provider adds them to the team, deactivating them removes them. Owners are never removed this way — that one role stays a deliberate, human action.
The audit log, and what it actually covers
Activity in the sidebar records deploys, variable changes, member changes, approvals, and data jobs — filterable by member, app, kind and date range, exportable as CSV. Variable changes show who changed which name and when, never the value itself, so the log is useful without becoming a second place secrets leak from.
The part worth knowing: actions a Railyard operator takes on your own team — changing limits, suspending, reinstating — land in this same log, not a separate one only we can see. If something was done to your team, you can see it the same way you’d see anything your own members did.
The score that tells you if any of this is actually on
Settings → Security checks ten things and scores the team 0–100: two-factor on every member, admins who haven’t signed in for 90 days, servers with pending security updates, EOL operating systems, open ports, certificate expiry, backup verification, unprotected stagings, and API tokens with no expiry. Each failing check links straight to its fix, so “we have a security score” doesn’t just sit at the bottom of a settings page unread.
Full reference: Teams, SSO and access.