Account

Security

Your jobs run on a server only your organization uses. Each job runs in its own virtual machine, destroyed when the job ends. Your secrets stay in GitHub and reach only the job that uses them.

This describes the private-beta setup. Items marked Before your first job are configured and checked on your server before your first job runs.

Isolation

  • No shared machines. During the beta your jobs run on a server dedicated to your organization. No other customer’s jobs run on it, and nothing on it is shared. Before your first job
  • A fresh machine per job. Each job gets its own virtual machine with a single-use runner registration, runs exactly one job, and is destroyed afterwards.
  • Warm starts are built only from your default branch, never from pull-request code, and each job gets its own copy.
  • Test parallelization: the parts don’t hold GitHub credentials and can’t reach the network. Only your original job talks to GitHub. Before your first job

Your secrets

GitHub sends Actions secrets, GITHUB_TOKEN and OIDC tokens to the runner of the job that uses them, as it does for any self-hosted runner. They exist only inside that job’s machine, which is destroyed afterwards. We don’t add, read or store your secrets.

What the GitHub App can do

  • Register self-hosted runners in your organization, one single-use registration per job.
  • Read Actions job status, and organization membership for sign-in.
  • Read the code of the repositories you select, to prepare warm starts from your default branch: read-only, one repository at a time. Never write access.

The App’s private key is held only by our control service, never on the server that runs your jobs. We never ask for a personal access token.

Warm starts

  • A warm start is saved only from runs of your default branch (push, manual or scheduled) that reach the checkpoint step, never from pull requests, and is used only by jobs of the same repository.
  • Before a saved setup is used, we remove the runner’s credentials, the job’s workspace and checkout, temporary files, logs, shell history and the credential files of common tools. We refuse to save a setup that still contains one of the job’s GitHub tokens or any credential-shaped content.
  • Run steps that use secrets after the checkpoint step. Anything your setup steps write to disk outside the workspace before it becomes part of the saved setup, and later jobs of the same repository, including pull-request jobs, start with it. We can’t recognize every credential, for example a token from a cloud or Vault login that uses OIDC. Don’t log in to clouds, registries or secret stores before the checkpoint step.

Network

  • Job machines have no public address and accept no inbound connections. Before your first job
  • Jobs can reach the public internet, so package registries and Docker Hub work. Private address ranges, the cloud provider’s metadata service and our internal systems are blocked. Before your first job
  • Job machines have no cloud permissions. They reach your cloud only with credentials your workflow brings, such as OIDC.
  • Private networks and VPNs aren’t supported in the beta.

Data

  • Job logs stay in GitHub, under your retention settings.
  • We keep job metadata for billing and support: organization, repository, workflow and job names, run and job IDs, times, and resource use. No process arguments, environment or tokens.
  • The prepared copy for warm starts stays on your dedicated server and is deleted when you leave.

Compliance

We don’t have a SOC 2 report or a penetration test yet. A data processing agreement isn’t available yet. An internal security review of your setup, with sign-off, happens before your first job. We answer security questionnaires truthfully, including what is still in progress.