Kako samostalno hostati Gitea u 2026.: repozitoriji, SSH i sigurne nadogradnje

Ako ste već pokušali samostalno hostati Gitea, vjerojatno vam je poznata frustrirajuća situacija: sučelje se prikazuje, ali ROOT_URL generira poveznice za kloniranje s localhostom ili SSH port nije proslijeđen. Ponovno stvaranje containera rijetko rješava neslaganje između URL-ova, stanja i ovisnosti.

Ovaj vodič koristi jedan konkretan kriterij dovršenosti — klonirati putem HTTPS-a i SSH-a, poslati commit i LFS objekt, otvoriti issue i pokrenuti jedan job na zasebno registriranom Actions runneru. Svaki se odabir konfiguracije procjenjuje prema tom kriteriju, a ne prema zelenoj oznaci containera.

Pronađite svaki trajni bajt u Gitei

Navedite stanje prije stvaranja prvog stvarnog zapisa: repozitorije, LFS objekte, privitke, konfiguraciju i bazu podataka. Montirajte /data prije bootstrapanja, zapišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je ta putanja doista trajna. Potvrdite mount zapisivanjem bezopasnih podataka, zamjenom Gitee i njihovim ponovnim čitanjem.

Snapshoti su vrijedni za brzi rollback, ali potrebna je neovisna sigurnosna kopija ako host ili volume nestane. Vratite podatke u prazno okruženje s pinanom slikom i provjerite prolaze li repozitoriji fsck, preuzimaju li se LFS objekti te odgovaraju li issuei, izdanja i korisničke dozvole stanju prije izrade sigurnosne kopije. Upotrijebite trajna spremišta i snapshote kako biste ta dva mehanizma oporavka zadržali odvojenima.

Izgradite zamjenjiv Gitea container

Sljedeća naredba čini granicu containera vidljivom, bez pretvaranja da osigurava svaku vanjsku uslugu.

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

Prije otvaranja ingressa provjerite razriješeno okruženje, mountove i listener. Za zahtjevniju instalaciju dodajte provjerene postavke povezivanja s bazom Postgres ili MySQL te SSH rutu ako je potrebna; za privatne usluge koristite privatna imena. Uspješno pokretanje završava tek kada možete klonirati putem HTTPS-a i SSH-a, poslati commit i LFS objekt, otvoriti issue i pokrenuti jedan job na zasebno registriranom Actions runneru, a ne kada docker ps ispiše Up.

Odvojite Gitea od njegovih ovisnosti

Zdravlje procesa i zdravlje proizvoda odvojeni su u Gitei. Port 3000 može odgovarati dok transakcija vidljiva korisniku i dalje ne uspijeva. Mrežni ugovor za Giteu čine Postgres ili MySQL za zahtjevniju instalaciju te SSH ruta ako je potrebna. Privatne endpointove zadržite na internom DNS-u, dopustite samo potrebne izlazne pozive i dodijelite Gitei ograničenu servisnu vjerodajnicu.

Ovu provjeru spremnosti koristite nakon značajnih promjena konfiguracije: klonirajte putem HTTPS-a i SSH-a, pošaljite commit i LFS objekt, otvorite issue i pokrenite jedan job na zasebno registriranom Actions runneru. Skupe vanjske provjere nemojte uključivati u liveness probe kako ispad usluge pružatelja ne bi uzrokovao petlju ponovnog pokretanja. Rad na kapacitetu treba pratiti broj repozitorija, pakiranje Git objekata, LFS pohranu, latenciju baze podataka i opterećenje runnera, a ne uobičajene zahtjeve za stranice, jer to bolje odražava stvarno opterećenje Gitee nego zahtjevi za stranice.

TLS je jednostavan; generirani URL-ovi nisu

Izložite jedan HTTPS hostname za Giteu, a sirovi port 3000 zadržite privatnim. Postavite ROOT_URL i SSH_DOMAIN na adrese s kojih korisnici stvarno kloniraju. Time sprječavate da preglednici i API klijenti nauče dvije konkurentske adrese.

Iz čistog klijenta pokrenite provjerenu transakciju i provjerite prvi zahtjev koji ne uspije. Ako su DNS ili TLS pogrešno konfigurirani, upotrijebite vodič za prilagođenu domenu. Tretirajte poruku „ROOT_URL generira poveznice za kloniranje s localhostom ili SSH port nije proslijeđen” kao zasebnu dijagnozu aplikacije nakon što potvrdite ispravnost rute.

Testirajte implementaciju Gitee od početka do kraja

Nemojte promet prvog korisnika koristiti kao test prihvaćanja za Giteu. Pripremite bezopasno ogledno stanje i pokrenite potpunu radnju „kloniraj putem HTTPS-a i SSH-a, pošalji commit i LFS objekt, otvori issue i pokreni jedan job na zasebno registriranom Actions runneru”. Zabilježite točan javni URL, rezultat, referencu slike i interval logova povezan s pokretanjem.

Zamijenite container i ponovite postupak bez ponovne izgradnje podataka. Zatim vratite sustav na prazan host; uvjet oporavka jest da repozitoriji prolaze fsck, da se LFS objekti preuzimaju te da issuei, izdanja i korisničke dozvole odgovaraju stanju prije izrade sigurnosne kopije. Pri svakom prolasku pratite broj repozitorija, pakiranje Git objekata, LFS pohranu, latenciju baze podataka i opterećenje runnera, a ne uobičajene zahtjeve za stranice, te definirajte upozorenje oko pogoršanja transakcije, a ne oko metrika neaktivnog containera.

Jedna završna provjera trebala bi namjerno ne uspjeti: privremeno uskratite testnom identitetu pristup bazi Postgres ili MySQL za zahtjevniju instalaciju te SSH ruti ako je potrebna. Provjerite prepoznaje li rezultirajuća Gitea poruka relevantnu granicu umjesto da pokrene brisanje podataka ili beskonačno ponovno pokretanje. Vratite valjano stanje i potvrdite da ista ogledna transakcija uspijeva. Ovu kratku vježbu zadržite na kontrolnom popisu za izdanje.

Uvježbajte rizičnu promjenu Gitee

Za Giteu pratite transakciju, a ne proces: klonirajte putem HTTPS-a i SSH-a, pošaljite commit i LFS objekt, otvorite issue i pokrenite jedan job na zasebno registriranom Actions runneru. Kombinirajte njezinu latenciju i stopu pogrešaka s brojem repozitorija, pakiranjem Git objekata, LFS pohranom, latencijom baze podataka i opterećenjem runnera, a ne s uobičajenim zahtjevima za stranice, kako bi upozorenje identificiralo ograničenu komponentu.

Proba nadogradnje mora obuhvatiti činjenicu da migracije sheme, hookovi repozitorija, paketi i runneri trećih strana zahtijevaju postupnu nadogradnju Gitee. Vratite podatke, provedite migraciju i pokrenite transakciju prije zamjene u produkciji. Ako ROOT_URL generira poveznice za kloniranje s localhostom ili SSH port nije proslijeđen, nemojte brisati podatke samo da biste dobili zeleno pokretanje; tim redoslijedom usporedite verziju, varijable, mountove i dostupnost ovisnosti.

Zaštitite vrijedni dio Gitee

Nakon prve prijave provjerite što anonimni posjetitelj, obični korisnik i administrator mogu učiniti. Problem s Giteom koji treba izbjeći jest da installer ili prvi administratorski račun ostanu dostupni dulje nego što je potrebno. Planirana je politika zatvoriti installer nakon bootstrapanja, ograničiti administraciju web-mjesta i osigurati da tokeni za registraciju runnera kratko traju.

Prema GITEA__security__SECRET_KEY odnosite se u skladu s njegovom ulogom u Gitei: osjetljive vrijednosti držite izvan Gita, dokumentirajte učinke rotacije i u produkciji nikada nemojte zamijeniti javnim primjerom. Račune ovisnosti držite odvojenima od ljudskih računa, gdje je praktično uskratite nekorišteni egress i ograničite rad pod utjecajem broja repozitorija, pakiranja Git objekata, LFS pohrane, latencije baze podataka i opterećenja runnera, a ne uobičajenih zahtjeva za stranice.

Što bi Dockup trebao automatizirati za Giteu

Za Giteu Dockup može izraditi rutu i TLS certifikat, sačuvati mountove, isporučiti tajne i smjestiti Postgres ili MySQL za zahtjevniju instalaciju te SSH rutu ako je potrebna na privatnoj mreži, uz implementaciju na Dockupu ili povezanim serverima.

Kontrolna točka izdanja i dalje je konkretna transakcija Gitee: klonirajte putem HTTPS-a i SSH-a, pošaljite commit i LFS objekt, otvorite issue i pokrenite jedan job na zasebno registriranom Actions runneru. Također provjerite uvjet oporavka — repozitoriji prolaze fsck, LFS objekti se preuzimaju, a issuei, izdanja i korisničke dozvole odgovaraju stanju prije izrade sigurnosne kopije. Te dvije provjere pokazuju radi li implementacija i može li se sustav oporaviti.

Često postavljana pitanja

Što je Gitei potrebno za produkcijsku implementaciju?

Usmjerite Gitea container na portu 3000 kroz jedan HTTPS origin. Prateći mrežni zahtjev čine Postgres ili MySQL za zahtjevniju instalaciju te SSH ruta ako je potrebna. Nemojte Giteu smatrati spremnom dok ne možete klonirati putem HTTPS-a i SSH-a, poslati commit i LFS objekt, otvoriti issue i pokrenuti jedan job na zasebno registriranom Actions runneru.

Koji Gitea podaci pripadaju sigurnosnoj kopiji?

Učinite /data trajnim i uključite repozitorije, LFS objekte, privitke, konfiguraciju i bazu podataka u isti manifest oporavka. Čisto vraćanje Gitee uspješno je samo kada repozitoriji prolaze fsck, LFS objekti se preuzimaju, a issuei, izdanja i korisničke dozvole odgovaraju stanju prije izrade sigurnosne kopije.

Zahtijeva li Gitea HTTPS iza reverse proxyja?

Za javni origin Gitee koristite HTTPS, a port 3000 zadržite na internoj ruti. Ispravno primijenite postavku Gitee: postavite ROOT_URL i SSH_DOMAIN na adrese s kojih korisnici stvarno kloniraju. Za Giteu HTTPS štiti vjerodajnice ili korisnički sadržaj tijekom prijenosa i održava dosljedno ponašanje klijenta osjetljivo na origin.

Kako treba testirati nadogradnju Gitee?

Vratite trenutno stanje Gitee u izoliranu implementaciju, primijenite kandidatsku verziju i ponovite njezinu transakciju prihvaćanja. Obratite posebnu pozornost jer migracije sheme, hookovi repozitorija, paketi i runneri trećih strana zahtijevaju postupnu nadogradnju Gitee. Prethodnu sliku Gitee zadržite dok ne razumijete granice migracije podataka i rollbacka.