Så självhostar du Gitea 2026: repositorier, SSH och säkra uppgraderingar

Om du redan har försökt självhosta Gitea känner du förmodligen igen det frustrerande läget: gränssnittet visas, men ROOT_URL genererar localhost-länkar för kloning eller så vidarebefordras inte SSH-porten. Att återskapa containern löser sällan en konflikt mellan URL:er, tillstånd och beroenden.

Den här genomgången använder ett konkret kriterium för en färdig installation — klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner. Varje konfigurationsval utvärderas mot det kriteriet, inte mot en grön containerstatus.

Hitta alla beständiga byte i Gitea

Lista tillståndet innan den första riktiga posten skapas: repositorier, LFS-objekt, bilagor, konfiguration och databas. Montera /data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Bekräfta monteringen genom att skriva ofarliga data, ersätta Gitea och läsa tillbaka dem.

Snapshots är värdefulla för snabb återställning, men en fristående säkerhetskopia behövs om värden eller volymen försvinner. Återställ till en tom miljö med den låsta image-versionen och verifiera att repositorierna klarar fsck, att LFS-objekt kan laddas ned och att ärenden, releaser och användarbehörigheter överensstämmer med tillståndet före säkerhetskopieringen. Använd beständiga volymer och snapshots för att hålla de två återställningsmekanismerna åtskilda.

Bygg en utbytbar Gitea-container

Följande kommando synliggör containergränsen utan att låtsas konfigurera alla externa tjänster.

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

Innan du öppnar ingressen kontrollerar du den upplösta miljön, monteringar och lyssnare. Lägg till de granskade anslutningsinställningarna för Postgres eller MySQL för en större installation samt en SSH-route vid behov; använd privata namn för privata tjänster. En lyckad start är klar först när du kan klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner — inte när docker ps skriver ut Up.

Separera Gitea från dess beroenden

Processhälsa och produkthälsa är separata i Gitea. Port 3000 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Giteas nätverkskontrakt omfattar Postgres eller MySQL för en större installation samt en SSH-route vid behov. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Gitea en tjänsteinloggning med begränsad behörighet.

Använd följande readiness-test efter betydande konfigurationsändringar: klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner. Håll kostsamma externa kontroller borta från liveness-prober så att ett avbrott hos en leverantör inte orsakar en omstartsloop. Kapacitetsarbetet bör följa antal repositorier, packning av Git-objekt, LFS-lagring, databassvarstid och runner-belastning i stället för vanliga sidförfrågningar, eftersom det bättre speglar Giteas verkliga belastning än sidförfrågningar.

TLS är enkelt – genererade URL:er är det inte

Exponera ett HTTPS-värdnamn för Gitea och håll den råa porten 3000 privat. Ange ROOT_URL och SSH_DOMAIN till de adresser som användarna faktiskt klonar från. Då slipper webbläsare och API-klienter lära sig två konkurrerande adresser.

Kör den verifierade transaktionen från en ren klient och undersök den första begäran som misslyckas. Använd guiden för anpassade domäner när DNS eller TLS är felkonfigurerat. Behandla “ROOT_URL genererar localhost-länkar för kloning eller så vidarebefordras inte SSH-porten” som en separat applikationsdiagnos när routingen väl är bekräftad.

Verifiera Gitea-distributionen från början till slut

Använd inte trafik från den första användaren som acceptanstest för Gitea. Förbered ofarligt exempeldata och kör hela åtgärden ”klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och kör ett jobb på en separat registrerad Actions-runner”. Notera den exakta publika URL:en, resultatet, image-referensen och loggintervallet som hör till körningen.

Ersätt containern och upprepa utan att bygga om data. Återställ därefter till en tom värd; återställningsvillkoret är att repositorierna klarar fsck, att LFS-objekt kan laddas ned och att ärenden, releaser och användarbehörigheter överensstämmer med tillståndet före säkerhetskopieringen. Observera antal repositorier, packning av Git-objekt, LFS-lagring, databassvarstid och runner-belastning i stället för vanliga sidförfrågningar vid varje genomgång, och definiera en alert kring försämrad transaktionskvalitet i stället för kring inaktiva container-mätvärden.

En sista kontroll bör medvetet misslyckas: neka tillfälligt testidentiteten åtkomst till Postgres eller MySQL för en större installation samt till en SSH-route vid behov. Kontrollera att det resulterande Gitea-meddelandet identifierar den relevanta gränsen i stället för att utlösa dataradering eller en oändlig omstart. Återställ det giltiga tillståndet och bekräfta att samma exempeltransaktion lyckas. Behåll denna korta övning i release-checklistan.

Öva på den riskfyllda Gitea-ändringen

För Gitea bör du övervaka en transaktion i stället för en process: klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner. Kombinera dess svarstid och felfrekvens med antal repositorier, packning av Git-objekt, LFS-lagring, databassvarstid och runner-belastning i stället för vanliga sidförfrågningar, så att en alert identifierar den begränsande komponenten.

Uppgraderingsövningen måste ta hänsyn till att schemamigreringar, repository hooks, paket och runners från tredje part kräver en stegvis Gitea-uppgradering. Återställ, migrera och kör transaktionen före bytet i produktion. Om ROOT_URL genererar localhost-länkar för kloning eller så vidarebefordras inte SSH-porten ska du inte radera data för att få en grön start; jämför version, variabler, monteringar och räckvidd till beroenden i den ordningen.

Skydda den värdefulla delen av Gitea

Efter den första inloggningen granskar du vad en anonym besökare, en vanlig användare och en administratör kan göra. Gitea-felet du ska undvika är att låta installationsprogrammet eller det första administratörskontot vara åtkomligt längre än nödvändigt. Den avsedda policyn är att stänga installationsprogrammet efter bootstrap, begränsa webbplatsadministrationen och hålla registreringstokens för runners kortlivade.

Behandla GITEA__security__SECRET_KEY utifrån dess roll i Gitea: håll känsliga värden borta från Git, dokumentera effekterna av rotation och använd aldrig ett publikt exempelvärde i produktion. Håll beroendekonton åtskilda från personliga konton, neka oanvänd utgående trafik där det är praktiskt möjligt och begränsa arbete som påverkas av antal repositorier, packning av Git-objekt, LFS-lagring, databassvarstid och runner-belastning i stället för vanliga sidförfrågningar.

Vad Dockup bör automatisera för Gitea

För Gitea kan Dockup skapa routen och TLS-certifikatet, bevara monteringar, leverera secrets och placera Postgres eller MySQL för en större installation samt en SSH-route vid behov på privat nätverk, samtidigt som distributionen sker till antingen Dockup eller anslutna servrar.

Release-grinden är fortfarande den konkreta Gitea-transaktionen: klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner. Verifiera även återställningsvillkoret — att repositorierna klarar fsck, att LFS-objekt kan laddas ned och att ärenden, releaser och användarbehörigheter överensstämmer med tillståndet före säkerhetskopieringen. Dessa två kontroller visar om distributionen fungerar och om den kan återställas.

Vanliga frågor

Vad behöver Gitea för en produktionsdistribution?

Routa Gitea-containern på port 3000 genom ett enda HTTPS-origin. Det stödjande nätverkskravet är Postgres eller MySQL för en större installation samt en SSH-route vid behov. Anse inte Gitea vara redo förrän du kan klona via HTTPS och SSH, pusha en commit och ett LFS-objekt, öppna ett ärende och köra ett jobb på en separat registrerad Actions-runner.

Vilka Gitea-data ska ingå i en säkerhetskopia?

Gör /data beständig och inkludera repositorier, LFS-objekt, bilagor, konfiguration och databas i samma återställningsmanifest. En ren Gitea-återställning är godkänd först när repositorierna klarar fsck, LFS-objekt kan laddas ned och ärenden, releaser och användarbehörigheter överensstämmer med tillståndet före säkerhetskopieringen.

Kräver Gitea HTTPS bakom en reverse proxy?

Använd HTTPS för det publika Gitea-originet och håll port 3000 på den interna routen. Tillämpa Gitea-inställningen korrekt: ange ROOT_URL och SSH_DOMAIN till de adresser som användarna faktiskt klonar från. För Gitea skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Gitea-uppgradering testas?

Återställ det aktuella Gitea-tillståndet till en isolerad distribution, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom schemamigreringar, repository hooks, paket och runners från tredje part kräver en stegvis Gitea-uppgradering. Behåll den tidigare Gitea-imagen tills datamigreringens och återställningens gränser är förstådda.