GitHub wasn’t just where our code lived. We paid for GitHub and relied on it as the foundation of our entire development infrastructure. It held our source code, issues and reviews, ran our tests, release workflows and deployments, and — through OAuth — handled sign-in to the admin panels of our own apps.
On 30 September 2026, more than a week ago, we lost access to all of it. Suddenly, and without warning.
Routine housekeeping that ended in a suspension
It started with some housekeeping we’d been putting off. The Studio81 Labs organization and enterprise account were tied to our personal accounts, and we finally wanted to separate our company and personal accounts.
So we created company accounts and transferred ownership of the organization and the enterprise to them. We configured SSH commit signing, set up Codex code review using our company account, and paid for a new seat — on top of the enterprise subscription we were already paying for.
About an hour after we finished, we had lost access to the entire organization. Every repository, issue, pull request and setting. The new company accounts were suspended.
Four tickets, no human
We opened four support tickets with GitHub, one after another. Each got the same automated, generic reply. We tried to escalate. We also asked for a refund for the extra seat, which we’d actually used for about an hour.
At the time of writing, more than a week has passed since the suspension. In that time we haven’t received a single reply from a person at GitHub — no explanation, no information about next steps, and no response to the refund request.
So we don’t know why it happened. Our guess is that new accounts, an ownership transfer and a payment in quick succession tripped an automated abuse check. But that’s our assumption, not an explanation.
What we can describe is the impact, and what we had to do to keep working.
The impact went far beyond Git
Losing access to the repositories was only part of the problem. It also stopped everything wired to the organization — CI, release workflows and deployments. Every one of our projects deployed through GitHub. Sign-in through GitHub OAuth, which we used for the admin panels of all our projects, stopped working too. We lost normal access to the admin panels as well as the ability to manage the OAuth apps themselves.
The apps and servers kept running. But when something broke in one of them, we had no normal way to fix it and ship a new version.
It didn’t just block product development. It also blocked our normal procedures for managing and releasing our apps.
That coupling turned out to be the real issue. One vendor was providing several services at once, and we hadn’t adequately planned for all of them failing together.
Wait, or leave
Without an answer from support, we couldn’t keep waiting. We started setting up OneDev around the second day after the outage. Even if access came back later, we wouldn’t know why we lost it or whether it would happen again.
So we decided to take over running our development platform and move repositories and CI/CD to our own infrastructure running OneDev.
Migrating to OneDev
Moving the repositories and restoring CI/CD took about four days. We completed the remaining integrations gradually after that. The whole migration meant:
- restoring repositories from local clones,
- porting CI/CD and setting up build agents,
- restoring secrets and environment configuration,
- reconnecting deployments, monitoring and other integrations,
- re-verifying staging and production release procedures,
- replacing sign-in to every project admin panel — we moved from GitHub OAuth to Google Workspace.
Local Git clones were a huge help, but they are not a backup of a development platform. They preserved the code and history we had pulled. They didn’t contain issues, review comments, organization settings, secrets or CI run history.
And they only help where a clone exists. One archived project wasn’t on any of our machines. We still have no access to it, and without the account being restored we have nothing to restore it from.
Issues were the worst part. We ended up reconstructing some of them from the archived sessions of our AI agents — their logs still held the descriptions and discussions of the issues they’d worked on. It isn’t complete, and it was never a backup we’d planned.
It was a lucky accident.
All of this was extra work, in time we wanted to spend building products.
What we’re changing
A few concrete measures came out of this:
- Independent backups of repositories and project data — including issues, not just code.
- The development platform must not be the only way to sign in to operational admin panels.
- A documented CI/CD recovery procedure, with access to the necessary keys outside the platform itself.
- Verify that backups can actually be restored.
- A fresh backup before any account or ownership change — even one that looks routine.
Self-hosting isn’t free. It needs maintenance, monitoring and backups, and by taking over operations we take on that responsibility too.
But it’s a responsibility that’s in our own hands.
What we expect from a paid vendor
We don’t expect every automated abuse decision to be right. Automation makes mistakes, and we understand why it exists.
But from a paid vendor we do expect a way to request a review of an action like this and to get a clear answer. When a vendor seriously disrupts a customer’s business, clear communication and a chance to explain the situation are the least it should offer.
More than a week of automated replies to four tickets doesn’t meet that bar.
As soon as we hear from GitHub, or the status of our access or refund changes, we’ll update this post.
— Studio81