SSO for GitHub Actions Runner Access

Answer

WarpBuild supports single sign-on through SAML 2.0 and OIDC on enterprise plans, for a flat $250 per month whatever the user count. Provisioning runs through support, and everything after that is self-serve: support sends a one-time setup link, your identity provider admin configures the connection from that link without a WarpBuild login, and your team then signs in by entering your tenant name on the WarpBuild login page.

SSO governs human access to the WarpBuild account, which is the dashboard where runners, BYOC stacks, usage, and billing live. Job execution is untouched. A workflow that runs on warp-ubuntu-latest-x64-4x before the rollout runs on the same label after it, because the runner registers with GitHub through the WarpBuild GitHub App rather than through your identity provider. Programmatic access continues to use API keys issued inside the WarpBuild account.

Stating that split early saves a round of questions, because two different reviewers are asking. The identity team wants the protocol, the attribute mapping, and where the session comes from. The platform team wants to know what happens to runs-on and whether pipelines break during the cutover. The answer for the second team is that nothing in the workflow file changes.

The workflow below is what a pipeline looks like on both sides of an SSO rollout. The labels are the same for every team in the organization regardless of how those people sign in to the dashboard.

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  arm-image:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: docker build --platform linux/arm64 -t app:arm64 .

  windows-integration:
    runs-on: warp-windows-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration.ps1

Providers and Protocols

WarpBuild supports enterprise single sign-on via SAML 2.0 and OIDC (OpenID Connect). The SSO documentation names the providers below, and any other SAML 2.0 or OIDC-compliant provider connects the same way.

Pick the protocol your identity team already operates. Teams standardized on SAML 2.0 application catalogs usually stay on SAML. Teams that run everything as OAuth 2.0 clients usually pick OIDC, which skips the certificate handling.

On the SAML path, you create a SAML application in your identity provider and register two service-provider values that the setup wizard displays. Both have different names in different products, which is where most of the setup friction comes from.

Then configure the identity provider to emit four assertion attributes. The attribute names are case-sensitive, so an assertion that emits givenname where the mapping expects givenName fails to populate the field.

On the OIDC path, you create an OIDC or OAuth 2.0 web application in your identity provider and register the redirect URI shown in the wizard as an allowed redirect. You then supply the issuer URL, the client ID, and the client secret. WarpBuild auto-discovers the endpoints from {issuer}/.well-known/openid-configuration, so there are no per-endpoint fields to fill in. Set the application's client authentication method to Client Secret Basic; other client authentication methods are the most common cause of a connection that validates in the identity provider and fails at sign-in.

Pricing

SSO is available for a flat $250 per month, whatever the user count. The fee is one number on the invoice, and it stays the same number as the organization grows.

Everything else stays usage based. The current rates are on the WarpBuild pricing page, and the per-minute rates below come from the runner catalog.

The practical question in a budget review is what the SSO line does to the bill as headcount rises. Here is the arithmetic for three organization sizes, all running on warp-ubuntu-latest-x64-4x at $0.008 per minute. WarpBuild rates checked on 2026-08-13.

The SSO column holds at $250.00 across all three rows. Runner spend moves with minutes consumed, and the identity line does not move with headcount at all, which is the part worth carrying into a finance conversation before an org-wide rollout.

Two more line items belong in the same budget. Cache storage bills at $0.20 per GB-month and cache write or restore operations at $0.0001 each. BYOC Linux and Windows runners carry a $0.002 per minute WarpBuild fee, with the compute billed to your own cloud account.

Setup

The rollout has one gated step and three self-serve ones.

1. Request provisioning. SSO is available on enterprise plans. Email [email protected] with your organization name and the identity provider you plan to use. Support provisions SSO for your organization and sends back a one-time setup link.
2. Open the setup link and choose a protocol. The link requires no WarpBuild login, so it can go straight to the identity provider admin who owns the application catalog, without provisioning them a WarpBuild account first. Choose SAML 2.0 or OIDC on the first screen.
3. Configure your identity provider. On SAML, create the application, register the ACS URL and Entity ID from the wizard, and emit the four assertion attributes above. On OIDC, create the web application, register the redirect URI, and enter the issuer URL, client ID, and client secret with client authentication set to Client Secret Basic.
4. Create the SAML connection. Tell WarpBuild how to reach your identity provider using any one of three methods: a metadata URL, which WarpBuild fetches automatically; metadata XML pasted directly from your identity provider's export; or manual entry of the identity provider SSO URL and X.509 signing certificate. Submitting validates and saves the connection, and SSO goes live for the organization. OIDC connections finish at step 3 and skip this step entirely.

After that, your team signs in by entering your tenant name on the WarpBuild login page, which routes the browser to your identity provider. The full walkthrough with screenshots of each wizard screen is in the SSO documentation.

Sequencing that works well in practice: run step 1 during the commercial conversation so the setup link is waiting when the identity team has a window, do steps 2 through 4 in a single 30-minute session with the identity provider admin present, and verify with two accounts before announcing the change. The metadata URL method is the one to prefer where your identity provider offers it, because certificate rotation on the identity provider side then flows through without a second configuration pass.

Two things to raise with support before you plan a wider migration. First, confirm which of your identity provider's optional behaviors your rollout depends on; the documented setup covers the connection and the sign-in flow, so anything your program requires on top of that is a support conversation. Second, if your organization runs GitHub Enterprise Cloud with data residency or GitHub Enterprise Server, sort the enterprise app registration out in the same pass; that flow is covered on WarpBuild runners on GitHub Enterprise.

The rest of the material a security review asks for sits next to this page. Runner isolation, encrypted ephemeral storage, and the secrets boundary are described in the runner security documentation, and each runner runs in its own virtual machine that is created on demand and destroyed after the build. WarpBuild is SOC 2 Type 2, with trust.warpbuild.com as the linked evidence. For the questionnaire itself, answering a GitHub Actions security review walks through the questions that come up most, and are GitHub Actions runners secure? covers the shorter version.

Placement questions usually arrive in the same thread as identity questions. US and EU are the regions WarpBuild names for hosted runners, and US data residency for GitHub Actions runners covers what runs where. BYOC runs on AWS, GCP, and Azure for teams that want the runner instances inside their own account, and Terraform support exists for BYOC on AWS, so the placement is reviewable as code.

FAQ

Which identity providers does WarpBuild SSO work with?

Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Auth0, Microsoft AD FS, OneLogin, PingOne, JumpCloud, Rippling, and any SAML 2.0 or OIDC-compliant provider.

How much does SSO cost on WarpBuild?

SSO is a flat $250 per month, whatever the user count.

How do I turn SSO on for my organization?

SSO is available on enterprise plans and provisioned through support. Email [email protected], then configure your identity provider yourself through the one-time setup link, which requires no WarpBuild login.

Which SAML attributes does WarpBuild expect in the assertion?

NameID maps to id, email maps to email, givenName maps to firstName, and surname maps to lastName. The attribute names are case-sensitive.