Ako hostovať Gitea vo vlastnej réžii v roku 2026: repozitáre, SSH a bezpečné aktualizácie

Ak ste sa už pokúšali hostovať Gitea vo vlastnej réžii, tento frustrujúci stav vám bude pravdepodobne známy: používateľské rozhranie sa zobrazí, ale ROOT_URL generuje odkazy na klonovanie s localhost alebo port SSH nie je presmerovaný. Opätovné vytvorenie kontajnera zriedka vyrieši nesúlad medzi URL adresami, stavom a závislosťami.

Tento postup používa jedno konkrétne kritérium úspešného dokončenia — klonovanie cez HTTPS a SSH, odoslanie commitu a objektu LFS, otvorenie issue a spustenie jednej úlohy na samostatne registrovanom Actions runneri. Každé konfiguračné rozhodnutie sa posudzuje podľa tohto kritéria, nie podľa zelenej značky kontajnera.

Nájdite všetky trvalé dáta v Gitea

Ešte pred vytvorením prvého skutočného záznamu si spíšte stav: repozitáre, objekty LFS, prílohy, konfiguráciu a databázu. Pred bootstrapom pripojte /data, zapíšte neškodné vzorové dáta a nahraďte kontajner, aby ste overili, že táto cesta je skutočne persistentná. Pripojenie potvrďte zápisom neškodných dát, nahradením Gitea a ich opätovným načítaním.

Snapshoty sú užitočné na rýchly rollback, no v prípade straty hostiteľa alebo volume potrebujete aj nezávislú zálohu. Obnovte dáta do prázdneho prostredia s pripnutým image a overte, že repozitáre prejdú kontrolou fsck, objekty LFS sa stiahnu a issue, releases a oprávnenia používateľov zodpovedajú stavu pred zálohou. Použite persistent volumes and snapshots, aby tieto dva mechanizmy obnovy zostali oddelené.

Vytvorte Gitea kontajner, ktorý možno jednoducho nahradiť

Nasledujúci príkaz zviditeľní hranicu kontajnera bez toho, aby predstieral provisionovanie všetkých externých služieb.

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

Pred otvorením ingressu skontrolujte výsledné premenné prostredia, mounty a listener. Pri vyťaženejšej inštalácii doplňte overené nastavenia pripojenia pre Postgres alebo MySQL a podľa potreby aj SSH route; pre súkromné služby používajte private names. Úspešné spustenie je dokončené až vtedy, keď môžete klonovať cez HTTPS a SSH, odoslať commit a objekt LFS, otvoriť issue a spustiť jednu úlohu na samostatne registrovanom Actions runneri — nie vtedy, keď docker ps vypíše Up.

Oddeľte Gitea od jej závislostí

Pre Gitea sú health procesu a health produktu dve odlišné veci. Port 3000 môže odpovedať, aj keď transakcia z pohľadu používateľa stále zlyháva. Sieťový kontrakt pre Gitea tvorí Postgres alebo MySQL pri vyťaženejšej inštalácii a SSH route podľa potreby. Súkromné endpointy ponechajte na internom DNS, povoľte iba potrebné odchádzajúce spojenia a Gitea prideliť credential s obmedzeným rozsahom oprávnení.

Po významných zmenách konfigurácie použite tento readiness test: klonovanie cez HTTPS a SSH, odoslanie commitu a objektu LFS, otvorenie issue a spustenie jednej úlohy na samostatne registrovanom Actions runneri. Náročné externé kontroly ponechajte mimo liveness probes, aby výpadok poskytovateľa nespôsobil slučku reštartov. Pri plánovaní kapacity sledujte počet repozitárov, balenie Git objektov, úložisko LFS, latenciu databázy a vyťaženie runnera, nie bežné požiadavky na stránky — tieto metriky lepšie vystihujú skutočné zaťaženie Gitea.

TLS je jednoduché, generované URL už nie

Pre Gitea vystavte jeden HTTPS hostname a port 3000 ponechajte súkromný. Nastavte ROOT_URL a SSH_DOMAIN na adresy, cez ktoré používatelia skutočne klonujú. Zabránite tak tomu, aby sa prehliadače a API clients dozvedeli o dvoch konkurenčných adresách.

Z čistého klienta spustite overenú transakciu a skontrolujte prvú požiadavku, ktorá zlyhá. Ak je problém v DNS alebo TLS, použite custom-domain guide. Hlásenie „ROOT_URL generates localhost clone links or the SSH port is not forwarded“ riešte ako samostatnú diagnostiku aplikácie až po overení route.

Otestujte nasadenie Gitea od začiatku do konca

Premávku prvého používateľa nepoužívajte ako akceptačný test pre Gitea. Pripravte neškodný vzorový stav a spustite kompletnú akciu „clone over HTTPS and SSH, push a commit and LFS object, open an issue and run one job on a separately registered Actions runner“. Zaznamenajte presnú verejnú URL, výsledok, referenciu image a interval logov spojený s týmto behom.

Nahraďte kontajner a test zopakujte bez opätovného vytvárania dát. Potom obnovte systém na prázdnom hostiteľovi; podmienkou obnovy je, aby repozitáre prešli kontrolou fsck, objekty LFS sa stiahli a issue, releases a oprávnenia používateľov zodpovedali stavu pred zálohou. Pri každom priechode sledujte počet repozitárov, balenie Git objektov, úložisko LFS, latenciu databázy a vyťaženie runnera, nie bežné požiadavky na stránky, a alert nastavte na zhoršenie transakcie, nie na metriky nečinného kontajnera.

Jedna záverečná kontrola by mala zámerne zlyhať: dočasne odoberte testovacej identite prístup k Postgres alebo MySQL pri vyťaženejšej inštalácii a k SSH route podľa potreby. Overte, že výsledná správa Gitea identifikuje príslušnú hranicu namiesto spustenia mazania dát alebo nekonečného reštartovania. Obnovte platné podmienky a potvrďte, že rovnaká vzorová transakcia opäť prejde. Toto krátke cvičenie ponechajte v release checklist.

Nacvičte rizikovú zmenu v Gitea

V prípade Gitea sledujte transakciu, nie proces: klonovanie cez HTTPS a SSH, odoslanie commitu a objektu LFS, otvorenie issue a spustenie jednej úlohy na samostatne registrovanom Actions runneri. Jej latenciu a chybovosť kombinujte s počtom repozitárov, balením Git objektov, úložiskom LFS, latenciou databázy a vyťažením runnera, nie s bežnými požiadavkami na stránky, aby alert identifikoval komponent s nedostatkom kapacity.

Nácvik aktualizácie musí zohľadniť, že migrácie schémy, hooks repozitárov, packages a third-party runnery vyžadujú postupnú aktualizáciu Gitea. Pred nahradením produkčnej inštalácie obnovte dáta, vykonajte migráciu a spustite transakciu. Ak ROOT_URL generuje odkazy na klonovanie s localhost alebo port SSH nie je presmerovaný, nemažte dáta len preto, aby štart vyzeral úspešne; v uvedenom poradí porovnajte verziu, premenné, mounty a dostupnosť závislostí.

Chráňte najcennejšiu časť Gitea

Po prvom prihlásení skontrolujte, čo môže vykonať anonymný návštevník, bežný používateľ a administrátor. Chybou v Gitea, ktorej sa treba vyhnúť, je ponechať installer alebo prvý admin účet dostupný dlhšie, než je nevyhnutné. Zamýšľaná politika je po bootstrapovaní installer uzavrieť, obmedziť správu webu a nastaviť krátku platnosť registračných tokenov runnerov.

S GITEA__security__SECRET_KEY zaobchádzajte podľa jeho úlohy v Gitea: citlivé hodnoty uchovávajte mimo Git, zdokumentujte účinky rotácie a v produkcii nikdy nepoužívajte verejný príklad. Účty závislostí oddeľte od účtov ľudí, podľa možností zakážte nepotrebný egress a obmedzte prácu ovplyvnenú počtom repozitárov, balením Git objektov, úložiskom LFS, latenciou databázy a vyťažením runnera, nie bežnými požiadavkami na stránky.

Čo by mal Dockup automatizovať pre Gitea

Pre Gitea môže Dockup vytvoriť route a TLS certifikát, zachovať mounty, doručiť secrets a umiestniť Postgres alebo MySQL pri vyťaženejšej inštalácii a SSH route podľa potreby do private network, pričom nasadenie môže prebehnúť v Dockup alebo na pripojených serveroch.

Release gate však stále tvorí konkrétna transakcia Gitea: klonovanie cez HTTPS a SSH, odoslanie commitu a objektu LFS, otvorenie issue a spustenie jednej úlohy na samostatne registrovanom Actions runneri. Overte aj podmienku obnovy — repozitáre prejdú kontrolou fsck, objekty LFS sa stiahnu a issue, releases a oprávnenia používateľov zodpovedajú stavu pred zálohou. Tieto dve kontroly ukážu, či nasadenie funguje a či ho možno obnoviť.

Často kladené otázky

Čo Gitea potrebuje na produkčné nasadenie?

Kontajner Gitea sprístupnite na porte 3000 prostredníctvom jedného HTTPS originu. Podpornou sieťovou požiadavkou je Postgres alebo MySQL pri vyťaženejšej inštalácii a SSH route podľa potreby. Gitea nepovažujte za pripravenú, kým nemôžete klonovať cez HTTPS a SSH, odoslať commit a objekt LFS, otvoriť issue a spustiť jednu úlohu na samostatne registrovanom Actions runneri.

Ktoré dáta Gitea patria do zálohy?

Zachovávajte /data a do rovnakého recovery manifestu zahrňte repozitáre, objekty LFS, prílohy, konfiguráciu a databázu. Čistá obnova Gitea je úspešná iba vtedy, keď repozitáre prejdú kontrolou fsck, objekty LFS sa stiahnu a issue, releases a oprávnenia používateľov zodpovedajú stavu pred zálohou.

Vyžaduje Gitea za reverse proxy HTTPS?

Pre verejný origin Gitea používajte HTTPS a port 3000 ponechajte na internej route. Nastavenie Gitea aplikujte správne: ROOT_URL a SSH_DOMAIN nastavte na adresy, cez ktoré používatelia skutočne klonujú. HTTPS v Gitea chráni credentials alebo obsah používateľov pri prenose a udržiava konzistentné správanie klienta citlivé na origin.

Ako testovať aktualizáciu Gitea?

Obnovte aktuálny stav Gitea do izolovaného nasadenia, aplikujte kandidátnu verziu a zopakujte akceptačnú transakciu. Venujte tomu osobitnú pozornosť, pretože migrácie schémy, hooks repozitárov, packages a third-party runnery vyžadujú postupnú aktualizáciu Gitea. Predchádzajúci image Gitea ponechajte, kým nebudete rozumieť hranici migrácie dát a rollbacku.