GitHub pro nás nebyl jen místo, kde leží kód. Byl placeným základem celé naší vývojové infrastruktury. Uchovával zdrojové kódy, issues a review, spouštěl testy, release workflow i nasazení a přes OAuth zajišťoval přihlášení do administrací našich vlastních aplikací.
Před více než týdnem, 30. září 2026, jsme k tomu všemu ztratili přístup.
Najednou a bez varování.
Rutinní úklid, který skončil suspendací
Začalo to úklidem, který jsme dlouho odkládali. Organizace i enterprise účet Studio81 Labs byly navázané na naše osobní účty a my jsme chtěli konečně oddělit firemní a soukromé.
Založili jsme proto firemní účty a převedli na ně vlastnictví organizace i enterprise. Nastavili jsme SSH podpisy commitů, napojili firemní Codex na code review a zaplatili za nové uživatelské místo — navíc k enterprise předplatnému, které jsme už měli zaplacené.
Zhruba hodinu po dokončení byla celá organizace nedostupná. Všechny repozitáře, issues, pull requesty i nastavení. Nové firemní účty byly suspendované.
Čtyři tickety, žádný člověk
Postupně jsme otevřeli čtyři tickety na podporu GitHubu. Na každý přišla stejná automatická, obecná odpověď. Zkusili jsme věc eskalovat. Požádali jsme také o vrácení platby za dodatečné místo, které jsme reálně využili zhruba hodinu.
V době psaní tohoto článku uplynul od suspendace více než týden. Za tu dobu jsme od GitHubu nedostali jedinou odpověď od člověka — žádné vysvětlení, žádnou informaci o dalším postupu ani reakci na žádost o refundaci.
Důvod suspendace proto neznáme. Tušíme, že kombinace nových účtů, převodu vlastnictví a platby v krátkém sledu mohla spustit automatickou ochranu proti zneužití. Je to ale jen naše domněnka, ne vysvětlení.
Popsat můžeme dopady a to, co jsme museli udělat, abychom mohli pokračovat v práci.
Dopad přesáhl samotný Git
Ztráta přístupu k repozitářům byla jen část problému. Ztrátou přístupu k organizaci se zastavily i navázané procesy — CI, release workflow a nasazení. Všechny naše projekty měly deploy postavený na GitHubu. Přestalo fungovat také přihlašování přes GitHub OAuth, které jsme používali ve všech projektových administracích. Ztratili jsme tak běžný přístup do administrací i možnost spravovat samotné OAuth aplikace.
Aplikace i servery dál běžely. Když se ale v některé z nich objevil problém, neměli jsme běžnou cestu, jak ho opravit a vydat novou verzi.
Zablokovaný tak nebyl jen vývoj produktů. Zablokované byly i běžné postupy pro správu a vydávání našich aplikací.
Právě tahle provázanost se ukázala jako zásadní. Jeden dodavatel současně zajišťoval několik služeb a jejich společný výpadek jsme neměli dostatečně pokrytý.
Čekat, nebo odejít
Bez odpovědi podpory jsme nemohli dál čekat. OneDev jsme začali připravovat zhruba druhý den po výpadku. I kdyby nám přístup později vrátili, nevěděli bychom, proč jsme o něj přišli, ani jestli se to nestane znovu.
Rozhodli jsme se proto převzít provoz vývojové platformy a přesunout repozitáře i CI/CD na vlastní infrastrukturu s OneDev.
Migrace na OneDev
Základní přesun repozitářů a obnovení CI/CD zabraly zhruba čtyři dny. Další integrace jsme dokončovali postupně. Celá migrace znamenala:
- obnovit repozitáře z lokálních klonů,
- převést CI/CD a nastavit agenty pro buildy,
- obnovit secrets a konfiguraci prostředí,
- znovu napojit nasazení, monitoring a další integrace,
- ověřit stagingové i produkční release postupy,
- nahradit přihlášení do všech projektových administrací — z GitHub OAuth jsme přešli na Google Workspace.
Lokální Git klony byly zásadní pomoc, zálohou vývojové platformy ale nejsou. Zachovaly kód a historii, které jsme měli stažené. Neobsahovaly však issues, komentáře z review, nastavení organizace, secrets ani historii běhů CI.
A pomohou jen tam, kde nějaký klon existuje. Jeden archivovaný projekt jsme lokálně neměli. K němu zatím nemáme přístup a bez obnovení účtu ho nemáme z čeho obnovit.
Nejhůř na tom byly issues. Část z nich jsme nakonec zrekonstruovali z archivovaných sessions našich AI agentů — v jejich záznamech zůstalo zadání i diskuse k issues, na kterých pracovali. Úplné to není a nebyla to záloha, kterou bychom plánovali.
Byla to šťastná náhoda.
To všechno byla práce navíc v době, kterou jsme chtěli věnovat vývoji produktů.
Co měníme do budoucna
Z této zkušenosti nám vychází několik konkrétních opatření:
- Nezávislé zálohy repozitářů i projektových dat — včetně issues, ne jen kódu.
- Vývojová platforma nesmí být jedinou cestou přihlášení do provozních administrací.
- Zdokumentovaný postup obnovy CI/CD a přístup k potřebným klíčům mimo samotnou platformu.
- Ověřovat obnovitelnost, ne pouze existenci záloh.
- Čerstvá záloha před každou změnou účtů nebo vlastnictví — i před takovou, která vypadá rutinně.
Vlastní infrastruktura není zadarmo. Vyžaduje údržbu, monitoring a zálohování a převzetím provozu přebíráme i tuto odpovědnost.
Je to ale odpovědnost, kterou máme ve svých rukou.
Co čekáme od placeného dodavatele
Nečekáme, že každé rozhodnutí automatické ochrany bude správné. Automatika se mýlí a chápeme, proč existuje.
Od placeného dodavatele ale čekáme možnost požádat o přezkoumání takového zásahu a dostat srozumitelnou odpověď. Když dodavatel zákazníkovi zásadně omezí podnikání, je srozumitelná komunikace a možnost situaci vysvětlit to nejmenší, co by měl nabídnout.
Více než týden automatických odpovědí na čtyři tickety tomu neodpovídá.
Jakmile dostaneme vyjádření GitHubu nebo se změní stav přístupu či refundace, článek aktualizujeme.
— Studio81