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 decyduje o tym, którą wersję można uruchomić. Git nie wymaga własnego demona: puste repozytorium (bare repository) oraz konto SSH (secure shell) stanowią w pełni funkcjonalny serwer nawet na najmniejszej dostępnej maszynie. 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. Puste repozytorium przez SSH, niewymagające uruchamiania żadnych dodatkowych usług. cgit, szybki interfejs webowy typu read-only bez bazy danych. Forgejo lub Gitea, pełna 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 porównać wymagania pamięciowe z posiadanym planem hostingowym.

Rzeczywiste zapotrzebowanie na pamięć RAM dla poszczególnych 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 dokumentuje 1 GB pamięci RAM przy 2 rdzeniach 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 dokumentuje 16 GB jako wartość bazową dla instalacji jednowęzłowej oraz 8 GB jako dolną granicę dla środowisk o ograniczonej pamięci. Forgejo nie publikuje żadnych wymagań sprzętowych. Jest to fork Gitea, który zachowuje się w podobny sposób, dlatego dane dla Gitea stanowią najbliższy dostępny punkt odniesienia.

W praktyce na VPS z 1 GB RAM: puste repozytoria i 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 po prostu nie zadziała.

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, więc 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 uwierzytelnienia; należy sprawdzić dziennik serwera za pomocą sudo journalctl -u ssh -n 20. Linia zawierająca Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys oznacza błędne uprawnienia pliku, ponieważ sshd ignoruje plik klucza, do którego inni użytkownicy mają uprawnienia zapisu.

Następnie należy odebrać powłokę (shell) temu kontu.

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

git-shell akceptuje tylko nieliczne polecenia wysyłane przez Git za pośrednictwem SSH, więc interaktywne logowanie kończy się teraz wyświetleniem komunikatu zamiast znaku 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 repozytorió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 zawiera 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 wyświetla każde znalezione repozytorium, dzięki czemu nowe repozytorium typu bare pojawia się bez dodatkowej konfiguracji. cache-size to liczba stron w pamięci podręcznej; przy wartości zero buforowanie pozostaje wyłączone. Przed dodaniem własnych linii zapoznaj się z zawartością /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 repozytorium typu bare 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 znać dwa ograniczenia. cgit działa w trybie tylko do odczytu i nie obsługuje logowania, więc cała zawartość scan-path jest publiczna: przechowuj prywatne repozytoria poza tym katalogiem lub zabezpiecz całą witrynę za pomocą HTTP basic authentication. Ponadto skrypt CGI działa z uprawnieniami użytkownika serwera WWW, więc użytkownik ten musi mieć możliwość przejścia przez /srv/git i odczytu każdego repozytorium. Katalog, do którego użytkownik nie ma dostępu, będzie widoczny jako pusty indeks zamiast błędu.

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łość instalacji stanowi plik binarny oraz baza SQLite, dzięki czemu oprogramowanie to działa na sprzęcie, na którym GitLab nie mógłby zostać uruchomiony. Poniższy plik Compose pochodzi z dokumentacji Forgejo i zawiera tag obrazu aktualny na sierpień 2026 roku.

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

Polecenie curl powinno zwrócić linię 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ą są uprawnienia: katalog ./forgejo musi należeć do UID (identyfikatora użytkownika) określonego w USER_UID, w przeciwnym razie proces nie będzie mógł zapisać danych w swoim katalogu. Artykuł Docker Compose na VPS szczegółowo omawia ten układ plików oraz zasady dotyczące własności 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 na każdej stronie repozytorium wyświetli się 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 gitea/gitea lub jako pojedynczy plik binarny z jedną jednostką systemd i jednym plikiem app.ini; jej obecne stabilne wydanie to 1.27.1 (stan na sierpień 2026 roku).

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 dokonuje zapisu jednocześnie, ponieważ SQLite szereguje operacje zapisu, a długotrwałe zadania CI generują ciągły ruch. 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ólną historię. 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 już nie. Forgejo v10.0, wydane w styczniu 2025 roku, było ostatnim wydaniem obsługującym bezpośrednią migrację bazy danych z Gitea, i to tylko z wersji Gitea v1.22 lub starszej. W sierpniu 2026 roku Gitea znajduje się w wersji 1.27.1, 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 istotny jest model zarządzania lub oczekujesz, że projekt pozostanie w rękach organizacji non-profit, wybierz Forgejo. Jeśli zależy Ci na większej bazie instalacyjnej i możliwości uzyskania wsparcia komercyjnego, wybierz Gitea. Oba projekty są rozwijane otwarcie i często publikują nowe wersje: Forgejo wydaje stabilną wersję co trzy miesiące oraz wersję LTS (long term support) raz w roku; w sierpniu 2026 roku aktualną wersją jest v16.0.2, a wersją LTS v15.0.6.

Poziom 3: koszty GitLab przed rozpoczęciem pracy

GitLab CE to oprogramowanie innej klasy. Jedna instancja stanowi zestaw 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 z wymaganiami GitLab określa 16 GB pamięci RAM i 8 vCPU jako bazę dla instalacji jednowęzłowej, przy czym 8 GB wskazano jako dolną granicę 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 sierpień 2026 roku; wartości te rosły na przestrzeni lat, dlatego przed doborem serwera należy ponownie sprawdzić dokumentację.

W zamian za te zasoby otrzymuje się konkretne funkcjonalności: rejestr kontenerów, rejestr pakietów, precyzyjne uprawnienia, 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 potrzebny 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 z kluczem nadaje posiadaczowi wszystkie uprawnienia danego 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 przekierowywanie portów, przekierowywanie 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 zmiennej $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 oraz Gitea nadpisują plik authorized_keys, umieszczając w nim 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 pozwala na indywidualne uprawnienia użytkowników: key-3 informuje platformę, który użytkownik nawiązuje połączenie, a ta weryfikuje jego uprawnienia do 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 dostępem 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 wymaga jego wymiany dla wszystkich użytkowników jednocześnie. Należy również usuwać klucze w dniu odejścia użytkownika, ponieważ stary klucz w tym pliku stanowi trwały dostęp, 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ściwy zestaw czynności przed umieszczeniem na nim repozytoriów.

Czy mogę uruchamiać 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; wszystko, co wywołuje GitHub API lub oczekuje infrastruktury hostowanej przez GitHub, nie zadziała.

Należy uwzględnić dwie konsekwencje. Runner uruchamia kontener dla każdego zadania, więc wymaga silnika kontenerów i własnego budżetu 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 żadnego z powyższych działań. Jeśli nadal rozważane są koszty odejścia, co faktycznie daje 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ę katalogu na poziomie systemu plików.

Platformy typu forge przechowują zgłoszenia, pull requesty, użytkowników, klucze oraz uprawnienia w bazie danych, a 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 przed wpisaniem komendy należy zweryfikować lokalizację:

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 maszynie, z której pochodzi, nie jest kopią zapasową. Przywracanie danych to krok, który często jest pomijany: warto rozpakować jeden zrzut na zapasowej maszynie już teraz, aby poznać procedurę w spokojnych warunkach, a nie podczas awarii.

Wybór według scenariusza

Jedna osoba z laptopem i serwerem VPS, bez potrzeby przeglądania kodu w przeglądarce: repozytoria typu bare przez SSH. Brak dodatkowych uruchomionych usług i konieczności aktualizacji oprogramowania.

Ten sam scenariusz, lecz z potrzebą przeglądania kodu w przeglądarce i udostępniania linków: dodaj cgit. Nadal brak bazy danych i usług działających w tle.

Zespół dokonujący wzajemnych przeglądów kodu i śledzący zadania: Forgejo lub Gitea, przy minimum 2 GB pamięci RAM. Przenieś runner CI na drugą maszynę, gdy zadania staną się bardziej obciążające.

Organizacja wymagająca rejestru kontenerów i ścieżek audytu, dysponująca serwerem z 16 GB pamięci RAM: GitLab. Poniżej tego budżetu nie należy uruchamiać tej usługi.

Przejście między pierwszymi trzema poziomami jest tanie, ponieważ we wszystkich przypadkach repozytoria są zwykłymi katalogami Git na dysku. Rozpocznij od najniższego poziomu, który spełnia wymagania. Jeśli zastanawiasz się, co jeszcze warto umieścić na tym samym serwerze, krótka lista usług wartych samodzielnego hostowania zestawia serwer Git z innymi usługami rywalizującymi o zasoby pamięci RAM.

FAQ

Czy VPS o pojemności 1 GB RAM 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 1 GB RAM i 2 rdzenie CPU jako konfigurację wystarczającą dla małych zespołów i projektów; Forgejo to fork Gitea o zbliżonych wymaganiach. Nie należy instalować PostgreSQL ani CI runnera na tej samej maszynie. Jeśli usługa znika bez śladu w logach, należy uruchomić sudo dmesg -T | grep -i oom: linia wskazująca na zabity proces oznacza, że mechanizm OOM (Out of Memory) kernela zakończył działanie usługi. W takim przypadku jedynym rozwiązaniem jest zwiększenie zasobów, a nie zmiana flag konfiguracyjnych.

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

Oba projekty dzielą historię kodu źródłowego i większość funkcji. Gitea powstała jako fork Gogs w 2016 roku, natomiast Forgejo wywodzi się z Gitea pod koniec 2022 roku, po przejęciu kontroli nad znakiem towarowym Gitea przez podmiot komercyjny. Forgejo jest publikowane przez Codeberg e.V., niemiecką organizację non-profit, na licencji GPLv3; Gitea pozostaje na licencji MIT i posiada wsparcie komercyjne. Różnica praktyczna dotyczy ścieżki migracji. Forgejo v10.0 ze stycznia 2025 roku było ostatnim wydaniem obsługującym bezpośrednią migrację bazy danych z Gitea (tylko z wersji Gitea v1.22 lub starszych), dlatego obecnie nie istnieje wspierana ścieżka bezpośredniego przejścia z działającej instancji Gitea.

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ć osobny program typu runner i zarejestrować go w swojej instancji. Wiele opublikowanych akcji działa bez zmian, jednak te korzystające z API GitHub nie będą funkcjonować. 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 obsługuje już 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 dane. 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ę odtwarzania na zapasowej maszynie, aby upewnić się, że proces jest poprawny.