Mirroring Your Repo Is Not a Backup Plan

On August 6th, degraded GitHub Actions and Pages was actively discussed on Hacker News. The GitHub problems meant builds broke, deployments broke, project pages stopped publishing — and the discussion turned almost immediately from "they are having an outage" into "how dependent on them are we, exactly?".

A reaction that size makes sense. GitHub stopped being just code hosting a long time ago: it is also the CI, the release process, the public face of a project, and often the project's website. When one company holds all four roles, any outage of theirs turns straight into a conversation about vendor lock-in.

I find that interesting from a practical angle. I have mirrored my repositories for years and assumed I was covered. An outage is a good excuse to check whether that is true.

What I actually have

Every one of my projects lives on three hosts at once: my own Gitea on my server, GitLab, and GitHub. Texodus has four — the fourth is a Raspberry Pi in the next room.

$ git remote -v
server   ssh://git@git.blokhin.us/nick/Texodus.git
gitlab   git@gitlab.com:w512/texodus.git
origin   git@github.com:w512/Texodus.git
rpi5     ssh://git@rpi5-local/nick/Texodus.git

This costs essentially nothing: git remote add once, plus the habit of pushing to all of them. If GitHub disappeared tomorrow along with my account, the commit history would not be affected.

It sounds like a finished answer to "what if". It is an answer to the wrong question.

The code is safe and I still cannot ship

Users do not download a repository. They download a built .dmg, .AppImage, or installer — and those are produced by GitHub Actions.

In my case that is not simply "run the build somewhere else". The Texodus release pipeline contains a non-obvious step: after the AppImage is packaged, the build machine's graphics libraries are stripped out of it, because otherwise the app does not start on recent distributions. That fix exists only inside the workflow file. Building the project locally "the usual way" would hand me an artifact with the old bug back in it — and I would not notice immediately.

That is the real single point of failure. Mirrors protect the history of the code. They do nothing at all for the ability to release and deliver an update.

There is a partial exception. macOS builds already run locally, from a separate script, because Developer ID signing and notarization need a certificate from the local keychain. So one of my three release paths does not depend on GitHub — but for an entirely unrelated reason. That is luck, not planning.

What follows from this

Leaving GitHub entirely is not rational: the audience is there, the issues are there, discovery is there. The question is not how to quit, but how to make an outage mean a delay rather than a standstill. The minimum set looks like this:

• A repository mirror. The cheapest item and, judging by my own case, the most overrated: it takes a minute to set up and covers only part of the problem.
• The ability to run CI locally. Not "in principle possible" — actually verified: the pipeline runs on your own machine and produces the same artifact.
• Artifact export. Releases that exist only as GitHub Releases are unavailable to your users exactly when the platform is unavailable.
• A written emergency release procedure. One document: what to run, where the keys are, where to publish, when the normal path is closed.

The last one I wrote down for myself: I do not have it. Until an outage actually happens, "I roughly remember how this gets built" feels like enough — and that feeling is precisely the dependency nobody closes.

The boring counterexample

The site you are reading did not notice the outage at all. It is built as static files on my laptop and published to my own nginx; GitHub is involved in its life only as one of three code mirrors. Neither Actions nor Pages sits anywhere between the source and the reader.

That is not foresight — it is just the kind of site I find comfortable to run. But the coincidence is instructive: the fewer moving parts belonging to someone else stand between your code and your user, the fewer questions someone else's outage raises.