Gitea zelf hosten in 2026: repositories, SSH en veilige upgrades
Implementeer Gitea met de juiste poort, persistente opslag, TLS, authenticatie en back-ups. Los problemen op waarbij ROOT_URL in productie localhost-clonelinks genereert.
Als je al eens hebt geprobeerd Gitea zelf te hosten, herken je deze frustrerende situatie waarschijnlijk: de UI verschijnt, maar ROOT_URL genereert localhost-clonelinks of de SSH-poort wordt niet doorgestuurd. De container opnieuw aanmaken lost een verschil tussen URL's, status en dependencies zelden op.
Deze walkthrough gebruikt één concreet criterium voor voltooiing: clonen via HTTPS en SSH, een commit en LFS-object pushen, een issue openen en één job uitvoeren op een afzonderlijk geregistreerde Actions-runner. Elke configuratiekeuze wordt aan dat criterium getoetst, niet aan een groen containerbadgetje.
Zoek elke persistente byte in Gitea
Breng de status in kaart voordat het eerste echte record wordt aangemaakt: repositories, LFS-objecten, bijlagen, configuratie en database. Mount /data vóór de bootstrap, schrijf onschadelijke voorbeeldgegevens en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Bevestig de mount door onschadelijke gegevens te schrijven, Gitea te vervangen en de gegevens opnieuw uit te lezen.
Snapshots zijn waardevol voor snel terugdraaien, maar je hebt een onafhankelijke back-up nodig wanneer de host of het volume verdwijnt. Herstel naar een lege omgeving met de vastgezette image en controleer of repositories fsck doorstaan, LFS-objecten kunnen worden gedownload en issues, releases en gebruikersrechten overeenkomen met de toestand vóór de back-up. Gebruik persistente volumes en snapshots om die twee herstelmechanismen gescheiden te houden.
Bouw een vervangbare Gitea-container
Met de volgende opdracht wordt de containergrens zichtbaar, zonder te doen alsof alle externe services worden ingericht.
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
Controleer vóór het openen van ingress de opgeloste environment, mounts en listener. Voeg voor een drukkere installatie de gecontroleerde verbindingsinstellingen voor Postgres of MySQL toe, evenals een SSH-route als dat nodig is; gebruik private namen voor private services. Een succesvolle start is pas voltooid wanneer je via HTTPS en SSH kunt clonen, een commit en LFS-object kunt pushen, een issue kunt openen en één job kunt uitvoeren op een afzonderlijk geregistreerde Actions-runner — niet wanneer docker ps Up toont.
Scheid Gitea van zijn dependencies
Processtatus en productstatus zijn bij Gitea twee verschillende zaken. Poort 3000 kan antwoorden terwijl de transactie vanuit het perspectief van de gebruiker nog steeds mislukt. Het netwerkcontract voor Gitea bestaat uit Postgres of MySQL voor een drukkere installatie en een SSH-route als dat nodig is. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Gitea een servicecredential met beperkte scope.
Gebruik deze readiness-oefening na betekenisvolle configuratiewijzigingen: clonen via HTTPS en SSH, een commit en LFS-object pushen, een issue openen en één job uitvoeren op een afzonderlijk geregistreerde Actions-runner. Houd kostbare externe controles buiten liveness-probes, zodat een storing bij een provider geen restart-loop veroorzaakt. Richt capaciteitswerk op het aantal repositories, Git-object packing, LFS-opslag, database-latentie en runner-workload in plaats van op gewone paginaverzoeken; dat weerspiegelt de werkelijke druk op Gitea beter dan paginaverzoeken.
TLS is eenvoudig; gegenereerde URL's niet
Stel één HTTPS-hostnaam voor Gitea beschikbaar en houd de ruwe poort 3000 privé. Stel ROOT_URL en SSH_DOMAIN in op de adressen die gebruikers daadwerkelijk gebruiken om te clonen. Zo voorkom je dat browsers en API-clients twee concurrerende adressen leren kennen.
Voer vanaf een schone client de bekende, goed werkende transactie uit en controleer het eerste verzoek dat mislukt. Gebruik de handleiding voor een custom domain wanneer DNS of TLS niet goed is ingesteld. Behandel “ROOT_URL genereert localhost-clonelinks of de SSH-poort wordt niet doorgestuurd” als een afzonderlijke applicatiediagnose zodra de route is bewezen.
Bewijs dat de Gitea-deployment end-to-end werkt
Gebruik verkeer van de eerste gebruiker niet als acceptatietest voor Gitea. Bereid onschadelijke voorbeeldstatus voor en voer de volledige actie uit: “clonen via HTTPS en SSH, een commit en LFS-object pushen, een issue openen en één job uitvoeren op een afzonderlijk geregistreerde Actions-runner”. Noteer de exacte publieke URL, het resultaat, de image-referentie en het loginterval dat bij de uitvoering hoort.
Vervang de container en herhaal de test zonder de gegevens opnieuw op te bouwen. Herstel vervolgens naar een lege host; aan de herstelvoorwaarde is voldaan wanneer repositories fsck doorstaan, LFS-objecten kunnen worden gedownload en issues, releases en gebruikersrechten overeenkomen met de toestand vóór de back-up. Observeer bij elke test het aantal repositories, Git-object packing, LFS-opslag, database-latentie en runner-workload in plaats van gewone paginaverzoeken, en definieer een alert rond verslechtering van de transactie in plaats van rond inactieve containermetrics.
Laat één laatste controle expres mislukken: blokkeer tijdelijk de toegang van de testidentiteit tot Postgres of MySQL voor een drukkere installatie en tot een SSH-route als dat nodig is. Controleer of het resulterende Gitea-bericht de relevante grens identificeert, in plaats van het verwijderen van gegevens of een eindeloze restart te veroorzaken. Herstel de geldige toestand en bevestig dat dezelfde voorbeeldtransactie slaagt. Neem deze korte oefening op in de releasechecklist.
Oefen de risicovolle Gitea-wijziging
Monitor voor Gitea een transactie in plaats van een proces: clonen via HTTPS en SSH, een commit en LFS-object pushen, een issue openen en één job uitvoeren op een afzonderlijk geregistreerde Actions-runner. Combineer de latentie en het foutpercentage hiervan met het aantal repositories, Git-object packing, LFS-opslag, database-latentie en runner-workload in plaats van met gewone paginaverzoeken, zodat een alert het component met de beperking identificeert.
De upgrade-oefening moet rekening houden met het feit dat schemamigraties, repository hooks, packages en runners van derden een gefaseerde Gitea-upgrade vereisen. Herstel, migreer en voer de transactie uit vóór de vervanging in productie. Als ROOT_URL localhost-clonelinks genereert of de SSH-poort niet wordt doorgestuurd, verwijder dan geen gegevens om de startup groen te maken; vergelijk in deze volgorde de versie, variabelen, mounts en bereikbaarheid van dependencies.
Bescherm het waardevolle deel van Gitea
Controleer na de eerste login wat een anonieme bezoeker, gewone gebruiker en administrator elk kunnen doen. De Gitea-fout die je moet vermijden, is de installer of het eerste adminaccount langer dan nodig bereikbaar houden. Het beoogde beleid is om de installer na de bootstrap te sluiten, sitebeheer te beperken en tokens voor runnerregistratie kort geldig te maken.
Behandel GITEA__security__SECRET_KEY volgens de rol ervan in Gitea: houd gevoelige waarden buiten Git, documenteer de gevolgen van rotatie en gebruik in productie nooit een publiek voorbeeld. Houd dependency-accounts gescheiden van menselijke accounts, weiger ongebruikte uitgaande verbindingen waar dat praktisch is en begrens werk dat wordt beïnvloed door het aantal repositories, Git-object packing, LFS-opslag, database-latentie en runner-workload in plaats van door gewone paginaverzoeken.
Wat Dockup voor Gitea moet automatiseren
Voor Gitea kan Dockup de route en het TLS-certificaat aanmaken, mounts behouden, secrets leveren en Postgres of MySQL voor een drukkere installatie en een SSH-route als dat nodig is op private networking plaatsen, terwijl de deployment naar Dockup of gekoppelde servers wordt uitgevoerd.
De release gate blijft de concrete Gitea-transactie: clonen via HTTPS en SSH, een commit en LFS-object pushen, een issue openen en één job uitvoeren op een afzonderlijk geregistreerde Actions-runner. Controleer ook de herstelvoorwaarde: repositories doorstaan fsck, LFS-objecten kunnen worden gedownload en issues, releases en gebruikersrechten komen overeen met de toestand vóór de back-up. Deze twee controles laten zien of de deployment werkt en of deze kan worden hersteld.
Veelgestelde vragen
Wat heeft Gitea nodig voor een deployment in productie?
Routeer de Gitea-container op poort 3000 via één HTTPS-origin. De vereiste ondersteuning op netwerkniveau bestaat uit Postgres of MySQL voor een drukkere installatie en een SSH-route als dat nodig is. Noem Gitea pas klaar wanneer je via HTTPS en SSH kunt clonen, een commit en LFS-object kunt pushen, een issue kunt openen en één job kunt uitvoeren op een afzonderlijk geregistreerde Actions-runner.
Welke Gitea-gegevens horen in een back-up?
Maak /data persistent en neem repositories, LFS-objecten, bijlagen, configuratie en database op in hetzelfde herstelmanifest. Een schone Gitea-herstelactie slaagt pas wanneer repositories fsck doorstaan, LFS-objecten kunnen worden gedownload en issues, releases en gebruikersrechten overeenkomen met de toestand vóór de back-up.
Heeft Gitea HTTPS nodig achter een reverse proxy?
Gebruik HTTPS voor de publieke Gitea-origin en houd poort 3000 op de interne route. Pas de Gitea-instelling correct toe: stel ROOT_URL en SSH_DOMAIN in op de adressen die gebruikers daadwerkelijk gebruiken om te clonen. Voor Gitea beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent clientgedrag dat afhankelijk is van de origin.
Hoe moet een Gitea-upgrade worden getest?
Herstel de huidige Gitea-status naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat schemamigraties, repository hooks, packages en runners van derden een gefaseerde Gitea-upgrade vereisen. Bewaar de vorige Gitea-image totdat de grens voor datamigratie en rollback duidelijk is.