DEV Community: Paul Jennings

Meet Zoomies: free, open-source GitHub Actions runners with a live web UI

Paul Jennings — Fri, 11 Sep 2026 06:38:53 +0000

Self-hosting a GitHub Actions runner starts with a fairly simple goal: run your builds on your own hardware.

Then come the operational questions. Which runners are busy? Why is that job waiting? How do you add another machine? What did the previous build leave behind? And how much work will it take to move your existing repositories over?

I'm building Zoomies to make that experience easier.

It's a free, open-source GitHub Actions runner fleet controller with ephemeral runners, autoscaling across your own hosts, a live web UI, and a migration wizard that opens reviewable pull requests.

It runs as a single Go binary with SQLite. You don't need Kubernetes or a separate database server.

And yes, the name comes from dogs getting the zoomies. The cocker spaniel and the swishing paw print are very much part of the project. CI tools are allowed a little personality. 🐾

The real Zoomies interface, populated with the project's demo fleet. Screenshots throughout this article use demo data; the displayed timings are examples, not benchmarks.

Give each job a fresh runner

A long-lived runner gradually becomes a machine with history: checked-out repositories, installed tools, temporary files and whatever yesterday's workflow left behind.

Zoomies defaults to one job per runner. For container-backed pools, it starts a fresh runner container and removes it after the job finishes.

The controller watches GitHub's workflow_job webhooks, decides when more runners are needed, and asks an agent to start them on a matching host. Polling provides a fallback if webhook delivery isn't available.

You configure pools with the labels and capacity limits your workloads need. Zoomies scales the runners within those limits and the capacity of the hosts you've connected.

That last distinction matters: Zoomies manages runner capacity on your hosts. You still choose and provide the machines.

A web UI for the questions you actually ask

The web UI is a central part of Zoomies.

The Overview brings together queue depth, active jobs, runner counts, startup and registration timings, pool utilisation, and recent scaling decisions. Those decisions include explanations, so you can see why the fleet changed.

From there, you can inspect pools, runners, jobs and hosts, check usage, or follow the audit trail. Pages update through the controller's event stream, with light and dark themes and a command palette for getting around quickly.

When a job fails, its details show the failing step and timings, with a link to the relevant output on GitHub.

Job details connect a failed build to its runner, pool, timings and GitHub logs.

For terminal workflows, there's also a CLI and REST API. Prometheus metrics and structured logs let Zoomies fit into existing monitoring.

Multiple hosts, architectures and runner images

You can start with one machine and an embedded agent, then add remote agents as your needs grow.

The Hosts page shows health, available runner slots and detected backends. Its Add a host flow generates the command to enrol another machine using a single-use join token.

Agents initiate their connections to the controller, which is useful for machines behind NAT: you don't need an inbound connection to each agent.

See which machines have room for more runners and which need attention.

The runner image catalogue includes:

Runner environment	Architectures
Ubuntu 24.04	x86-64 and arm64
Ubuntu 22.04	x86-64
Debian 12	x86-64 and arm64
Fedora 42	x86-64 and arm64
Rocky Linux 9	x86-64 and arm64

Docker and Podman backends are available, alongside a process backend for running directly on a host. The controller and agents target Linux; macOS controller builds are intended for development. Windows runners and macOS runner images aren't currently supported.

See the platform details and support matrix for the distinction between available builds and runtime qualification.

Installation starts with one command

The installer is available at:

curl -fsSL https://zoomies.sh/install.sh | sh

It checks the host and guides you through the deployment choices, configuration and GitHub App connection. Native, Docker Compose and single-container deployment paths are available; the setup finishes in the terminal or browser depending on the path you choose.

The quick start also explains how to download and inspect the script before running it.

Once you've connected GitHub and created a pool, route a job to that pool's label. For example, a pool configured with zoomies-linux-x64 can receive jobs using:

runs-on: zoomies-linux-x64

Your workflow still runs through GitHub Actions. The runner environment needs the tools your steps depend on, so choose an appropriate image and try a representative build first.

Migration is built into the product

Getting a fleet running is only part of adoption. Moving repositories onto it is the next part.

Zoomies includes a Migrate wizard that reads the workflows your GitHub App can access, maps supported hosted-runner labels to your pools, and shows the proposed changes before opening a pull request for each selected repository.

A typical change looks like this:

- runs-on: ubuntu-latest
+ runs-on: zoomies-linux-x64

The wizard changes the selected runs-on values while preserving the surrounding formatting. It reports skipped jobs and their reasons, including matrix expressions and workflows already targeting self-hosted runners.

Review the exact workflow change before opening a PR. This demo also shows how missing GitHub App permissions are explained.

For teams already using static self-hosted runners, there's another route: configure a Zoomies pool to match the labels those workflows already request. Where the labels and environment are compatible, workflows can move across without editing their YAML, and you can retire the old runners gradually.

The migration guide covers both approaches.

Free software, infrastructure you control

Zoomies is released under AGPL-3.0. The source is available at eyupio/zoomies.

The software is free; you provide the compute, storage and network resources. Whether self-hosting saves money depends on your hardware, workload and operating costs.

Zoomies is currently an early beta, intended initially for workloads you trust. Its defaults include ephemeral runners, authentication, and container jobs without access to the host Docker socket. Self-hosted jobs still execute repository code, so read the security guide when choosing how to deploy it.

Give your CI the Zoomies

If you've been looking for a way to manage self-hosted GitHub Actions runners from a usable web interface, try Zoomies with one repository and one pool.

Explore the project: zoomies.sh
Get running: Quick start
See more screenshots: Web UI tour
Star, contribute or report an issue: eyupio/zoomies on GitHub

I'd love feedback from people running CI on their own machines: what's the biggest headache in your current runner setup?

Introducing SUB12.io: A Free Precision Shooting Platform for Sub-12 Air Rifle Shooters

Paul Jennings — Sun, 26 Apr 2026 09:56:15 +0000

SUB12: a free precision-shooting platform I built for a niche sport I love

I shoot sub-12 ft·lbf air rifle benchrest from Yorkshire. Twenty-five-shot cards at known distances, where the difference between a good day and a great one is often a different pellet batch, half a click of windage, or a rest that didn't quite settle.

It is, more than most sports I've tried, a sport of small details — and almost none of those details get recorded properly. They end up scattered across paper cards in a kit bag, photos on a phone, half-finished spreadsheets, and WhatsApp messages with club mates. I had a perfectly good record of my last great session somewhere; I just couldn't find it. And I couldn't answer questions that should have been easy:

Which rifle and pellet combination is actually working best for me?
Am I improving over time, or did I just have one good Saturday?
Which pellet batch produced the smallest groups?
How are the rest of the club doing this league round?

So I built SUB12 — a free web app for tracking score cards, managing rifles and pellets, testing pellet performance, joining clubs, and running leagues. It's live now, and I'm looking for early users and contributors.

What SUB12 does

At its core, SUB12 lets you log a 25-shot score card and link it to the rifle, pellet, score, X count, target photo, league, and club it belongs to. Once that's in the system, every card becomes part of a longer story.

You can track:

25-shot score cards with shot grids
Personal bests and recent form
X-ring counts
Per-rifle performance
Pellet and rifle combinations
Group sizes from pellet tests
Club standings and league rounds
Verification, amendments, and audit trails
Activity feed posts and comments
Achievements

The aim isn't to digitise a paper score card. It's to make every session useful later.

Score cards with context

A score on its own tells you the result. A score with context tells you why.

Every card in SUB12 carries the rifle, the pellet, the individual shots, the X count, the target photo, and — if the card belongs to a league — the verification status and audit trail. So when you look back at a personal best, you know exactly what produced it.

That trust layer matters for leagues, where club organisers need to know a card is real. It also matters for the shooter who wants to understand whether a result came from form, equipment, or a particular setup.

Gear management

Most benchrest shooters I know own more than one rifle and test more than one pellet. SUB12 tracks both, with profiles for each rifle and a pellet library you can attach to cards and tests.

The point is to make the rifle/pellet question answerable from your own data, not from gut feel after a single windy afternoon.

Pellet testing — the part I'm most proud of

Pellet choice in airgun shooting tends to be heavily anecdotal. People swear by a tin, then a bad batch lands and the swearing changes character.

SUB12 has a dedicated pellet testing area that records group sizes per session, ranks rifle/pellet combinations over time, and shows performance trends across batches and lots.

The long-term goal is to make pellet selection more empirical without making it joyless. You still shoot the groups. SUB12 just remembers them properly so that the next time you stand in front of a wall of tins, you have data to point at.

Clubs and leagues

Clubs in SUB12 bring members together with leaderboards, linked leagues, a shared activity feed, and member admin. Leagues support seasons, rounds, standings, score verification, amendments, and a full audit history.

There's a social layer too — follows, posts, comments, achievements — because a club is more than a fixture list, and a lot of what keeps people in the sport happens between sessions.

Why a PWA

Shooters capture data away from a desk, often with a poor signal, almost always on a phone. SUB12 is a progressive web app: it installs on iOS, Android, and desktop without an app store, works on capture-friendly screens at a range, and updates instantly without a release cycle.

For a small niche sport, the PWA route was an easy call. I wanted to ship to every device my users actually carry, without running three codebases and waiting on store reviews.

The stack

For anyone here for the build details rather than the rifles:

Frontend: React, TypeScript, Vite, Tailwind CSS
Routing & data: TanStack Router, TanStack Query
State: Zustand
Charts: Recharts
Backend: Go with Chi
Storage: PostgreSQL, Redis
Mobile: Capacitor / PWA

It's a deliberately boring stack, and I'm grateful for that every time I touch it. TanStack Query took most of the data-loading mental load off the table; Go and Chi keep the backend small and well-behaved; PostgreSQL does all the heavy lifting for league scoring and audit history.

What I'm looking for

SUB12 works, but it has the lopsided edges any v1 has — and the people best placed to help me sand them down are the people who'll actually use it.

I'd particularly value feedback from:

Air rifle benchrest shooters — does the score card flow match how you actually log a card?
Sub-12 ft·lbf rifle owners — what's missing from the gear and pellet testing setup?
Club organisers — do the club tools fit how your club actually runs?
League organisers — does the verification and audit flow give you what you need?
Anyone using spreadsheets or paper logs today — what would make you switch?
Developers interested in niche sports software — issues, PRs, and "have you considered" emails are all welcome.

The kinds of feedback that'll help most: bugs, friction points, things that almost-but-don't fit your workflow, and features you'd reach for next.

Free, and staying free

SUB12 is free now, and the plan is to keep it free. No subscription, no premium tier, no paywall on core features. It's a niche-sport tool built by someone in the niche, and that's how I'd like it to stay.

If any of the above resonates, take it for a spin:

→ https://sub12.io

And if you find anything rough, please let me know. That's the whole reason I'm posting this.