Cum să găzduiești Gitea pe cont propriu în 2026: repositories, SSH și upgrade-uri sigure

Dacă ai încercat deja să găzduiești Gitea pe cont propriu, probabil îți este familiară situația frustrantă: interfața apare, dar ROOT_URL generează linkuri localhost pentru clone sau portul SSH nu este forwardat. Recrearea containerului rezolvă rareori un dezacord între URL-uri, state și dependencies.

Acest ghid folosește un singur criteriu concret de finalizare — clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschiderea unui issue și rularea unui job pe un Actions runner înregistrat separat. Fiecare alegere de configurare este evaluată în funcție de acest criteriu, nu în funcție de un badge verde al containerului.

Identifică fiecare byte persistent din Gitea

Inventariază state-ul înainte de crearea primului record real: repositories, obiecte LFS, atașamente, configurație și database. Montează /data înainte de bootstrap, scrie date de test inofensive și înlocuiește containerul pentru a demonstra că acel path este într-adevăr persistent. Confirmă mount-ul scriind date inofensive, înlocuind Gitea și citindu-le din nou.

Snapshots sunt utile pentru rollback rapid, dar ai nevoie de un backup independent atunci când hostul sau volume-ul dispare. Restaurează într-un mediu gol, folosind imaginea fixată ca versiune, și verifică dacă repositories trec verificarea fsck, obiectele LFS se descarcă, iar issues, releases și permisiunile utilizatorilor corespund stării de dinaintea backupului. Folosește persistent volumes and snapshots pentru a păstra distincte aceste două mecanisme de recovery.

Construiește un container Gitea care poate fi înlocuit

Următoarea comandă face vizibilă limita containerului fără să pretindă că configurează fiecare serviciu extern.

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

Înainte de a deschide ingress-ul, verifică environment-ul rezolvat, mount-urile și listener-ul. Adaugă setările de conexiune verificate pentru Postgres sau MySQL într-o instalare mai aglomerată și o rută SSH dacă este necesar; folosește nume private pentru serviciile private. Un launch reușit se încheie atunci când poți face clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschide un issue și rula un job pe un Actions runner înregistrat separat, nu atunci când docker ps afișează Up.

Separă Gitea de dependencies

Pentru Gitea, health-ul procesului și health-ul produsului sunt lucruri separate. Portul 3000 poate răspunde, în timp ce tranzacția destinată utilizatorului eșuează în continuare. Contractul de rețea pentru Gitea este Postgres sau MySQL într-o instalare mai aglomerată și o rută SSH dacă este necesar. Păstrează endpoint-urile private în DNS intern, permite doar apelurile outbound necesare și oferă-i lui Gitea un service credential cu scope limitat.

Folosește acest exercițiu de readiness după modificări importante de configurare: clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschiderea unui issue și rularea unui job pe un Actions runner înregistrat separat. Nu include verificările externe costisitoare în probele de liveness, pentru ca o indisponibilitate a unui provider să nu provoace un restart loop. Lucrările de capacity planning ar trebui să urmărească numărul de repositories, împachetarea obiectelor Git, storage-ul LFS, latența database-ului și workload-ul runnerului, nu simplele request-uri de pagină, deoarece acestea reflectă mai bine presiunea reală asupra Gitea.

TLS este simplu; URL-urile generate nu sunt

Expune Gitea printr-un singur hostname HTTPS; păstrează portul brut 3000 privat. Setează ROOT_URL și SSH_DOMAIN la adresele de la care utilizatorii fac efectiv clone. Astfel, browserele și clienții API nu vor învăța două adrese concurente.

De pe un client curat, rulează tranzacția cunoscută ca funcțională și inspectează primul request care eșuează. Folosește custom-domain guide când DNS-ul sau TLS-ul este configurat greșit. Tratează „ROOT_URL generează linkuri localhost pentru clone sau portul SSH nu este forwardat” ca pe o diagnosticare separată la nivel de aplicație, după ce ruta a fost verificată.

Demonstrează funcționarea deploymentului Gitea end to end

Nu folosi traficul primului utilizator ca test de acceptance pentru Gitea. Pregătește un state de test inofensiv și rulează acțiunea completă „clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschiderea unui issue și rularea unui job pe un Actions runner înregistrat separat”. Notează URL-ul public exact, rezultatul, referința imaginii și intervalul de loguri asociat rulării.

Înlocuiește containerul și repetă testul fără să reconstruiești datele. Apoi efectuează recovery pe un host gol; condiția de recovery este ca repositories să treacă verificarea fsck, obiectele LFS să se descarce, iar issues, releases și permisiunile utilizatorilor să corespundă stării de dinaintea backupului. La fiecare rundă, urmărește numărul de repositories, împachetarea obiectelor Git, storage-ul LFS, latența database-ului și workload-ul runnerului, nu simplele request-uri de pagină, și definește o alertă în jurul degradării tranzacției, nu în jurul metricilor unui container inactiv.

O verificare finală ar trebui să eșueze intenționat: interzice temporar accesul identității de test la Postgres sau MySQL într-o instalare mai aglomerată și la o rută SSH dacă este necesar. Verifică dacă mesajul Gitea rezultat identifică limita relevantă, în loc să declanșeze ștergerea datelor sau un restart nesfârșit. Restabilește condiția validă și confirmă că aceeași tranzacție de test reușește. Păstrează acest exercițiu scurt în release checklist.

Repetă schimbarea riscantă pentru Gitea

Pentru Gitea, monitorizează o tranzacție, nu un proces: clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschiderea unui issue și rularea unui job pe un Actions runner înregistrat separat. Combină latența și rata de erori cu numărul de repositories, împachetarea obiectelor Git, storage-ul LFS, latența database-ului și workload-ul runnerului, nu cu simplele request-uri de pagină, astfel încât o alertă să identifice componenta limitată.

Repetiția upgrade-ului trebuie să acopere faptul că schema migrations, repository hooks, packages și third-party runners necesită un upgrade Gitea etapizat. Restaurează, migrează și rulează tranzacția înainte de înlocuirea din producție. Dacă ROOT_URL generează linkuri localhost pentru clone sau portul SSH nu este forwardat, nu șterge datele pentru a obține un startup verde; compară în această ordine versiunea, variabilele, mount-urile și reachability-ul dependencies.

Protejează partea valoroasă din Gitea

După primul login, verifică ce poate face fiecare dintre un vizitator anonim, un utilizator obișnuit și un administrator. Problema Gitea care trebuie evitată este păstrarea installerului sau a primului cont de administrator accesibil mai mult timp decât este necesar. Politica dorită este să închizi installerul după bootstrap, să restricționezi administrarea site-ului și să păstrezi tokenurile de înregistrare ale runnerelor cu durată scurtă de viață.

Tratează GITEA__security__SECRET_KEY în funcție de rolul său în Gitea: păstrează valorile sensibile în afara Git, documentează efectele rotației și nu înlocui niciodată, în producție, valoarea cu un exemplu public. Păstrează conturile pentru dependencies separate de conturile umane, refuză egress-ul nefolosit acolo unde este practic și limitează lucrările influențate de numărul de repositories, împachetarea obiectelor Git, storage-ul LFS, latența database-ului și workload-ul runnerului, nu de simplele request-uri de pagină.

Ce ar trebui să automatizeze Dockup pentru Gitea

Pentru Gitea, Dockup poate crea ruta și certificatul TLS, păstra mount-urile, livra secrets și plasa Postgres sau MySQL într-o instalare mai aglomerată și o rută SSH dacă este necesar în networking-ul privat, în timp ce face deployment fie pe Dockup, fie pe servere atașate.

Release gate-ul rămâne tranzacția concretă Gitea: clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschiderea unui issue și rularea unui job pe un Actions runner înregistrat separat. Verifică și condiția de restore — repositories trec verificarea fsck, obiectele LFS se descarcă, iar issues, releases și permisiunile utilizatorilor corespund stării de dinaintea backupului. Aceste două verificări arată dacă deploymentul funcționează și dacă poate fi recuperat.

Întrebări frecvente

De ce are nevoie Gitea pentru un deployment în producție?

Direcționează containerul Gitea de pe portul 3000 printr-un singur origin HTTPS. Cerința de networking asociată este Postgres sau MySQL într-o instalare mai aglomerată și o rută SSH dacă este necesar. Nu considera Gitea ready până când nu poți face clone prin HTTPS și SSH, push pentru un commit și un obiect LFS, deschide un issue și rula un job pe un Actions runner înregistrat separat.

Ce date Gitea trebuie incluse într-un backup?

Persistă /data și include repositories, obiectele LFS, atașamentele, configurația și database-ul în același manifest de recovery. Un restore Gitea curat este reușit doar atunci când repositories trec verificarea fsck, obiectele LFS se descarcă, iar issues, releases și permisiunile utilizatorilor corespund stării de dinaintea backupului.

Are Gitea nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru origin-ul public Gitea și păstrează portul 3000 pe ruta internă. Aplică corect setarea Gitea: setează ROOT_URL și SSH_DOMAIN la adresele de la care utilizatorii fac efectiv clone. Pentru Gitea, HTTPS protejează credentials sau conținutul utilizatorilor în tranzit și păstrează consecvent comportamentul clientului dependent de origin.

Cum trebuie testat un upgrade Gitea?

Restaurează state-ul Gitea actual într-un deployment izolat, aplică versiunea candidat și repetă tranzacția de acceptance. Acordă o atenție deosebită acestui aspect, deoarece schema migrations, repository hooks, packages și third-party runners necesită un upgrade Gitea etapizat. Păstrează imaginea Gitea anterioară până când limitele migrării datelor și ale rollback-ului sunt clare.