Własny serwer Git: Forgejo, Gitea, cgit czy SSH?

Który serwer Git do samodzielnego hostowania wybrać

Serwer Git do samodzielnego hostowania nie jest jednym konkretnym produktem, a ilość pamięci RAM (random access memory) na posiadanym VPS determinuje, która wersja będzie odpowiednia. Git nie wymaga własnego demona: samo repozytorium typu bare oraz konto SSH (secure shell) wystarczają, aby uruchomić działający serwer na najmniejszej dostępnej instancji. Wszystko powyżej tego poziomu to aplikacja webowa, którą uruchamia się dodatkowo, a każdy kolejny krok zwiększa zapotrzebowanie na pamięć, której mały VPS może nie posiadać.

Istnieją cztery poziomy. Repozytorium bare przez SSH, niewymagające uruchamiania żadnych dodatkowych usług nasłuchujących. cgit, szybki interfejs webowy tylko do odczytu, niewymagający bazy danych. Forgejo lub Gitea, pełnoprawna platforma z obsługą kont, zgłoszeń (issues) i pull requestów, mieszcząca się w kilkuset megabajtach. GitLab, który wymaga serwera o wielokrotnie większych zasobach niż pozostałe rozwiązania.

Wybór należy uzależnić od planowanego zakresu prac, a następnie zweryfikować wymagania pamięciowe z posiadanym planem hostingowym.

Ile pamięci RAM faktycznie wymaga każda z opcji

Tylko dwa z tych projektów publikują wymagania sprzętowe. Opublikowaną wartość należy traktować jako minimum, a nie gwarancję. Po uruchomieniu instancji należy dokonać własnych pomiarów za pomocą systemd-cgtop lub 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 podaje 1 GB pamięci RAM oraz 2 rdzenie CPU jako wartość wystarczającą dla małych zespołów i projektów, wskazując Raspberry Pi 3 jako sprzęt wystarczający do niewielkich obciążeń. GitLab podaje 16 GB jako wartość bazową dla instalacji jednowęzłowej oraz 8 GB jako dolną granicę dla środowisk o ograniczonych zasobach pamięci. Forgejo nie publikuje żadnych wymagań sprzętowych. Jest to fork Gitea, który zachowuje się w podobny sposób, więc dane dla Gitea stanowią najbliższy dostępny punkt odniesienia.

W praktyce na VPS z 1 GB RAM: puste repozytoria oraz cgit mieszczą się w pamięci z zapasem, ponieważ żaden z nich nie uruchamia rezydentnej usługi. Forgejo lub Gitea uruchomią się i obsłużą mały zespół korzystający z SQLite, jednak jest to poziom graniczny, więc należy zrezygnować z instalacji PostgreSQL oraz runnera CI (continuous integration) na tej samej maszynie. Jeśli interfejs WWW znika bez komunikatu o błędzie, należy uruchomić sudo dmesg -T | grep -i oom i wyszukać linię typu Out of memory: Killed process 1181 (forgejo), co oznacza, że proces został zakończony przez mechanizm kernel out of memory killer. GitLab na maszynie z 1 GB RAM nie jest kwestią optymalizacji. Ta usługa nie uruchomi się.

Poziom 0: surowe repozytorium przez SSH

Git nie wymaga uruchamiania żadnego demona sieciowego. git push przez SSH uruchamia git-receive-pack po stronie zdalnej jako zwykły proces systemowy, dlatego każde konto dostępne za pomocą klucza jest już zdalnym repozytorium Git. Należy utworzyć jedno konto dla repozytoriów i przechowywać je poza jego katalogiem domowym, ponieważ w systemie Ubuntu 24.04 nowy katalog domowy ma uprawnienia 0750, co uniemożliwia późniejszy odczyt przez przeglądarkę WWW.

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 tworzy repozytorium bez kopii roboczej, co jest standardem dla serwera. Wypychanie zmian do repozytorium posiadającego kopię roboczą jest odrzucane z błędem refusing to update checked out branch: refs/heads/main, co stanowi najczęstszy błąd na tym poziomie.

Teraz należy dodać klucz do konta i sklonować repozytorium.

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

Pierwsze poprawne wypchnięcie zmian kończy się komunikatem * [new branch] main -> main. Jeśli operacja kończy się błędem git@vps.example.com: Permission denied (publickey), oznacza to brak autoryzacji; należy wówczas sprawdzić logi serwera za pomocą sudo journalctl -u ssh -n 20. Linia o treści Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys oznacza nieprawidłowe uprawnienia pliku, ponieważ sshd ignoruje plik klucza, do którego inni użytkownicy mają prawo zapisu.

Następnie należy odebrać powłokę systemową temu kontu.

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

git-shell akceptuje tylko kilka poleceń wysyłanych przez Git za pośrednictwem SSH, dlatego interaktywne logowanie kończy się teraz komunikatem zamiast znakiem zachęty:

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

To cały serwer. Nie ma tu bazy danych ani procesu WWW do aktualizacji. Rezygnuje się przy tym ze wszystkich funkcji platformy typu forge: brak przeglądarki plików, systemu śledzenia zgłoszeń, pull requestów oraz uprawnień per użytkownik. Każdy klucz w tym pliku pozwala na odczyt i zapis każdego repozytorium należącego do użytkownika git.

Poziom 1: cgit zapewnia podgląd WWW bez bazy danych

cgit to program CGI (common gateway interface) napisany w języku C. Serwer WWW uruchamia go przy każdym żądaniu, program odczytuje repozytoria bezpośrednio z dysku i nie przechowuje własnego stanu. Ubuntu 24.04 udostępnia go w komponencie universe.

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

Wskaż katalog repozytoriów w /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 przeszukuje ten katalog i wymienia każde znalezione repozytorium, dzięki czemu nowe, puste repozytorium (bare repo) pojawia się bez dodatkowej konfiguracji. cache-size to liczba buforowanych stron; buforowanie pozostaje wyłączone, gdy wartość wynosi zero. Przed dodaniem własnych linii sprawdź zawartość pliku /etc/cgitrc, ponieważ pakiety Debian i Ubuntu dostarczają własne ustawienia domyślne.

Każdy wpis wyświetla pierwszą linię pliku description repozytorium, więc nowe, puste repozytorium jest widoczne jako Unnamed repository; edit this file 'description' to name the repository.. Popraw to dla każdego repozytorium z osobna:

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

Przed rozpoczęciem pracy warto poznać dwa ograniczenia. cgit działa w trybie tylko do odczytu i nie posiada mechanizmu logowania, więc wszystko w katalogu scan-path jest publiczne: przechowuj prywatne repozytoria poza tym katalogiem lub zabezpiecz całą witrynę za pomocą HTTP Basic Authentication. Ponadto CGI działa z uprawnieniami użytkownika serwera WWW, więc użytkownik ten musi mieć możliwość przejścia przez ścieżkę /srv/git i odczytu każdego repozytorium. Katalog, do którego użytkownik nie ma dostępu, będzie widoczny jako pusty indeks, a nie jako błąd.

Poziom 2: Forgejo lub Gitea do obsługi zgłoszeń i pull requestów

Forgejo i Gitea opierają się na tej samej koncepcji: pojedynczy plik binarny w języku Go, który udostępnia platformę programistyczną z obsługą użytkowników, organizacji, zgłoszeń (issues), pull requestów, wydań (releases), rejestru pakietów oraz wbudowanego systemu CI. Cała instalacja sprowadza się do pliku binarnego oraz bazy SQLite, dzięki czemu rozwiązanie to działa na sprzęcie, na którym GitLab nie mógłby zostać uruchomiony. Poniższy plik Compose jest zgodny z dokumentacją Forgejo, z uwzględnieniem tagu obrazu wskazanego w październiku 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

Linia curl powinna zwrócić nagłówek statusu HTTP. Przed zakończeniem pierwszej konfiguracji może to być przekierowanie do /install, co nadal oznacza, że usługa działa. Jeśli kontener kończy działanie, najczęstszą przyczyną jest problem z uprawnieniami: katalog ./forgejo musi należeć do UID (identyfikatora użytkownika) określonego w USER_UID, w przeciwnym razie proces nie może zapisać danych we własnym katalogu. Docker Compose na VPS szczegółowo opisuje strukturę plików oraz zasady dotyczące uprawnień do wolumenów.

Dwie odpowiedzi na stronie konfiguracji decydują o tym, czy adresy URL do klonowania będą działać. Port SSH musi być ustawiony na 222, ponieważ plik Compose mapuje port hosta 222 na port 22 kontenera, a domena musi być nazwą, którą użytkownicy będą faktycznie wpisywać. Błąd w którymkolwiek z tych ustawień spowoduje, że każda strona repozytorium będzie oferować polecenie klonowania, które nie zadziała dla nikogo, kto je skopiuje. Oba ustawienia znajdują się później w sekcji [server] pliku app.ini, jako SSH_PORT, SSH_DOMAIN oraz ROOT_URL.

W przypadku instancji publicznej należy udostępnić port WWW wyłącznie na adresie loopback ('127.0.0.1:3000:3000') i umieścić przed nim Nginx w celu obsługi TLS (transport layer security). Gitea instaluje się w ten sam sposób z obrazu docker.gitea.com/gitea używanego w dokumentacji lub jako pojedynczy plik binarny z jedną jednostką systemd i jednym plikiem app.ini. Obecne stabilne wydanie to v28.1.0, opublikowane 6 października 2026. Wraz z wydaniem v28.0.0 pod koniec września projekt porzucił stary prefiks 1., więc wydanie następujące po 1.27 to 28, a nie 1.28.

Należy pozostać przy SQLite tak długo, jak to możliwe. Pozwala to utrzymać instancję jako jeden proces i jeden plik, co ułatwia restarty bez konieczności nadzorowania dodatkowej usługi. PostgreSQL staje się opłacalny, gdy kilka osób zapisuje dane jednocześnie, ponieważ SQLite szereguje operacje zapisu, a długotrwałe procesy CI generują ciągły ruch zapisu. Oba projekty umożliwiają późniejszą migrację istniejącej instancji do PostgreSQL, więc nie jest to decyzja ostateczna.

Forgejo czy Gitea: na czym polega różnica

Projekty mają wspólne pochodzenie. Gitea powstała jako fork Gogs w 2016 roku. Pod koniec 2022 roku kontrola nad domeną i znakiem towarowym Gitea przeszła na spółkę Gitea Ltd, a część opiekunów projektu wraz z Codeberg uruchomiła Forgejo. Forgejo jest publikowane przez Codeberg e.V., stowarzyszenie non-profit zarejestrowane w Niemczech, które w 2024 roku zmieniło licencję z MIT na GPLv3 (GNU general public license version 3). Gitea pozostaje na licencji MIT i jest rozwijana przy wsparciu komercyjnym.

W codziennym użytkowaniu zestawy funkcji są zbliżone. Ścieżka migracji między nimi nie jest jednak prosta. Forgejo v10.0, wydane w styczniu 2025 roku, było ostatnią wersją obsługującą bezpośrednią migrację bazy danych z Gitea, przy czym dotyczyło to tylko wersji Gitea v1.22 lub starszych. Gitea w październiku 2026 roku osiągnęła wersję v28.1.0, więc dla aktualnej instancji Gitea nie istnieje wspierana metoda bezpośredniego przejścia na Forgejo. Należy dokonać wyboru przed wprowadzeniem danych, a każdą późniejszą zmianę traktować jako eksport i ponowny import.

Krótka zasada wyboru: jeśli istotne jest zarządzanie projektem lub preferowane jest wsparcie organizacji non-profit, należy wybrać Forgejo. Jeśli priorytetem jest większa baza instalacyjna i dostępność komercyjnego wsparcia, należy wybrać Gitea. Oba projekty są rozwijane otwarcie i często publikują nowe wersje: Forgejo wydaje wersję stabilną co trzy miesiące oraz wersję LTS (long term support) raz w roku. Według stanu na październik 2026 roku aktualną wersją jest v16.0.5, a wersją LTS jest v15.0.9. Forgejo wspiera v16 do 29 października 2026 roku, a v15 do 15 lipca 2027 roku, dlatego przed przypięciem konkretnej wersji głównej należy sprawdzić stronę wydań.

Poziom 3: koszty GitLab przed rozpoczęciem pracy

GitLab CE to oprogramowanie innej klasy. Jedna instancja składa się z zestawu współpracujących usług: Puma dla aplikacji webowej, Sidekiq dla zadań w tle, PostgreSQL, Redis, Gitaly do obsługi repozytoriów oraz nginx jako warstwa wejściowa. Pakiet Omnibus instaluje je łącznie, co upraszcza proces instalacji, ale podnosi minimalne wymagania pamięciowe.

Strona wymagań GitLab określa 16 GB RAM oraz 8 vCPU jako bazę dla instalacji jednowęzłowej, przy czym 8 GB jest wskazywane jako dolna granica w środowiskach o ograniczonej pamięci. Ta sama strona zaleca wyłączenie swap, ponieważ korzystanie z niego pod obciążeniem drastycznie obniża wydajność instancji. Są to oficjalne dane na październik 2026 roku, które z biegiem lat stale rosną, dlatego przed doborem serwera należy ponownie sprawdzić dokumentację.

W zamian za ten koszt otrzymuje się konkretne funkcjonalności: rejestr kontenerów, rejestr pakietów, precyzyjne zarządzanie uprawnieniami, funkcje zgodności i audytu oraz CI przetestowane w dużej skali. Jeśli nikt w zespole nie potrafi wskazać żadnego elementu z tej listy, który jest niezbędny w bieżącym kwartale, opłacanie większego VPS nie przynosi żadnych korzyści.

Model dostępu SSH: jeden użytkownik git i wiele kluczy

Każdy poziom uwierzytelnia się w ten sam sposób. Istnieje jedno konto Unix o nazwie git, a każdy klucz publiczny trafia do pliku ~/.ssh/authorized_keys tego konta. Uwierzytelnianie opiera się na kluczu. Autoryzacja zależy od opcji wpisanych przed kluczem w tej samej linii.

Zwykły wpis klucza nadaje posiadaczowi wszystkie uprawnienia tego konta. Wymuszone polecenie (forced command) ogranicza je do Git:

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

Opcja restrict, dostępna od wersji OpenSSH 7.2, wyłącza przekierowanie portów, przekierowanie agenta, X11 oraz przydzielanie PTY (pseudo terminala) za pomocą jednego słowa. command= zastępuje żądanie klienta wskazanym poleceniem, a Git nadal działa, ponieważ przesyła swoje żądanie w $SSH_ORIGINAL_COMMAND.

Platforma typu forge generuje ten plik automatycznie i to jest główna różnica między poziomem 0 a poziomem 2. Forgejo i Gitea nadpisują authorized_keys, umieszczając jedną linię na każdy zarejestrowany klucz, z których każda zawiera wymuszone polecenie identyfikujące klucz za pomocą jego identyfikatora w bazie danych:

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

To wymuszone polecenie sprawia, że jedno współdzielone konto Unix staje się mechanizmem uprawnień per-użytkownik: key-3 informuje platformę, który użytkownik nawiązuje połączenie, a ta weryfikuje go względem repozytorium przed przesłaniem jakichkolwiek obiektów. Nie należy ręcznie edytować tego pliku na serwerze zarządzanym przez forge, ponieważ jest on nadpisywany na podstawie bazy danych i wprowadzona zmiana zostanie usunięta. Klucze wdrożeniowe (deploy keys) działają w oparciu o ten sam mechanizm: klucz wdrożeniowy to zwykły klucz SSH zarejestrowany dla pojedynczego repozytorium, zazwyczaj z uprawnieniami tylko do odczytu, gdzie weryfikacja odbywa się wewnątrz platformy, a nie w sshd.

Dwa nawyki są ważniejsze niż jakakolwiek powyższa konfiguracja. Należy wydawać jeden klucz na osobę lub maszynę, nigdy nie używać kluczy współdzielonych, ponieważ unieważnienie takiego klucza oznacza konieczność jego wymiany dla wszystkich użytkowników jednocześnie. Należy również usuwać klucze w dniu odejścia pracownika, ponieważ stary klucz w tym pliku stanowi stały punkt dostępu, którego nikt nie monitoruje. Dobre praktyki zarządzania kluczami SSH na serwerze omawiają typy kluczy oraz hasła, a wszystkie te zasady mają tu pełne zastosowanie. Jeśli serwer jest nowy, pierwsze dziesięć minut na nowym VPS to właściwa procedura przed umieszczeniem na nim repozytoriów.

Czy można uruchomić GitHub Actions na własnym serwerze Git?

Można uruchamiać workflowy napisane w składni GitHub Actions. Nie można uruchomić GitHub. Funkcja Forgejo Actions jest domyślnie włączona od wersji Forgejo v1.21 i odczytuje pliki workflow z .forgejo/workflows w każdym repozytorium. Gitea Actions działa w ten sam sposób i odczytuje .gitea/workflows. Oba rozwiązania wymagają drugiego programu, tzw. runnera, zainstalowanego i zarejestrowanego w instancji za pomocą tokena z ustawień administratora. Wiele opublikowanych akcji działa bez zmian; te, które wywołują GitHub API lub oczekują infrastruktury hostowanej przez GitHub, nie będą działać.

Należy uwzględnić dwie konsekwencje. Runner uruchamia kontener dla każdego zadania, więc wymaga silnika kontenerów i własnego przydziału pamięci, dlatego nie powinien znajdować się na tym samym serwerze 1 GB co forge. Ponadto runner wykonuje wszystko, co zawiera plik workflow, co dokumentacja Forgejo stwierdza wprost: runner wykonuje zdalny kod (remote code execution). Jeśli to możliwe, należy zapewnić mu osobny host, a w ostateczności własnego użytkownika bez uprawnień oraz token rejestracyjny ograniczony do jednego repozytorium.

Jeśli repozytoria pozostają na GitHub, a celem jest jedynie przeniesienie obliczeń na własny sprzęt, jest to inna konfiguracja wymagająca innych kroków: self-hosted GitHub Actions runner łączy się z repozytorium GitHub i nie wymaga powyższych działań. Jeśli nadal rozważane są koszty odejścia, co faktycznie oferuje GitHub pozwala oddzielić hosting Git od otaczającej go sieci.

Kopie zapasowe: repozytoria to tylko połowa stanu

Czyste repozytorium (bare repository) jest katalogiem, więc jego skopiowanie przenosi całą zawartość. Klon typu mirror z innej maszyny stanowi pełnoprawną kopię zapasową i jest aktualizowany w miejscu:

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

Polecenie to pobiera wszystkie referencje oraz obiekty. Nie pobiera ono jednak skryptów typu hooks po stronie serwera ani pliku description, dlatego w przypadku korzystania z hooków należy również wykonać kopię całego katalogu na poziomie systemu plików.

Platforma typu forge przechowuje zgłoszenia (issues), pull requesty, użytkowników, klucze oraz uprawnienia w swojej bazie danych, więc sama kopia repozytoriów powoduje utratę tych informacji. Oba projekty udostępniają polecenie zrzutu (dump), które zapisuje bazę danych, repozytoria, konfigurację oraz załączniki do jednego archiwum:

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

W środowisku Docker to samo polecenie uruchamia się wewnątrz kontenera, a ścieżka do konfiguracji zależy od obrazu, dlatego należy ją sprawdzić przed wpisaniem komendy:

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

Polecenie należy uruchomić jako użytkownik będący właścicielem danych i zapisać archiwum w katalogu, do którego ten użytkownik ma uprawnienia zapisu. Następnie archiwum należy skopiować poza serwer, ponieważ kopia zapasowa istniejąca wyłącznie na zabezpieczanej maszynie nie jest kopią zapasową. Przywracanie danych to krok, który często jest pomijany: należy rozpakować jeden zrzut na zapasowej maszynie już teraz, aby poznać procedurę w spokojnych warunkach, a nie podczas awarii.

Wybór scenariusza

Jedna osoba z laptopem i serwerem VPS, bez potrzeby przeglądania kodu w przeglądarce: wystarczą repozytoria typu bare przez SSH. Nie ma potrzeby uruchamiania dodatkowych usług ani przeprowadzania aktualizacji.

Ten sam scenariusz, ale z potrzebą przeglądania kodu w przeglądarce i wysyłania linków: należy dodać cgit. Nadal nie jest wymagana baza danych ani rezydentne procesy.

Zespół, który wzajemnie recenzuje kod i śledzi zgłoszenia: Forgejo lub Gitea, przy co najmniej 2 GB pamięci RAM. Po zwiększeniu intensywności zadań CI, runnera należy przenieść na drugą maszynę.

Organizacja wymagająca rejestru kontenerów i ścieżek audytu, dysponująca serwerem z 16 GB RAM: GitLab. Przy mniejszym budżecie sprzętowym nie należy go uruchamiać.

Przejście między pierwszymi trzema poziomami jest tanie, ponieważ we wszystkich przypadkach repozytoria są zwykłymi katalogami Git na dysku. Należy zacząć od najniższego poziomu, który spełnia wymagania. Jeśli planowane jest umieszczenie innych usług na tym samym serwerze, lista usług wartych samodzielnego hostowania przedstawia serwer Git w kontekście innych rozwiązań konkurujących o zasoby RAM.

FAQ

Czy serwer VPS o pojemności 1 GB obsłuży Forgejo lub Gitea?

Tak, w przypadku małego zespołu, przy użyciu SQLite i braku innych zasobożernych usług na serwerze. Dokumentacja Gitea wskazuje, że 1 GB pamięci RAM i 2 rdzenie CPU są zazwyczaj wystarczające dla małych zespołów i projektów, a Forgejo, będące forkiem Gitea, ma zbliżone wymagania. Nie należy instalować PostgreSQL ani CI runnera na tej samej maszynie. Jeśli usługa znika bez błędu w dzienniku, należy uruchomić sudo dmesg -T | grep -i oom: linia wskazująca na zabity proces oznacza, że mechanizm OOM (Out of Memory) kernela przerwał działanie usługi. Rozwiązaniem jest zwiększenie planu serwera, a nie zmiana flag konfiguracyjnych.

Jaka jest różnica między Forgejo a Gitea?

Projekty te współdzielą historię kodu źródłowego oraz większość funkcji. Gitea powstała jako fork Gogs w 2016 roku, natomiast Forgejo powstało jako fork Gitea pod koniec 2022 roku, po tym jak kontrola nad znakiem towarowym Gitea przeszła w ręce firmy komercyjnej. Forgejo jest publikowane przez Codeberg e.V., niemiecką organizację non-profit, na licencji GPLv3; Gitea pozostaje na licencji MIT z wsparciem komercyjnym. Różnica praktyczna dotyczy ścieżki migracji. Forgejo v10.0, wydane w styczniu 2025 roku, było ostatnią wersją obsługującą bezpośrednią migrację bazy danych z Gitea (tylko z wersji Gitea v1.22 lub starszych), dlatego obecnie nie ma wspieranej ścieżki bezpośredniej zmiany instancji Gitea na Forgejo.

Czy mogę uruchamiać workflowy GitHub Actions na własnym serwerze Git?

Zarówno Forgejo Actions, jak i Gitea Actions obsługują workflowy zapisane w składni YAML GitHub Actions, odczytywane z .forgejo/workflows oraz .gitea/workflows. Należy zainstalować oddzielny program typu runner i zarejestrować go w swojej instancji. Wiele opublikowanych akcji działa bez zmian, natomiast te wywołujące API GitHub nie będą działać. Runner wykonuje dowolny kod z repozytoriów i uruchamia osobny kontener dla każdego zadania, dlatego należy zapewnić mu dedykowany host lub przynajmniej osobnego użytkownika z ograniczonymi uprawnieniami. Nie należy uruchamiać go na serwerze 1 GB, który już obsługuje instancję Git.

Jak wykonać kopię zapasową własnego serwera Git?

W przypadku czystych repozytoriów (bare repositories), git clone --mirror z innej maszyny kopiuje wszystkie referencje i obiekty, a git remote update wewnątrz tego mirrora odświeża jego zawartość. W przypadku Forgejo lub Gitea repozytoria stanowią tylko część danych, ponieważ zgłoszenia (issues), pull requesty, użytkownicy i klucze znajdują się w bazie danych. Należy użyć wbudowanego narzędzia do zrzutu, sudo -u git forgejo dump -c /etc/forgejo/app.ini, lub tego samego polecenia wewnątrz kontenera w przypadku instalacji Docker. Archiwum należy skopiować poza serwer i przynajmniej raz przeprowadzić procedurę przywracania na zapasowej maszynie, aby upewnić się, że proces jest poprawny.