Runner compatibility

Fabric runs your .github/workflows/*.yml when you propose, push to a proposed change, or accept. The runner executes each job’s steps directly on the host, so it has no Docker daemon. That makes runs fast and cheap, and it means most of a normal CI workflow (checkout, language setup, install, build, test, deploy) works unchanged. It also means any feature that needs Docker cannot run.

This page lists what works, what does not, and the exact error you see when a workflow uses something unsupported.

What works

Feature	Notes
`run:` steps	Shell steps of every kind: `bash`, `sh`, `pwsh`, `python`. The core of most workflows.
JavaScript `uses:` actions	Node actions like `actions/checkout`, `actions/setup-node`, `actions/setup-python`, `actions/setup-go`.
Composite `uses:` actions	Actions built from other `run:` and JS steps.
`actions/cache`	Dependency caching restores and saves across runs.
Build artifacts	`actions/upload-artifact` and `actions/download-artifact` work within a run.
`setup-*` actions	The language and tool setup actions install onto the host for later steps.
`env:`, `secrets:`, `vars:`	Workflow, job, and step environment, plus `${{ secrets.* }}` and `${{ vars.* }}`.
`needs:`, `matrix:`, `if:`	Job dependencies, matrix expansion, and conditional steps.
`timeout-minutes`	Per-job timeouts are enforced.

What does not work

The runner has no Docker daemon, so anything that would start a container cannot run. These features are rejected before the job starts, with a clear error, so a workflow that uses one fails fast instead of running part way and breaking later.

Feature	Why
`services:`	Service containers (a database, a cache, a message broker) need Docker to start.
`container:`	A job that runs inside a container image needs Docker to create it.
`uses: docker://<image>`	An image-based action pulls and runs a container.
Docker (Dockerfile) actions	An action whose `action.yml` sets `runs.using: docker` is built and run as a container.
`docker build` / `docker run` in a `run:` step	There is no daemon for the Docker CLI to talk to, so these commands fail.

Adding support for these is a separate piece of work that is still ahead of us. Today they are a known limitation of the Docker-free runner.

The error you will see

When a job uses an unsupported feature, its check fails with a message naming the feature and the job or step it came from, and pointing back to this page. For a job that declares services:, the check reads:

services: is not supported on this runner (it has no Docker daemon). Found in
job 'test'. Supported: run: steps and JS/composite uses: actions. See
https://fabricemr.com/docs/runner-compatibility/

The same shape applies to container: and Docker-based uses: actions, with the feature name and location swapped in. The message shows in the web runs view and in fabric checks --logs <job>.

How to adapt a workflow

Service container (database, cache, broker): install the service on the host in a run: step and start it there, or point the job at a managed instance and pass its connection string through secrets: or vars:.
container: job: drop the container and install what the job needs with setup-* actions and run: steps. The host already has common toolchains.
Docker action: look for a JavaScript or composite version of the same action, which is common for popular actions, or replace it with run: steps.
docker build / docker run: move image builds to a step that pushes to your registry using its API or CLI, or run them in an environment that has a Docker daemon and report the result back.

If none of these fit your workflow, tell us with fabric report and include the workflow so we can prioritize the missing feature.