Sådan selvhoster du Gitea i 2026: repositories, SSH og sikre opgraderinger

Hvis du allerede har forsøgt at selvhoste Gitea, kender du sandsynligvis den frustrerende situation: Brugerfladen vises, men ROOT_URL genererer localhost-links til kloning, eller SSH-porten bliver ikke videresendt. Det løser sjældent problemet at oprette containeren igen, hvis der er uoverensstemmelse mellem URL'er, state og afhængigheder.

Denne gennemgang bruger ét konkret kriterium for, hvornår installationen er færdig — klon over HTTPS og SSH, push et commit og et LFS-objekt, opret en issue, og kør ét job på en separat registreret Actions-runner. Hvert konfigurationsvalg vurderes ud fra dette kriterium og ikke ud fra et grønt container-badge.

Find alle persistente bytes i Gitea

Kortlæg state, før den første reelle post oprettes: repositories, LFS-objekter, vedhæftede filer, konfiguration og database. Montér /data før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive ufarlige data, udskifte Gitea og læse dataene tilbage.

Snapshots er værdifulde til hurtig rollback, men du har brug for en uafhængig backup, hvis hosten eller volumen forsvinder. Gendan til et tomt miljø med det pinnede image, og kontrollér, at repositories består fsck, at LFS-objekter kan downloades, og at issues, releases og brugerrettigheder stemmer overens med tilstanden før backup. Brug persistent volumes og snapshots, så de to recovery-mekanismer holdes adskilt.

Byg en Gitea-container, der kan udskiftes

Følgende kommando synliggør containerens grænse uden at foregive, at alle eksterne services provisioneres.

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

Før du åbner for ingress, skal du kontrollere den evaluerede konfiguration, mounts og listeneren. Tilføj de gennemgåede forbindelsesindstillinger til Postgres eller MySQL ved en større installation samt en SSH-route, hvis det er nødvendigt. Brug private navne til private services. En vellykket opstart er først gennemført, når du kan klone over HTTPS og SSH, pushe et commit og et LFS-objekt, oprette en issue og køre ét job på en separat registreret Actions-runner — ikke når docker ps viser Up.

Adskil Gitea fra dets afhængigheder

Processtatus og produktstatus er to forskellige ting for Gitea. Port 3000 kan svare, selv om den brugerrettede transaktion stadig fejler. Giteas netværkskontrakt omfatter Postgres eller MySQL ved en større installation samt en SSH-route, hvis det er nødvendigt. Hold private endpoints på intern DNS, tillad kun nødvendige udgående forbindelser, og giv Gitea en afgrænset servicekonto.

Brug denne readiness-øvelse efter væsentlige konfigurationsændringer: Klon over HTTPS og SSH, push et commit og et LFS-objekt, opret en issue, og kør ét job på en separat registreret Actions-runner. Hold dyre eksterne checks ude af liveness probes, så et nedbrud hos en provider ikke udløser en restart-loop. Kapacitetsarbejde bør følge antallet af repositories, Git-objektpakning, LFS-storage, databaselatens og runner-belastning i stedet for almindelige sideforespørgsler. Det afspejler Giteas reelle belastning bedre end sideforespørgsler.

TLS er nemt; genererede URL'er er ikke

Eksponér ét HTTPS-hostnavn til Gitea, og hold den rå port 3000 privat. Indstil ROOT_URL og SSH_DOMAIN til de adresser, som brugerne rent faktisk kloner fra. Det forhindrer browsere og API-klienter i at lære to konkurrerende adresser.

Kør den kendte, velfungerende transaktion fra en ren klient, og undersøg den første request, der fejler. Brug guiden til custom domains, når DNS eller TLS er forkert. Behandl “ROOT_URL generates localhost clone links or the SSH port is not forwarded” som en separat applikationsdiagnose, når routen er dokumenteret.

Verificér Gitea-installationen fra ende til anden

Brug ikke trafik fra den første bruger som acceptancetest for Gitea. Forbered ufarlig eksempel-state, og kør den komplette handling “klon over HTTPS og SSH, push et commit og LFS-objekt, opret en issue, og kør ét job på en separat registreret Actions-runner”. Notér den nøjagtige offentlige URL, resultatet, image-referencen og det loginterval, der er knyttet til kørslen.

Udskift containeren, og gentag uden at genopbygge data. Gendan derefter til en tom host. Recovery-betingelsen er, at repositories består fsck, at LFS-objekter kan downloades, og at issues, releases og brugerrettigheder stemmer overens med tilstanden før backup. Overvåg antallet af repositories, Git-objektpakning, LFS-storage, databaselatens og runner-belastning i stedet for almindelige sideforespørgsler ved hver gennemgang, og definér en alarm omkring forringelse af transaktionen frem for inaktive containermetrikker.

Én sidste kontrol bør med vilje fejle: Afvis midlertidigt testidentitetens adgang til Postgres eller MySQL ved en større installation samt en SSH-route, hvis det er nødvendigt. Kontrollér, at den resulterende Gitea-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en endeløs genstart. Gendan den gyldige tilstand, og bekræft, at den samme eksempeltransaktion lykkes. Behold denne korte øvelse i release-tjeklisten.

Øv den risikable Gitea-ændring

For Gitea skal du overvåge en transaktion i stedet for en proces: Klon over HTTPS og SSH, push et commit og et LFS-objekt, opret en issue, og kør ét job på en separat registreret Actions-runner. Kombinér transaktionens latens og fejlrate med antallet af repositories, Git-objektpakning, LFS-storage, databaselatens og runner-belastning i stedet for almindelige sideforespørgsler, så en alarm identificerer den komponent, der er under pres.

Opgraderingsøvelsen skal tage højde for, at schema-migreringer, repository-hooks, packages og tredjeparts-runnere kræver en trinvist gennemført Gitea-opgradering. Gendan, migrér, og kør transaktionen før udskiftning i produktion. Hvis ROOT_URL genererer localhost-links til kloning, eller SSH-porten ikke bliver videresendt, må du ikke slette data for at få en grøn opstart. Sammenlign version, variabler, mounts og tilgængelighed til afhængigheder i den rækkefølge.

Beskyt den værdifulde del af Gitea

Efter det første login skal du gennemgå, hvad en anonym besøgende, en almindelig bruger og en administrator hver især kan gøre. Den Gitea-fejl, du skal undgå, er at lade installationsprogrammet eller den første administratorkonto være tilgængelig længere end nødvendigt. Den tilsigtede politik er at lukke installationsprogrammet efter bootstrap, begrænse site-administration og holde registreringstokens til runners kortlivede.

Behandl GITEA__security__SECRET_KEY ud fra dets rolle i Gitea: Hold følsomme værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Hold afhængighedskonti adskilt fra menneskelige konti, afvis ubrugt egress, hvor det er praktisk, og begræns arbejde, der påvirkes af antallet af repositories, Git-objektpakning, LFS-storage, databaselatens og runner-belastning i stedet for almindelige sideforespørgsler.

Hvad Dockup bør automatisere for Gitea

For Gitea kan Dockup oprette routen og TLS-certifikatet, bevare mounts, levere secrets og placere Postgres eller MySQL ved en større installation samt en SSH-route, hvis det er nødvendigt, på et privat netværk, mens deploymentet sker på enten Dockup eller tilknyttede servere.

Release-gaten er stadig den konkrete Gitea-transaktion: Klon over HTTPS og SSH, push et commit og et LFS-objekt, opret en issue, og kør ét job på en separat registreret Actions-runner. Kontrollér også recovery-betingelsen — repositories består fsck, LFS-objekter kan downloades, og issues, releases og brugerrettigheder stemmer overens med tilstanden før backup. De to kontroller viser, om deploymentet fungerer, og om det kan gendannes.

Ofte stillede spørgsmål

Hvad kræver Gitea til en produktionsinstallation?

Route Gitea-containeren på port 3000 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres eller MySQL ved en større installation samt en SSH-route, hvis det er nødvendigt. Erklær ikke Gitea for klar, før du kan klone over HTTPS og SSH, pushe et commit og et LFS-objekt, oprette en issue og køre ét job på en separat registreret Actions-runner.

Hvilke Gitea-data skal med i en backup?

Persistér /data, og medtag repositories, LFS-objekter, vedhæftede filer, konfiguration og database i det samme recovery-manifest. En ren Gitea-gendannelse er kun vellykket, når repositories består fsck, LFS-objekter kan downloades, og issues, releases og brugerrettigheder stemmer overens med tilstanden før backup.

Kræver Gitea HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Gitea-origin, og behold port 3000 på den interne route. Anvend Gitea-indstillingen korrekt: Indstil ROOT_URL og SSH_DOMAIN til de adresser, som brugerne rent faktisk kloner fra. For Gitea beskytter HTTPS legitimationsoplysninger eller brugerindhold under transport og holder origin-følsom klientadfærd konsistent.

Hvordan bør en Gitea-opgradering testes?

Gendan den aktuelle Gitea-state til et isoleret deployment, anvend kandidatversionen, og gentag acceptancetransaktionen. Vær særligt opmærksom, fordi schema-migreringer, repository-hooks, packages og tredjeparts-runnere kræver en trinvist gennemført Gitea-opgradering. Behold det tidligere Gitea-image, indtil grænsen for datamigrering og rollback er forstået.