SSO for GitHub Actions Runner Access

Answer

WarpBuild supports single sign-on through SAML 2.0 and OIDC for a flat $250 per month whatever the user count. Setup is self-serve end to end: an organization admin configures the connection from Settings, verifies the company domain over DNS, and your team then signs in by entering your tenant name on the WarpBuild login page. Billing starts after the first domain is verified.

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

An organization admin runs all four steps from Settings → SSO.

1. Choose a tenant name. Two to forty lowercase letters, numbers, or hyphens. This is what your team enters on the WarpBuild login page, and it cannot be changed later.
2. Configure your identity provider. Choose SAML 2.0 or OIDC. On SAML, create the application, register the ACS URL and Entity ID from the wizard, emit the four assertion attributes above, then tell WarpBuild how to reach the identity provider using a metadata URL, pasted metadata XML, or manual entry of the SSO URL and X.509 signing certificate. 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.
3. Verify your domain. Add your company domain and publish the TXT record the wizard shows at your DNS host. WarpBuild checks for it automatically. Sign-in stays blocked until at least one domain is verified, and billing starts once it passes.
4. Enforce SSO. Optional. Enforcing requires every member to sign in through your identity provider. You sign in through SSO yourself first, which proves the connection works before the organization is locked to it.

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: start the domain verification early, since DNS propagation is the one step you do not control and it can take a few hours; do the identity provider configuration in a single 30-minute session with the admin present; and verify with two accounts before enforcing. 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 worth settling before a wider migration. First, members whose email sits outside your verified domains, such as contractors on personal addresses, are not covered by SSO; they join by invitation and sign in with Google or GitHub, and an organization still carrying such members cannot enforce SSO until they are covered by a verified domain or removed. 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?

An organization admin turns it on from Settings, with no provisioning request. You choose a tenant name, configure your identity provider, and verify your company domain over DNS. Billing starts after the first domain is verified.

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.