Skip to main content

CI configuration

run.cloud CI loads config from the commit SHA in this order:
  1. Native .runcloud/ci.yml (or .yaml / .json) if present
  2. Opted-in jobs in .github/workflows/*.{yml,yaml} (runs-on: runcloud)
Jobs from both sources are merged. Names must be unique.

Native .runcloud/ci.yml

Use this when you want a dedicated file without GitHub Actions syntax:

Job fields (native)

Check Run name: run.cloud / <job-key>.

GitHub Actions subset (gha-subset)

Opt-in jobs under .github/workflows/ support a documented subset of GitHub Actions workflow syntax. Unsupported constructs on an opted-in job fail the check run.cloud / config with an explicit error (fail closed).

Opt-in

Supported

Not supported (error on opted-in jobs)

Jobs that do not opt in are never validated against this list. They remain normal GitHub Actions jobs.

GHA-valid resource and path form

GitHub’s workflow schema (and tools like actionlint) reject unknown job keys such as cpu, memory, and paths. Prefer env-based extensions:
RUNCLOUD_* keys are configuration for run.cloud. They are not exported into the guest environment for your steps.

Defaults

Check Run names

Disabling a repository

After the GitHub App is installed, you can disable CI for a single repo from the API or dashboard controls for that installation so webhooks stop enqueueing jobs without uninstalling the App.

Limits and billing

Sandbox size and duration follow your org’s sandbox product limits. Usage is metered as Firecracker sandbox time for the org bound to the installation. See Access Control and Metering.

Full examples

See GitHub workflows and Secrets in CI.