> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # Railway > Connect your Railway workspace to Oleria to discover members, roles, access groups, projects and environments, tokens and keys, secret variables and the audit log. Railway is a cloud platform for deploying applications, databases and services. Connect your Railway workspace to Oleria to see who can reach each project and environment, through which role, which tokens and keys can act on them, and what changed. ## What Oleria discovers Oleria reads one Railway workspace through the Railway public GraphQL API (`https://backboard.railway.com/graphql/v2`) on its [regular sync schedule](/integrations/overview.md#sync-model): * **Users** - workspace members with their workspace role (**Admin**, **Member** or **Deployer**), and collaborators outside the workspace who were invited to a single project. For each member, Oleria shows whether two-factor authentication is on and which methods are set up (authenticator app, passkey), whether your workspace requires 2FA, and whether SAML SSO is configured or enforced. Railway has no last-login field, so a member's last activity comes from their most recent audit-log event in the last 30 days. * **Roles** - the three workspace roles and who holds each. Each role's reach over every project is shown once, on the role. * **Groups** - Railway access groups, their members, and the project role each group grants on its projects. * **Resources** - projects and their environments, and who can reach each one: direct project members (with their **Owner**, **Editor** or **Viewer** role), access groups, collaborators outside the workspace, and everyone through workspace roles. Project Owners are shown as the project's owners. Public projects show anonymous read access. * **Non-human identities** - project tokens (scoped to one environment), Railway Authentication tokens (with their expiry and creator), the connecting user's own account and workspace tokens (when you connect with an account token), SSH keys (the workspace's, plus the connecting user's own when you connect with an account token), and bucket access keys. Each is linked to the person it authenticates as or who created it, when Railway records one. Workspace tokens are shown with the workspace **Admin** role, workspace SSH keys with access to every project, and bucket keys with access to their environment. * **Secrets** - sealed variables and variables whose names show they hold a secret (for example `DATABASE_URL` or `STRIPE_SECRET_KEY`), as credentials. Oleria reads variable **names** only and never requests or stores variable values. * **Activity** - the workspace audit log: member, role, access-group, SSO and 2FA changes, token and credential changes, project and environment changes, deployments, and shell, SSH and file access to running services. ## Prerequisites * A Railway workspace on the **Pro** plan or higher. Workspaces with other members, 2FA enforcement and 30-day audit logs need Pro. SSO, access groups, Environment RBAC and 18-month audit logs need a committed-spend plan. * A Railway user with the **Admin** workspace role, to create the token below. * Admin access on the Oleria platform to add a new integration. ### Permissions Railway tokens have no scopes: a token can do what its owner's workspace role allows, and a workspace token acts with workspace **Admin** rights. Oleria uses one token for discovery and remediation actions. | Needs | Used for | | :- | :- | | Workspace **Admin** (workspace token, or account token of an Admin) | Members and their 2FA status, roles, access groups, projects and their members, tokens and keys, the audit log, and every remediation action. When you connect, Oleria rejects a token whose user isn't an Admin. | | **Pro** plan | Workspaces with other members, 2FA enforcement, 30 days of audit log | | Committed-spend plan | SSO, access groups, Environment RBAC, 18 months of audit log. Without it, these parts are empty; that is not an error. | ## Choose a token | Token | When to use | | :- | :- | | **Workspace token** (recommended) | Scoped to one workspace and acts with workspace Admin rights. It isn't tied to a person, so it keeps working when people leave. | | **Account token** | Belongs to one Admin and reaches every workspace they belong to. Also lets Oleria inventory that person's own API tokens. Enter the Workspace ID when you use one. | Project tokens are not supported. They reach a single environment and can't read workspace members, roles or the audit log. ## Create the token in Railway **1. Open the token page** Signed in as a workspace Admin, go to **Account Settings** > **Tokens** (`railway.com/account/tokens`). **2. Create the token** Enter a name (for example, `oleria`). For a workspace token, select your workspace in the **Workspace** list. For an account token, select **No workspace**. Select **Create** and copy the token. **3. Find the Workspace ID (account tokens only)** Go to **Workspace Settings** > **General** and copy the workspace ID. ## Connect Railway to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations**, then select the **Railway** tile. **2. Complete the connection form** | Field | Notes | | :- | :- | | API token | Required. The workspace or account token you created. | | Workspace ID | Needed only when the token can reach more than one workspace (an account token). | When you edit the integration, leave the API token blank to keep the stored token. You can't change the Workspace ID; to connect a different workspace, add a new integration. **3. Save the integration** Select **Authenticate**. Oleria checks that the token works, selects the workspace, and reads it before saving the connection. ## Verify the integration Confirm the new instance appears on the **Connected** tab of your **Integrations** page with a status of **Healthy**. ## Remediation actions | Action | What it does | Revert | | :- | :- | :- | | Disable user | Removes the user from the Railway workspace. Railway has no way to suspend a member. | Yes, re-invites them with their previous role. Access returns when they accept the email invitation. | | Enable user | Re-invites a removed user as a **Member**. | No | | Add user to role | Changes a member's workspace role. A member who already holds that role or a higher one is left unchanged. | Yes, restores the previous role if nobody changed it since | | Remove user from role | Lowers a member's workspace role one level (Admin to Member, Member to Deployer). A member always holds one role, so to remove a Deployer, disable the user. | Yes | | Add user to group / Remove user from group | Adds or removes a workspace member in an access group. | Yes | | Create group | Creates an access group with the **Viewer** project role. A name already in use changes nothing. | Yes, deletes the group | | Revoke access to resource | Removes a user's direct access to a project. Access through a workspace role or an access group is refused with the reason. | Yes. Workspace members are re-added. Collaborators outside the workspace are re-invited. | | Revoke anonymous access | Makes a public project private. | Yes | | Remove external access | Removes a collaborator who isn't a workspace member from the project in the finding, or from every project they belong to when none is named. Workspace members are refused; disable them instead. If a removal fails partway, the action reports which projects are done and which remain; run it again to finish. | Yes, re-invites them to each project with their previous role | | Create user | Invites the email to the workspace as a **Member**. The account joins when the person accepts. An existing member changes nothing. | Yes, removes the person if they joined. A pending invitation stays, because Railway can't withdraw it. | | Disable NHI | Deletes a project token or SSH key, revokes a Railway Authentication token, or resets a bucket's S3 credentials. | No | Every action needs a workspace token or an account token of a workspace Admin. Oleria never removes, demotes or revokes the access of the user whose token the connection uses, never removes or demotes the workspace's only Admin, and never changes a project outside the connected workspace. ## Known limitations * Railway has no way to suspend a member, so every member shows as enabled. Railway accounts have no password, so the last password change is empty. * Railway has no per-member last-login field. Last activity comes from the newest audit-log events of the last 30 days, which only Admins and workspace tokens can read. The audit log keeps 48 hours on Free and Hobby, 30 days on Pro and 18 months on Enterprise. * When Railway's audit log doesn't identify who acted, the activity shows **Unattributed Railway actor**. Actions by Railway's platform and support staff show **Railway System** and **Railway Staff**. * Railway lists only the connecting user's own account and workspace tokens. With a workspace token, no API tokens are listed. * Oleria doesn't revoke account or workspace tokens: Railway can't tell which token the connection itself uses. Revoke them in Railway. * Resetting a bucket's S3 credentials replaces the secret access key; the Access Key ID stays the same, so the key keeps the same name in Oleria. Services that use the bucket keep the old secret until you redeploy them. * Railway doesn't record who created a project token or when any token was last used. * Railway doesn't show which environments are restricted through its API, so restricted environments appear like any other environment. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.