Every GitHub Actions job runs in a throwaway Linux VM on the Macs your team already owns.
Paste into Claude Code, Codex or CursorYour agent opens the PR
› Use curl to read https://slotline.sh/agent, then follow it to run the pull request CI of acme/api on our Slotline Macs, keeping cloud runners as the fallback.
✓ Opened a pull request: Route pull request CI to Slotline Macs
Never slower than todayWith the Mac-first router, no free Mac in 60 s means your cloud runner takes the job.
SandboxedNo host files, SSH keys or tokens enter the VM.
Still just GitHubQueues, logs and results stay in GitHub Actions.
01 · How it works
Three steps. No new CI system.
GitHub keeps the queue, the logs and the results. Your Macs just show up as runners.
1
Connect GitHub, invite the team
The owner connects a private GitHub App to one repository and invites teammates by GitHub username.
ANana-devJoined
SAsam-codesInvited · 2 days
2
Each teammate pastes one command
After signing in, a teammate pastes one command into Terminal. It checks the Mac, installs the agent and builds the runner image locally, usually in 10–20 minutes.
$ curl -fsSL https://slotline.sh/install | sh -s -- sl_•••
✓ Mac connected · worker online
3
Hand the workflow to your coding agent
Copy one prompt from the setup page into Claude Code, Codex or Cursor. The agent adds a small router job and opens a pull request; every routed job keeps its cloud runner as the fallback.
› Use curl to read https://slotline.sh/agent, then follow it…
✓ Pull request opened · cloud fallback kept
02 · When every Mac is busy
Pick how long a job may wait.
Point a job straight at the pool, or let the Mac-first router decide per run. The router never makes a PR wait longer than a minute for a Mac.
Direct label
Simplest
The job waits in GitHub's queue until one of your Macs is free. Good for jobs you always want on a Mac.
runs-on: pilot-4vcpu-ubuntu-2404-arm64
Mac-first router
Recommended
A short routing job asks the platform for a free Mac with GitHub OIDC, so there is no shared secret. If none is ready within 60 s, the run uses your existing cloud runner.
A guard on your default branch also cancels a Mac job that sits in the queue for 90 s and retries the run once on cloud runners. Forks, public repositories and deployment runs are never sent to Macs.
03 · What reaches the VM
The job gets a VM. It never gets your Mac.
Every job boots a clean Ubuntu VM from a hash-verified image and gets deleted when the job ends. Nothing from your Mac is passed in.
Inside the VM
✓Your repository and the jobChecked out fresh for every run
✓The secrets that job usesDelivered by GitHub Actions, as on any runner
✓Docker and service containersPostgreSQL, Redis and builds stay inside the VM
✓Public packagesThrough a proxy that blocks private networks
Never passed in
✗Your filesNo folders are mounted from the Mac
✗Your SSH keysNo forwarded SSH agent
✗Your DockerThe host Docker socket stays on the host
✗Platform credentialsNo platform token or GitHub App key
Pilot note: jobs receive the repository secrets they use, so anyone who enrolls a Mac must be trusted with that repository's CI. That's why the pilot is invite-only and limited to one private repository.
04 · Your Mac stays yours
CI works around your day.
One worker per MacBook, and it steps aside when the machine needs to be a laptop.
Only on power
Jobs start only while the Mac is plugged in or has at least 30% battery.
Pause anytime
Pause from the dashboard. The current job finishes and no new ones start.
Backs off under load
If memory pressure turns critical, the Mac takes no new jobs and shuts its VM down.
Revoke in one click
Revoke a Mac and its agent stops the VM on its next heartbeat. Slots stay held until cleanup is confirmed.
05 · Specs
What runs, and what it runs on.
Linux on ARM64. Jobs and Docker images need to support arm64.
Runner VM
Ubuntu 24.04 · ARM64 · 4 vCPU · 8 GiB RAM
Label
pilot-4vcpu-ubuntu-2404-arm64
Tested with
actions/checkout, language setup, PostgreSQL and Redis services, Docker build, cache, artifacts, cancellation
Your Mac
Apple silicon · macOS 15 or later · Homebrew
Disk and power
20 GB free · plugged in or at least 30% battery
Pilot limits
Up to 5 Macs and one private repository per workspace · one worker per MacBook, two on dedicated Macs
Access
Invite-only · the Mac package is not yet Apple-notarized
06 · Questions
Before you put CI on your laptop.
Will CI slow my Mac down?
Each Mac runs one job at a time in a VM capped at 4 vCPU and 8 GiB. When you need the whole machine, pause it from the dashboard: the current job finishes and nothing new starts. Under critical memory pressure the Mac stops taking jobs on its own.
Do my workflows need to change?
Only runs-on, and your coding agent makes that change in a pull request you review: a small router job picks a free Mac, and each job falls back to its usual cloud runner. Jobs run on ARM64 Linux, so tools and images need ARM64 builds.
Can a job read my files or keys?
No folders, SSH agent, host Docker socket or platform credentials are passed into the VM, and its network can't reach your private network. A job does get the repository secrets it uses, just like on any runner, so Mac owners must be trusted with that repository.
What happens when every Mac is busy?
With the direct label, the job waits for a Mac. With the Mac-first router, it waits at most 60 seconds and then runs on your existing cloud runner.
Which repositories are supported?
During the pilot, one private repository per workspace. Forks, public repositories and deployment runs are excluded.
Who can join the pilot?
It's invite-only for now. Request access with your email and GitHub username and we'll reply by email.
Put the Macs on your desks to work.
More PRs shouldn't mean a longer queue. Join the pilot and run CI on the machines your team already has.