Runnable

Security and privacy

Your code runs here. It never trains here.

Runnable processes customer content only to provide, secure, and support your CI. These commitments apply to every plan, with no opt-out required and no premium tier that unlocks them.

You pay Runnable to run CI. Your development activity is not an advertising asset or a training corpus.

No AI training

Customer content is never sold, used for advertising or competitive analysis, or repurposed for generalized model development — ours or anyone else's. This applies to source code, diffs, workflows, logs, artifacts, secrets, and support attachments.

Minimal source custody

Your repository stays in GitHub or Entire. Each job fetches the requested commit onto one clean, single-use machine, and that machine is destroyed when the job ends. The optional workspace-handoff extension stores a private one-day snapshot only when a workflow explicitly enables it.

Least-privilege access

Short-lived repository credentials are narrowed to each job's declared permissions and refreshed during execution. Fork pull requests are downgraded to read access. Platform-wide credentials never enter the job environment.

Tenant-isolated secrets

Each organization has its own versioned workspace encryption key, and each secret receives a fresh data key wrapped by it. Organization, repository, environment, and name form the authenticated encryption context. Fork pull requests receive no customer secrets at any scope.

Explicit retention

Logs and artifacts follow the published retention window of your plan. What Runnable keeps, and for how long, is never ambiguous.

Provider-neutral CI

Runnable executes and records your CI independently of GitHub Actions. GitHub Actions does not parse, schedule, execute, log, cache, or store any Runnable job.

How it is enforced

Answers to the questions a security review actually asks.

Isolation

One job runs on one ephemeral Linux x64 machine. Machines are never reused between jobs and disks are non-persistent.

Workspace handoff

The opt-in handoff transfers a SHA-256-verified private artifact to an authorized direct dependency; it never reuses a machine. Internal snapshots are hidden from normal artifact APIs and expire after one day.

Secret handling

Secrets are masked in log output before storage. Log chunks are written as ordered, immutable, gzip-compressed objects in a private bucket.

Key management

Workspace keys are wrapped by a versioned root key held outside the database. Rotation retires the previous version for decryption and makes the new version active for all new and updated secrets.

Network egress

Jobs can reach arbitrary public endpoints for dependencies, APIs, registries, and deployment. Provider-enforced rules block private, loopback, link-local, carrier-grade NAT, and cloud-metadata networks.

Tenant boundaries

Every tenant-owned record carries an organization identifier, and every customer query combines the resource identifier with the authenticated organization.

What is not supported

The runner is Linux x64 only, with a six-hour ceiling and no native job containers. Native services and OIDC are supported; OIDC requires a dedicated stable signing key and is denied to forks. Write-scoped repository tokens require both an explicit workflow permission and the matching GitHub App grant.

Reviewing Runnable for your team?

Check a workflow first. No account is required, and workflow source is never retained.

Check a workflow