Hosted minutes add up
On private repositories, hosted runner time is metered. Every push to every pull request spends some.
Open source · MVP for Linux & WSL2
Your PR.
Your Compute.
OwnCI turns the machine you already code on into the GitHub Actions runner for your repository. GitHub still queues the jobs and shows the check on your pull request. Your machine does the work, and every job runs inside a Docker container.
curl -fsSL https://sparshlabs.com/ownci/install.sh | shThe problem
Your CI waits in someone else’s queue while your own machine sits idle.
Most pull request checks run on hosted runners: shared virtual machines that start from a clean image every time and, on private repositories, are billed by the minute. Meanwhile the laptop or workstation you’re sitting at is usually doing nothing.
GitHub already lets you run jobs on your own hardware with self-hosted runners. Turning one on is a small project, though: download and verify the runner, register it with a token, keep the process alive, clean up between jobs, and remember how to take it all out again. And by default a self-hosted runner runs job steps directly on your machine, as you.
What gets in the way
Three reasons people don’t use their own compute.
Self-hosting is a chore
Download, checksum, register, supervise, clean up and unregister, all by hand and again on every machine.
A plain runner runs on your host
A stock self-hosted runner executes steps directly on your machine and leaves files behind for the next job.
What OwnCI changes
The official runner, without the busywork.
OwnCI doesn’t replace GitHub Actions or invent a new CI. It installs, supervises and cleans up the official actions/runner, and configures it so jobs run in containers.
A runner set up by hand
- Find the right runner release and verify it yourself
- Paste a registration token into
config.sh - Keep
run.shalive and restart it after a crash - Jobs run straight on your host
- One job’s leftovers are still there for the next
- The generic
self-hostedlabel can catch any workflow
With OwnCI
ownci setupdownloads the pinned runner and checks its SHA-256 before registering- Your GitHub token is never stored, and the short-lived registration token never appears on a command line
- A supervisor restarts the runner with backoff;
ownci stopstops it cleanly - Every job runs in a Docker container
- The workspace is wiped after every job, and a failed wipe fails the job visibly
- An opt-in
owncilabel, so a strayruns-on: self-hostednever lands on your laptop
One command each
Set it up, start it, stop it, remove it.
ownci setupDownload and verify the runner, register it with your repository, install the isolation settings.
ownci startRe-check isolation, clean up leftovers, and start taking jobs. Add --detach to run in the background.
ownci stopStop contributing compute. The registration is kept, so start brings it back.
ownci uninstallStop the runner and, if you ask, unregister it on GitHub and remove OwnCI’s files.
Not sure your machine is ready? ownci doctor checks the platform, your user, Docker, ICU and the isolation settings, and ownci status reports what is actually running.
What stays the same
Your workflows, your PR checks, two lines different.
GitHub still owns workflows, queuing, scheduling and the check on the pull request. You point a job at your runner with the ownci label and give it a container image. That’s the whole change.
jobs:
build:
runs-on: [ownci] # the opt-in label OwnCI registers
container: ubuntu:24.04 # every job runs in a container
steps:
- uses: actions/checkout@v4
- run: make testWorkflows without a container: line can run unchanged in container-runner mode, and a team can share one workflow so everyone’s jobs run on their own machine, with maintainers deciding which jobs reach which machine.
Built for code you trust
What OwnCI is, and what it isn’t.
- For private repositories whose workflows you trust: your own and your team’s.
- Containers and a clean workspace for every job, re-checked every time the runner starts.
- Not a sandbox for hostile code. The official runner mounts the Docker socket into job containers, so a job can control your Docker daemon. The container guards against accidents, not attacks.
- Public repositories are refused by default, because pull requests from forks could run code on your machine.
- Early days: Linux and WSL2 only (tested end to end on WSL2 with Docker Desktop, amd64; native Linux and arm64 are built but not yet tested), one job at a time per runner, and no auto-start on boot yet.
Read the trust model before you point OwnCI at anything you don’t control. What OwnCI enforces, and what it doesn’t →
Ready when you are
Run your next PR check on your own machine.
Install, run ownci doctor, and set up your repository.