Actions compatibility
Everything GitHub Actions does, on our machines
A runner is more than a VM. The official actions talk to service APIs for cache, artifacts, logs and identity; Play Compute implements each one, so nothing in your workflow changes but runs-on.
27 available4 not offered
Service APIs the runner talks to
The APIs behind the official actions. We implement each one next to the machines, so the actions you already use work unchanged and faster.
- Cache service v2actions/cache@v4, setup-* caches, restore keys, cross-branch scopes. Stored in the same region as the job.Available
- Artifacts v4actions/upload-artifact@v4 and download-artifact@v4, retention, merge. Also in the app, the API and the CLI.Available
- Live logs and log archiveStreaming step logs, groups, masks, the downloadable archive. Searchable across runs.Available
- Job summariesGITHUB_STEP_SUMMARY Markdown on the run pageAvailable
- Annotations and problem matchers::error, ::warning, ::notice with file and lineAvailable
- OIDC tokensid-token: write for keyless sign-in to AWS, GCP, Azure, Vault. Issued by GitHub; claims are unchanged.Available
- Artifact attestationsactions/attest-build-provenance, SLSA provenanceAvailable
- Tool cachesetup-node, setup-python, setup-go, setup-java, rustup. Popular versions are already in the image.Available
- Packages and container registryGITHUB_TOKEN sign-in to ghcr.io and GitHub PackagesAvailable
Workflow syntax
GitHub evaluates your workflow; the runner only has to behave. Everything here is unchanged.
- Matrix, needs, if, strategyFan-out, fail-fast, max-parallel, include and excludeAvailable
- Reusable workflows and composite actionsworkflow_call, uses: ./.github/actions/...Available
- Outputs and environment filesGITHUB_OUTPUT, GITHUB_ENV, GITHUB_PATH, GITHUB_STATEAvailable
- Concurrency groupsconcurrency, cancel-in-progressAvailable
- Environments and approvalsProtected environments, required reviewers, secretsAvailable
- Re-run failed jobsRe-run all, re-run failed, re-run with debug logging. Also from the app and the CLI.Available
- Timeouts and canceltimeout-minutes, cancel from GitHubAvailable
- Every triggerpush, pull_request, schedule, workflow_dispatch, merge_group, ...Available
Containers
A job is a whole machine with its own kernel, so Docker works like it does on a VM.
- Service containersservices: postgres, redis, ... with health checks and portsAvailable
- Container jobscontainer: image for the whole jobAvailable
- Docker, buildx and composedocker build, buildx bake, docker compose upAvailable
- Docker layer cacheLayers kept between runs on a disk next to the job. Add-on, billed per GB.Available
- Sticky disksA disk that follows a job between runs (node_modules, Bazel, Gradle). Add-on, billed per GB.Available
- KVM inside the jobAndroid emulators, Firecracker in CI. A job is already a nested guest.Not offered
Machines
What a job can run on today.
- Linux x86-64, Ubuntu 24.04play-2vcpu to play-16vcpu, 4 GiB of memory per vCPUAvailable
- Memory that grows and shrinksA job gets memory as it uses it, up to its size's maximumAvailable
- Static egress IPOne fixed address for allow-lists. Add-on, billed per month.Available
- Linux arm64ARM runnersNot offered
- macOS and Windowsmacos-*, windows-* labels. Keep these jobs on GitHub-hosted runners.Not offered
- GPUGPU runnersNot offered
Moving in
How a workflow gets here.
- One-line changeruns-on: play-4vcpuAvailable
- Migration pull requestThe GitHub App finds every runs-on and opens one PRAvailable
Something your workflow needs that is not here? Keep that one job on its current runner (the switch is per job) and read the quickstart for what the image holds.