Uptime theater
They got your business because it used to always say 99.99%.
Self-hosted CI · MIT · Take back the uptime
Your CI runner doesn't get to go down.
notdownhub runs your workflow YAMLs triggered directly from your git repo or git server.
We wanted a CI runner that doesn't go down and doesn't nickel-and-dime us. So we built one. That's the whole idea.
$ ndh run [ndh] parsing workflows in ./ (no server, no open ports) [ndh] build (node: 20) ✓ 12.4s [ndh] build (node: 22) ✓ 11.9s [ndh] test needs: build ✓ 8.1s [ndh] done: 3 jobs, 0 queued, 0 orange
The cloud isn't what it used to be
It's red again.
Somewhere between your push and your deploy there's a page that's supposed to say everything's fine. Today it doesn't, and it seems like there are more days like today than yesterday. Now you've refreshed this page 41 times and your deploy has not moved. Why should you feel powerless over that?
cloud pipeline · status
auto-refreshing
Degraded performance
90 days
uptime 93.2% · "four nines" not pictured
Investigating
We're aware of elevated wait times for queued jobs and are looking into it.
Identified
A subset of runners in one region are affected. Others may see slowness.
Monitoring
A fix has been applied and we're watching recovery. Thank you for your patience.
Resolved
Incident resolved until next time.
Your deploy pipeline has a status page. On reflection, that should have been the first warning.
This costs you money
But the service isn't going to reimburse you for lost productivity.
Mandatory grass touching
And it's not just your team — your customers and downstream partners are down too!
Take back control
How it works
Run your workflows on your own machines. notdownhub is the missing piece that talks to the official self-hosted action runners. It adds a caching mirror and a web UI, and it coordinates runners from any machine you own on any repo that you have a copy of.
Use the cloud service when it's up, then repoint your self-hosted runners to notdownhub using a local repo copy of your ci.yaml when it inevitably goes down.
Enable multi-user participation by connecting notdownhub to a local git server and get your team back to work during the downtime.
Or just set it up as a lightweight solution to avoid being nickel-and-dimed on action minutes.
Run it in a cloud you still trust
The hub is simple and can run anywhere.
ndh hub up
is a single process sitting on a single port. It's easily secured and runners reach it
outbound-only. Set up simple WireGuard or Tailscale if you want additional protection and portability.
It doesn't need a big machine: the smallest cloud VM runs a
hub for a whole team. To keep it up as a background service, follow the
operations guide in the source repo.
What you actually get
A way around overreliance on unreliable providers
Unmodified workflow YAMLs
The standard workflows format, unchanged. Your matrix runs, your needs graph resolves, and the marketplace actions and runs-on labels behave exactly as written.
NAT-friendly fleets
Runners dial out and long-poll, so there's nothing to forward and no public IP to arrange. A laptop at home wifi can join a hub back at the office.
One-port hub
UI, API, runner coordination, and the caching mirror all sit behind a single port you choose and control. Default is a local private portal with basic auth if you want to make it available anywhere.
Docker or bare metal
Windows (probably), Linux, and macOS jobs can run in a container on Docker, or straight on the host.
MIT, all of it
Open source all the way down: Fork it and run it for as long as you like.
TLDR
OSS saves the day
notdownhub is a thin CLI (ndh)
wrapped around a maintained, MIT-licensed action-protocol server and the
official runner codebase. It can run anywhere, and it supports single repos and
git servers if you want collaboration.
Built on runner.server by ChristopherHX, a maintained, MIT-licensed fork of the official runner that does the genuinely hard part. Self-hosted action runners are directly from the cloud provider. notdownhub adds the packaging and the opinions. Credit where it's due.
Run it
Clone the repo and run your own CI.
Not on a package registry yet, so today the way in is clone and build. Three lines and you're running your own workflows on your own machine.
$ pnpm install && pnpm -r build $ ndh install # one-time: pins the runner stack (~66 MB) $ ndh run # run this repo's workflows, locally, offline-capable $ ndh hub up # later: a persistent hub for the whole team