Zelfgehoste Git-server: Forgejo, Gitea of cgit kiezen

Welke zelfgehoste Git-server moet u draaien

Een zelfgehoste Git-server is geen enkelvoudig product, en het RAM (random access memory) op uw VPS bepaalt welke versie u kunt gebruiken. Git heeft zelf geen daemon nodig: een bare repository plus een SSH (secure shell) account vormt al een werkende server op de kleinste machine die u kunt huren. Alles wat daarboven komt, is een webapplicatie die u daarnaast draait, en elke stap omhoog kost geheugen waarover een kleine VPS mogelijk niet beschikt.

Er zijn vier stappen. Een bare repository via SSH, waarbij niets luistert dat nog niet luisterde. cgit, een snelle read-only webweergave zonder database. Forgejo of Gitea, een volledige forge met accounts, issues en pull requests in enkele honderden megabytes. GitLab, dat een server verwacht die vele malen groter is dan de andere opties.

Bepaal uw keuze op basis van het werk dat u moet verrichten en controleer vervolgens het geheugengebruik tegenover het abonnement waarvoor u betaalt.

Hoeveel RAM elke optie daadwerkelijk nodig heeft

Slechts twee van deze projecten publiceren een hardware-specificatie. Beschouw een gepubliceerd getal als een ondergrens in plaats van een garantie, en meet uw eigen instantie zodra deze draait met systemd-cgtop of ps -o rss= -C forgejo.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea documenteert 1 GB RAM met 2 CPU-cores als doorgaans voldoende voor kleine teams en projecten, en noemt een Raspberry Pi 3 als voldoende voor kleine workloads. GitLab documenteert 16 GB als de basislijn voor een installatie op één node, en 8 GB als de ondergrens voor wat de eigen pagina een geheugenbeperkte omgeving noemt. Forgejo publiceert helemaal geen hardwarevereisten. Het is een fork van Gitea en gedraagt zich als zodanig, dus het Gitea-cijfer is de meest nauwkeurige gepubliceerde richtlijn die u heeft.

Wat dit betekent op een 1 GB VPS: kale repositories en cgit passen met ruimte over, omdat geen van beide een resident service draait. Forgejo of Gitea zullen starten en een klein team bedienen op SQLite, maar u bevindt zich op de gedocumenteerde ondergrens, dus laat PostgreSQL en de CI (continuous integration) runner van die server af. Als de webinterface zonder foutmelding verdwijnt, voer dan sudo dmesg -T | grep -i oom uit en zoek naar een regel zoals Out of memory: Killed process 1181 (forgejo), wat betekent dat de kernel out of memory killer het proces heeft beëindigd. GitLab op een 1 GB server is geen kwestie van finetuning. Het zal niet draaien.

Tier 0: een bare repository via SSH

Git heeft geen netwerk-daemon die u moet starten. git push via SSH voert git-receive-pack op de externe machine uit als een standaard Unix-proces. Elk account dat u met een sleutel kunt bereiken, fungeert daarom al als een Git-remote. Maak één account aan voor de repositories en bewaar de repositories buiten de home-directory van dat account. Op Ubuntu 24.04 heeft een nieuwe home-directory namelijk de modus 0750, waardoor een later toegevoegde web-view de inhoud niet kan lezen.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare maakt een repository aan zonder working copy; dit is wat een server hoort te bevatten. Pushen naar een repository die wel een working copy heeft, wordt geweigerd met refusing to update checked out branch: refs/heads/main. Dit is de meest voorkomende fout op dit niveau.

Geef het account nu een sleutel en kloon de repository.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

Een eerste push die slaagt, eindigt met * [new branch] main -> main. Een push die eindigt met git@vps.example.com: Permission denied (publickey) is nooit geauthenticeerd; controleer in dat geval het serverlogboek met sudo journalctl -u ssh -n 20. Een regel met de tekst Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys betekent dat de bestandsrechten onjuist zijn, omdat sshd een sleutelbestand negeert dat door andere gebruikers kan worden gewijzigd.

Ontneem het account vervolgens de shell-toegang.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell accepteert alleen de weinige commando's die Git via SSH verstuurt. Een interactieve login stopt daarom nu met een melding in plaats van een prompt:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

Dat is de volledige server. Er is geen database en geen webproces om bij te werken. Wat u opgeeft, is alles wat een forge biedt: geen browserinterface, geen issue tracker, geen pull requests en geen rechten per gebruiker. Elke sleutel in dat bestand kan elke repository lezen en schrijven die eigendom is van de gebruiker git.

Niveau 1: cgit biedt een webweergave zonder database

cgit is een CGI-programma (common gateway interface) geschreven in C. De webserver voert het programma per verzoek uit, leest de repositories rechtstreeks vanaf de schijf en slaat zelf geen status op. Ubuntu 24.04 bevat dit programma in de universe-component.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

Wijs het programma naar de directory met repositories in /etc/cgitrc:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path doorzoekt die directory en toont elke gevonden repository, waardoor een nieuwe bare repo zonder extra configuratie direct zichtbaar is. cache-size is het aantal gecachte pagina's; caching blijft uitgeschakeld zolang dit op nul staat. Lees wat uw pakketbeheerder al in /etc/cgitrc heeft geplaatst voordat u regels toevoegt, aangezien het Debian- en Ubuntu-pakket eigen standaardinstellingen bevat.

Elk item toont de eerste regel van het bestand description van de repository, waardoor een nieuwe bare repo zichzelf vermeldt als Unnamed repository; edit this file 'description' to name the repository.. Corrigeer dit per repository:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

Twee beperkingen zijn belangrijk om te kennen voordat u hierop voortbouwt. cgit is alleen-lezen en heeft geen inlogfunctie, dus alles onder scan-path is openbaar: houd een private repository buiten die directory, of plaats HTTP basic authentication voor de gehele site. De CGI draait bovendien als de webservergebruiker; deze gebruiker moet daarom toegang hebben tot /srv/git en elke repository kunnen lezen. Een directory die de gebruiker niet kan betreden, wordt weergegeven als een lege index in plaats van een foutmelding.

Tier 2: Forgejo of Gitea voor issues en pull requests

Forgejo en Gitea zijn gebaseerd op hetzelfde concept: één Go-binary die een webgebaseerde forge aanbiedt met gebruikers, organisaties, issues, pull requests, releases, een pakketregister en een ingebouwd CI-systeem. De volledige installatie bestaat uit de binary en SQLite, waardoor ze draaien op hardware waar GitLab niet op kan functioneren. Het onderstaande Compose-bestand is afkomstig uit de documentatie van Forgejo, met de image-tag zoals vermeld in oktober 2026.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

De regel curl hoort een HTTP-statusregel terug te geven. Voordat u de eerste configuratie voltooit, kan dit een redirect naar /install zijn, wat eveneens betekent dat de service actief is. Als de container in plaats daarvan afsluit, is de gebruikelijke oorzaak de eigendomsrechten: de map ./forgejo moet toebehoren aan de UID (user id) in USER_UID, anders kan het proces niet naar de eigen datamap schrijven. Docker Compose op een VPS behandelt de bestandsstructuur en de regel voor volume-eigendom volledig.

Twee antwoorden op de configuratiepagina bepalen of clone-URL's correct werken. De SSH-poort moet 222 zijn, omdat het Compose-bestand hostpoort 222 koppelt aan poort 22 van de container, en het domein moet de naam zijn die gebruikers daadwerkelijk invoeren. Als een van beide onjuist is, toont elke repository-pagina een clone-commando dat voor iedereen die het kopieert zal falen. Beide instellingen bevinden zich achteraf in de sectie [server] van app.ini, als SSH_PORT, SSH_DOMAIN en ROOT_URL.

Stel voor een publieke instantie de webpoort alleen beschikbaar op het loopback-adres ('127.0.0.1:3000:3000') en plaats nginx ervoor voor TLS (transport layer security). Gitea wordt op dezelfde wijze geïnstalleerd vanuit de docker.gitea.com/gitea-image die in de documentatie wordt gebruikt, of als een enkele binary met één systemd-unit en één app.ini. De huidige stabiele release is v28.1.0, gepubliceerd op 6 oktober 2026. Met v28.0.0 eind september heeft het project het oude 1.-voorvoegsel laten vallen, waardoor de release na 1.27 het versienummer 28 draagt, en niet 1.28.

Blijf bij SQLite zolang dat mogelijk is. Dit houdt de instantie beperkt tot één proces en één bestand, en het overleeft een herstart zonder dat er een extra service beheerd hoeft te worden. PostgreSQL is de extra kosten pas waard wanneer meerdere mensen tegelijkertijd schrijven, omdat SQLite schrijfacties serialiseert en langdurige CI-runs constant schrijven. Beide projecten kunnen een bestaande instantie later naar PostgreSQL migreren, dus dit is geen definitieve beslissing.

Forgejo of Gitea: wat is het werkelijke verschil

De oorsprong is gedeeld. Gitea is in 2016 een fork geworden van Gogs. Eind 2022 ging de controle over het Gitea-domein en het handelsmerk over naar een bedrijf, Gitea Ltd, waarna verschillende beheerders samen met Codeberg Forgejo startten. Forgejo wordt uitgegeven door Codeberg e.V., een non-profitvereniging geregistreerd in Duitsland, en is in 2024 overgestapt van de MIT-licentie naar GPLv3 (GNU general public license version 3). Gitea blijft onder de MIT-licentie vallen en wordt ontwikkeld met commerciële ondersteuning.

In het dagelijks gebruik liggen de functionaliteiten dicht bij elkaar. Het pad tussen beide is dat echter niet. Forgejo v10.0, van januari 2025, was de laatste release die direct een Gitea-database kon inlezen, en alleen vanaf Gitea v1.22 of ouder. Gitea zit per oktober 2026 op v28.1.0, waardoor een huidige Gitea-instantie geen ondersteunde directe overstap naar Forgejo heeft. Kies één van beide voordat u deze met data vult en beschouw een latere overstap als een export en een re-import.

Een korte regel voor de keuze. Als bestuur voor u van belang is, of als u wilt dat het project bij een non-profit blijft, gebruik dan Forgejo. Als u de voorkeur geeft aan een grotere installatiebasis en een commerciële ondersteuningsoptie, gebruik dan Gitea. Beide worden openlijk onderhouden en brengen regelmatig releases uit: Forgejo publiceert elke drie maanden een stabiele release en elk jaar een LTS (long term support) release, waarbij v16.0.5 de huidige versie is en v15.0.9 de LTS-versie per oktober 2026. Forgejo ondersteunt v16 tot 29 oktober 2026 en v15 tot 15 juli 2027, dus controleer de releases-pagina voordat u een hoofdversie vastzet.

Tier 3: wat GitLab kost voordat het iets doet

GitLab CE is een andere klasse software. Eén instantie is een verzameling samenwerkende services: Puma voor de webapplicatie, Sidekiq voor achtergrondtaken, PostgreSQL, Redis, Gitaly voor repository-toegang en nginx aan de voorzijde. Het Omnibus-pakket installeert deze gezamenlijk, wat de installatie eenvoudig maakt en de minimale geheugenbehoefte hoog houdt.

De vereistenpagina van GitLab documenteert 16 GB RAM en 8 vCPU als basislijn voor een installatie op één node, waarbij 8 GB wordt genoemd als ondergrens in een omgeving met beperkt geheugen. Dezelfde pagina adviseert om swap uit te schakelen, omdat swappen onder belasting de prestaties van de instantie ernstig verslechtert. Dit zijn de gepubliceerde cijfers per oktober 2026, en deze zijn in de loop der jaren gestegen; lees de pagina dus opnieuw voordat u een server dimensioneert.

U krijgt voor dat budget concrete zaken: een container registry, een package registry, fijnmazige rechten, compliance- en auditfuncties, en CI die op grote schaal is getest. Als niemand in uw team iets uit die lijst kan noemen dat zij dit kwartaal nodig hebben, betaalt u voor een grotere VPS in ruil voor niets.

Het SSH-toegangsmodel: één git-gebruiker en meerdere sleutels

Elke laag hier authenticeert op dezelfde manier. Er is één Unix-account genaamd git, en elke publieke sleutel wordt geplaatst in de ~/.ssh/authorized_keys van dat account. Authenticatie verloopt via de sleutel. Autorisatie wordt bepaald door de opties die u op dezelfde regel vóór de sleutel plaatst.

Een standaard sleutelregel geeft de houder alle rechten van dat account. Een geforceerd commando beperkt dit tot Git:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

restrict, beschikbaar sinds OpenSSH 7.2, schakelt port forwarding, agent forwarding, X11 en PTY (pseudo terminal) allocatie in één woord uit. command= vervangt wat de client heeft aangevraagd door het commando dat u opgeeft, en Git blijft werken omdat Git zijn verzoek verstuurt in $SSH_ORIGINAL_COMMAND.

Een forge schrijft dat bestand voor u, en dat is het werkelijke verschil tussen laag 0 en laag 2. Forgejo en Gitea herschrijven authorized_keys met één regel per geregistreerde sleutel, elk voorzien van een geforceerd commando dat de sleutel identificeert aan de hand van het database-ID:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

Dat geforceerde commando is de manier waarop één gedeeld Unix-account verandert in rechten per gebruiker: key-3 vertelt de forge welke gebruiker verbinding maakt, en deze controleert de gebruiker tegen de repository voordat er objecten worden verplaatst. Bewerk dat bestand niet handmatig op een door een forge beheerde server, omdat het wordt herschreven vanuit de database en uw regel dan verdwijnt. Deploy-sleutels werken via hetzelfde mechanisme: een deploy-sleutel is een gewone SSH-sleutel die is geregistreerd bij een enkele repository, meestal alleen-lezen, waarbij de controle in de forge plaatsvindt in plaats van in sshd.

Twee gewoontes zijn belangrijker dan alle bovenstaande configuratie. Geef één sleutel uit per persoon of per machine, nooit een gedeelde sleutel, omdat het intrekken van een gedeelde sleutel betekent dat deze voor iedereen tegelijk moet worden vervangen. Verwijder sleutels op de dag dat iemand vertrekt, aangezien een oude sleutel in dat bestand een permanente login is waar niemand op toeziet. Goed beheer van SSH-sleutels op een server behandelt sleuteltypes en wachtzinnen, en alles daarvan is hier ongewijzigd van toepassing. Als de server nieuw is, is de eerste tien minuten op een nieuwe VPS de juiste procedure voordat u er repositories op plaatst.

Kan ik GitHub Actions uitvoeren op mijn eigen Git-server?

U kunt workflows uitvoeren die zijn geschreven in de GitHub Actions-syntaxis. U kunt GitHub zelf niet uitvoeren. Forgejo Actions is standaard ingeschakeld sinds Forgejo v1.21 en leest workflowbestanden uit .forgejo/workflows in elke repository. Gitea Actions werkt op dezelfde manier en leest .gitea/workflows. Beide vereisen een tweede programma, de runner, dat moet worden geïnstalleerd en geregistreerd bij uw instantie met een token uit de beheerdersinstellingen. Veel gepubliceerde actions werken ongewijzigd; alles wat de GitHub API aanroept of verwacht dat de infrastructuur door GitHub wordt gehost, werkt niet.

Houd rekening met twee gevolgen. De runner start een container voor elke job, dus deze heeft een container-engine en een eigen geheugenbudget nodig. Daarom hoort deze niet thuis op dezelfde 1 GB server als de forge. Daarnaast voert de runner alles uit wat in een workflowbestand staat, wat de documentatie van Forgejo duidelijk vermeldt: de runner voert remote code execution uit. Geef de runner waar mogelijk een eigen host, of op zijn minst een eigen gebruiker zonder privileges en een registratietoken dat beperkt is tot één repository.

Als uw repositories op GitHub blijven staan en u alleen de rekenkracht op hardware wilt die u zelf beheert, is dat een andere configuratie met andere stappen: een self-hosted GitHub Actions runner koppelt aan een GitHub-repository en heeft dit alles niet nodig. Als u nog afweegt wat vertrek u kost, scheidt wat GitHub u daadwerkelijk biedt de Git-hosting van het netwerk eromheen.

Backups: repositories zijn slechts de helft van de status

Een bare repository is een map, dus het kopiëren ervan kopieert alles wat erin staat. Een mirror clone vanaf een andere machine is een echte back-up en deze ververst zichzelf op de huidige locatie:

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

Dit haalt elke ref en elk object op. Het haalt geen server-side hooks of het description-bestand op, dus bewaar ook een kopie van de map op bestandsniveau als u hooks gebruikt.

Een forge bewaart issues, pull requests, gebruikers, keys en permissies in de database, en een kopie van alleen de repositories gooit dit alles weg. Beide projecten leveren een dump-commando dat de database, de repositories, de configuratie en de bijlagen naar één archief schrijft:

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

Onder Docker draait hetzelfde commando binnen de container, en het configuratiepad hangt af van de image, dus kijk goed voordat u typt:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

Voer het uit als de gebruiker die eigenaar is van de data en schrijf het archief naar een map waar die gebruiker schrijfrechten heeft. Kopieer het archief vervolgens van de server, want een back-up die alleen op de machine zelf bestaat, is geen back-up. Herstellen is de stap die mensen vaak overslaan: pak nu een dump uit op een reservemachine, zodat u de procedure leert op een rustig moment in plaats van tijdens een storing.

Kiezen op basis van scenario

Eén persoon met een laptop en een VPS, waarbij browsen niet nodig is: gebruik bare repositories via SSH. Er draait geen extra service en er is niets om bij te werken.

Hetzelfde, maar u wilt code in een browser kunnen lezen en links ernaar kunnen sturen: voeg cgit toe. Nog steeds geen database en geen resident processen.

Een team dat elkaars code beoordeelt en issues bijhoudt: Forgejo of Gitea, op 2 GB RAM of meer. Verplaats de CI runner naar een tweede machine zodra de taken serieuzer worden.

Een organisatie die een container registry en audit trails nodig heeft, met 16 GB aan servergeheugen: GitLab. Begin hier niet aan onder dit budget.

Upgraden tussen de eerste drie niveaus is goedkoop, omdat de repositories in al deze gevallen gewone Git-mappen op de schijf zijn. Begin bij het laagste niveau dat aan uw eisen voldoet. Als u bepaalt welke andere zaken op dezelfde server passen, plaatst de shortlist van wat de moeite waard is om zelf te hosten een Git-server naast de andere services die strijden om dat RAM-geheugen.

FAQ

Kan een 1 GB VPS Forgejo of Gitea draaien?

Ja, voor een klein team, op SQLite, mits er geen andere zware processen op de server draaien. De documentatie van Gitea geeft aan dat 1 GB RAM en 2 CPU-cores doorgaans volstaan voor kleine teams en projecten; Forgejo is een fork van Gitea met dezelfde vereisten. Voeg geen PostgreSQL of een CI-runner toe aan die machine. Als de service verdwijnt zonder foutmelding in het eigen logbestand, voer dan sudo dmesg -T | grep -i oom uit: een regel die het beëindigde proces noemt, betekent dat de kernel out-of-memory killer het proces heeft beëindigd. De oplossing is dan een groter abonnement in plaats van een tuning-vlag.

Wat is het verschil tussen Forgejo en Gitea?

Ze delen een gezamenlijke geschiedenis en de meeste functies. Gitea is in 2016 geforkt van Gogs, en Forgejo is eind 2022 geforkt van Gitea nadat de controle over het Gitea-handelsmerk naar een bedrijf was overgegaan. Forgejo wordt uitgegeven door Codeberg e.V., een non-profit in Duitsland, onder de GPLv3-licentie; Gitea blijft onder de MIT-licentie met commerciële ondersteuning. Het praktische verschil zit in het migratiepad. Forgejo v10.0, van januari 2025, was de laatste release die een Gitea-database direct kon inlezen, en alleen vanaf Gitea v1.22 of ouder. Een actuele Gitea-instantie heeft daarom geen ondersteunde methode voor een directe overstap.

Kan ik GitHub Actions-workflows draaien op een zelfgehoste Git-server?

Forgejo Actions en Gitea Actions voeren beide workflows uit die zijn geschreven in de GitHub Actions YAML-syntaxis, gelezen vanuit .forgejo/workflows en .gitea/workflows. U installeert een apart runner-programma en registreert dit bij uw instantie. Veel gepubliceerde actions werken ongewijzigd, maar alles wat de GitHub API aanroept werkt niet. De runner voert willekeurige code uit uw repositories uit en start een container per job. Geef de runner daarom een eigen host, of op zijn minst een eigen gebruiker zonder privileges, en houd deze weg van een 1 GB-server die al de forge draait.

Hoe maak ik een back-up van een zelfgehoste Git-server?

Voor bare repositories kopieert git clone --mirror vanaf een andere machine elke ref en elk object, en git remote update binnen die mirror ververst deze. Voor Forgejo of Gitea vormen de repositories slechts een deel van de status, omdat issues, pull requests, gebruikers en sleutels in de database staan. Gebruik de ingebouwde dump-functie, sudo -u git forgejo dump -c /etc/forgejo/app.ini, of hetzelfde commando binnen de container bij een Docker-installatie. Kopieer het archief van de server af en herstel er eenmaal een op een reservemachine, zodat u weet dat de procedure werkt.