Job environment¶

Each job runs in its own virtual machine (Kata Containers), which is deleted when the job ends.

Values measured on the beta sites in November 2026. Slot sizes for paid plans may differ.

Installed tools¶

Forgejo and GitHub jobs run in the runner.li job image with bash, curl, docker (with Buildx and Compose), envsubst, gh, git, gpg, jq, make, node, npm, pip3, python3, rsync, ssh, sudo, tar, unzip, uv, wget, xz, zip and zstd. Other language versions come from the usual setup actions (setup-node, setup-python, setup-go, setup-uv), as on GitHub.

GitLab jobs run in the image your pipeline names, or ubuntu:24.04.

Docker, job containers and services¶

• docker build, docker run and Compose work in every job. Each job has its own Docker daemon.
• container: runs the job inside an image of your choice, for example container: golang:1.27.3. Docker is available inside it as well.
• services: start next to the job and are reachable by their name, for example postgres:5432.
• Builds for other CPU architectures work with QEMU emulation, as on GitHub: docker/setup-qemu-action, then platforms: linux/amd64,linux/arm64. Emulated builds are several times slower. For Go, Rust or Node, cross-compiling with FROM --platform=$BUILDPLATFORM avoids emulation.

Network¶

Jobs reach the internet, including your forge and its registry. They cannot reach the infrastructure the runners run on or other customers' jobs. To reach a private network, use a VPN client in the workflow until private connectivity is available (planned).

Cache¶

actions/cache and Buildx's cache-to: type=gha work within a job. The cache does not carry over to the next job yet, because every job starts in a fresh machine. For Docker layer caching across jobs, use a registry cache:

- uses: docker/build-push-action@v6
  with:
    cache-from: type=registry,ref=<registry>/<owner>/<image>:buildcache
    cache-to: type=registry,ref=<registry>/<owner>/<image>:buildcache,mode=max