Jak v roce 2026 provozovat vlastní Gitea: repozitáře, SSH a bezpečné aktualizace

Pokud jste se už pokoušeli provozovat vlastní Gitea, nejspíš znáte frustrující stav, kdy se zobrazí UI, ale ROOT_URL generuje odkazy pro klonování s localhost nebo není přesměrován SSH port. Opětovné vytvoření kontejneru jen zřídka vyřeší nesoulad mezi URL, stavem a závislostmi.

Tento postup používá jedno konkrétní kritérium dokončení — klonování přes HTTPS a SSH, odeslání commitu a LFS objektu, otevření issue a spuštění jedné úlohy na samostatně registrovaném Actions runneru. Každé konfigurační rozhodnutí posuzujeme podle tohoto kritéria, nikoli podle zeleného indikátoru kontejneru.

Najděte v Gitea všechna trvalá data

Ještě před vytvořením prvního skutečného záznamu si sepište stav: repozitáře, LFS objekty, přílohy, konfiguraci a databázi. Před bootstrapem připojte /data, zapište neškodná testovací data a nahraďte kontejner, abyste ověřili, že je daná cesta skutečně persistentní. Připojení ověřte zápisem neškodných dat, nahrazením Gitea a jejich opětovným načtením.

Snapshoty jsou cenné pro rychlý rollback, ale pokud zmizí hostitel nebo volume, potřebujete nezávislou zálohu. Obnovte data do prázdného prostředí s připnutým image a ověřte, že repozitáře projdou fsck, LFS objekty se stáhnou a issues, releases a oprávnění uživatelů odpovídají stavu před zálohou. K oddělení těchto dvou mechanismů obnovy použijte persistent volumes and snapshots.

Vytvořte nahraditelný kontejner Gitea

Následující příkaz zviditelní hranici kontejneru, aniž by předstíral zajištění všech externích služeb.

docker run -d \
  --name gitea \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v gitea-data:/data \
  -e GITEA__security__SECRET_KEY=replace-with-a-long-random-value \
  gitea/gitea:latest

Před otevřením ingressu zkontrolujte výsledné proměnné prostředí, mounty a listener. U vytíženější instalace doplňte ověřené parametry připojení k Postgres nebo MySQL a v případě potřeby také SSH route; pro privátní služby používejte privátní názvy. Úspěšné spuštění je dokončeno až ve chvíli, kdy můžete klonovat přes HTTPS a SSH, odeslat commit a LFS objekt, otevřít issue a spustit jednu úlohu na samostatně registrovaném Actions runneru — nikoli ve chvíli, kdy docker ps vypíše Up.

Oddělte Gitea od jejích závislostí

Stav procesu a stav produktu jsou u Gitea dvě odlišné věci. Port 3000 může odpovídat, i když transakce z pohledu uživatele stále selhává. Síťová smlouva Gitea zahrnuje Postgres nebo MySQL pro vytíženější instalaci a v případě potřeby také SSH route. Privátní endpointy ponechte na interním DNS, povolte pouze nezbytná odchozí volání a přidělte Gitea service credential s omezeným rozsahem oprávnění.

Po významných změnách konfigurace použijte toto ověření připravenosti: klonujte přes HTTPS a SSH, odešlete commit a LFS objekt, otevřete issue a spusťte jednu úlohu na samostatně registrovaném Actions runneru. Nákladné externí kontroly neumisťujte do liveness probes, aby výpadek poskytovatele nezpůsobil smyčku restartů. Při plánování kapacity sledujte počet repozitářů, balení Git objektů, úložiště LFS, latenci databáze a vytížení runneru namísto běžných požadavků na stránky — tyto metriky lépe odpovídají skutečnému zatížení Gitea než požadavky na stránky.

TLS je snadné, generované URL nikoli

Zpřístupněte Gitea pod jedním HTTPS hostname a raw port 3000 ponechte privátní. ROOT_URL a SSH_DOMAIN nastavte na adresy, které uživatelé skutečně používají ke klonování. Prohlížeče a API clients se tak nedozvědí o dvou konkurenčních adresách.

Z čistého klienta spusťte ověřenou transakci a zkontrolujte první požadavek, který selže. Pokud je problém v DNS nebo TLS, použijte custom-domain guide. Jakmile je route ověřená, berte stav „ROOT_URL generates localhost clone links or the SSH port is not forwarded“ jako samostatnou aplikační diagnózu.

Ověřte nasazení Gitea od začátku do konce

Pro Gitea nepoužívejte jako akceptační test provoz prvního uživatele. Připravte neškodný testovací stav a spusťte kompletní akci „clone over HTTPS and SSH, push a commit and LFS object, open an issue and run one job on a separately registered Actions runner“. Poznamenejte si přesnou veřejnou URL, výsledek, referenci image a interval logů spojený s daným během.

Nahraďte kontejner a test zopakujte bez opětovného sestavení dat. Poté obnovte data na prázdném hostiteli; podmínkou úspěšné obnovy je, že repozitáře projdou fsck, LFS objekty se stáhnou a issues, releases a oprávnění uživatelů odpovídají stavu před zálohou. Při každém průchodu sledujte počet repozitářů, balení Git objektů, úložiště LFS, latenci databáze a vytížení runneru namísto běžných požadavků na stránky a definujte alert pro zhoršení transakce, nikoli pro metriky nečinného kontejneru.

Jedna závěrečná kontrola by měla záměrně selhat: dočasně testovací identitě odeberte přístup k Postgres nebo MySQL pro vytíženější instalaci a v případě potřeby také k SSH route. Ověřte, že výsledná zpráva Gitea identifikuje příslušnou hranici, místo aby spustila mazání dat nebo nekonečný restart. Obnovte platný stav a potvrďte, že stejná testovací transakce znovu proběhne úspěšně. Toto krátké cvičení ponechte v checklistu releasu.

Nacvičte rizikovou změnu Gitea

U Gitea monitorujte transakci, nikoli proces: klonování přes HTTPS a SSH, odeslání commitu a LFS objektu, otevření issue a spuštění jedné úlohy na samostatně registrovaném Actions runneru. Latenci a chybovost kombinujte s počtem repozitářů, balením Git objektů, úložištěm LFS, latencí databáze a vytížením runneru namísto běžných požadavků na stránky, aby alert identifikoval komponentu s omezenou kapacitou.

Nácvik aktualizace musí zahrnovat skutečnost, že migrace schématu, repository hooks, packages a third-party runners vyžadují postupnou aktualizaci Gitea. Před nahrazením produkce proveďte obnovu, migraci a transakční test. Pokud ROOT_URL generuje odkazy pro klonování s localhost nebo není přesměrován SSH port, nemažte data jen proto, aby startup skončil zeleně; v tomto pořadí porovnejte verzi, proměnné, mounty a dostupnost závislostí.

Chraňte to cenné v Gitea

Po prvním přihlášení zkontrolujte, co může anonymní návštěvník, běžný uživatel a administrátor. Selhání, kterému se u Gitea chcete vyhnout, spočívá v tom, že installer nebo první účet administrátora zůstane dostupný déle, než je nutné. Zamýšlená politika je po bootstrapu installer uzavřít, omezit správu webu a nastavit krátkou platnost registračních tokenů runnerů.

S GITEA__security__SECRET_KEY zacházejte podle jeho role v Gitea: citlivé hodnoty uchovávejte mimo Git, zdokumentujte dopady rotace a v produkci nikdy nepoužívejte veřejný příklad. Účty závislostí oddělte od lidských účtů, kde je to praktické zakažte nepotřebný egress a omezte práci ovlivněnou počtem repozitářů, balením Git objektů, úložištěm LFS, latencí databáze a vytížením runneru namísto běžných požadavků na stránky.

Co by měl Dockup automatizovat pro Gitea

U Gitea může Dockup vytvořit route a TLS certifikát, zachovat mounty, doručit secrets a umístit Postgres nebo MySQL pro vytíženější instalaci a v případě potřeby také SSH route do privátní sítě, přičemž nasazení může proběhnout v Dockup nebo na připojených serverech.

Release gate je stále konkrétní transakce Gitea: klonování přes HTTPS a SSH, odeslání commitu a LFS objektu, otevření issue a spuštění jedné úlohy na samostatně registrovaném Actions runneru. Ověřte také podmínku obnovy — repozitáře projdou fsck, LFS objekty se stáhnou a issues, releases a oprávnění uživatelů odpovídají stavu před zálohou. Tyto dvě kontroly ukazují, zda nasazení funguje a zda ho lze obnovit.

Často kladené otázky

Co Gitea potřebuje pro produkční nasazení?

Kontejner Gitea zpřístupněte na portu 3000 prostřednictvím jednoho HTTPS originu. Požadavek na podpůrnou síť tvoří Postgres nebo MySQL pro vytíženější instalaci a v případě potřeby také SSH route. Gitea nepovažujte za připravenou, dokud nemůžete klonovat přes HTTPS a SSH, odeslat commit a LFS objekt, otevřít issue a spustit jednu úlohu na samostatně registrovaném Actions runneru.

Která data Gitea patří do zálohy?

Zachovejte /data a do stejného recovery manifestu zahrňte repozitáře, LFS objekty, přílohy, konfiguraci a databázi. Čistá obnova Gitea je úspěšná pouze tehdy, když repozitáře projdou fsck, LFS objekty se stáhnou a issues, releases a oprávnění uživatelů odpovídají stavu před zálohou.

Vyžaduje Gitea za reverse proxy HTTPS?

Pro veřejný origin Gitea používejte HTTPS a port 3000 ponechte na interní route. Nastavení Gitea aplikujte správně: ROOT_URL a SSH_DOMAIN nastavte na adresy, které uživatelé skutečně používají ke klonování. U Gitea HTTPS chrání přihlašovací údaje nebo obsah uživatelů při přenosu a udržuje konzistentní chování klientů závislé na originu.

Jak testovat aktualizaci Gitea?

Obnovte aktuální stav Gitea do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte akceptační transakci. Věnujte zvláštní pozornost tomu, že migrace schématu, repository hooks, packages a third-party runners vyžadují postupnou aktualizaci Gitea. Předchozí Gitea image ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.