Seva bora ya Git ya kujiendeshea: Gitea, Forgejo au cgit

Ni seva ipi ya Git unayopaswa kujiendeshea (self-hosted)

Seva ya Git unayojiendeshea si bidhaa moja tu, na kiasi cha RAM (random access memory) kwenye VPS yako ndicho huamua ni toleo lipi unaweza kuwa nalo. Git haihitaji daemon yake yenyewe: bare repository pamoja na akaunti ya SSH (secure shell) ni seva inayofanya kazi tayari kwenye mashine ndogo zaidi unayoweza kukodisha. Kila kitu kilicho juu ya kiwango hicho ni programu ya wavuti unayochagua kuiendesha kando yake, na kila hatua ya juu inagharimu kumbukumbu ambayo VPS ndogo inaweza isiwe nayo.

Kuna hatua nne. Bare repository kupitia SSH, bila kitu chochote kinachosikiliza (listening) ambacho hakikuwa kikisikiliza awali. cgit, mwonekano wa haraka wa wavuti wa kusoma pekee (read-only) bila database. Forgejo au Gitea, jukwaa kamili lenye akaunti, masuala (issues) na pull requests ndani ya megabytes mia chache. GitLab, ambayo inahitaji seva kubwa mara nyingi zaidi ya nyingine.

Amua kulingana na kazi unayohitaji kufanya, kisha linganisha kiasi cha kumbukumbu na mpango unaolipiwa.

Kiasi cha RAM kinachohitajika kwa kila chaguo

Miradi miwili pekee kati ya hii ndiyo inayochapisha takwimu za maunzi. Ichukulie takwimu iliyochapishwa kama kiwango cha chini kabisa badala ya ahadi, na upime mfano wako mwenyewe pindi utakapokuwa unafanya kazi, kwa kutumia systemd-cgtop au 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 inaandika 1 GB ya RAM ikiwa na CPU cores 2 kama kiasi kinachotosha kwa timu ndogo na miradi, na inataja Raspberry Pi 3 kama kifaa kinachotosha kwa kazi ndogo. GitLab inaandika 16 GB kama msingi wa usakinishaji wa node moja, na 8 GB kama kiwango cha chini kabisa kwa kile ukurasa wake unachokiita mazingira yenye uhaba wa kumbukumbu. Forgejo haichapishi mahitaji yoyote ya maunzi. Ni fork ya Gitea na inafanya kazi kama hiyo, kwa hivyo takwimu ya Gitea ndiyo mwongozo wa karibu zaidi uliopo.

Hii inamaanisha nini kwenye VPS ya 1 GB: bare repositories na cgit vinafaa na bado kunabaki nafasi, kwa sababu hakuna hata moja inayotumia huduma inayoendelea kukaa kwenye kumbukumbu. Forgejo au Gitea itaanza na itahudumia timu ndogo kwenye SQLite, lakini unakaa kwenye kiwango cha chini kabisa kilichoandikwa, kwa hivyo acha PostgreSQL na CI (continuous integration) runner nje ya seva hiyo. Ikiwa kiolesura cha wavuti kinapotea bila kutoa kosa, endesha sudo dmesg -T | grep -i oom na utafute mstari kama Out of memory: Killed process 1181 (forgejo), ambao unamaanisha kuwa kernel out of memory killer imeifunga. GitLab kwenye seva ya 1 GB si tatizo la kurekebisha usanidi. Haitafanya kazi.

Tier 0: hazina ya msingi kupitia SSH

Git haina daemon ya mtandao unayopaswa kuanzisha. git push kupitia SSH huendesha git-receive-pack upande wa pili kama mchakato wa kawaida wa Unix, kwa hivyo akaunti yoyote unayoweza kufikia kwa kutumia key tayari ni Git remote. Tengeneza akaunti moja kwa ajili ya hazina (repositories), na uweke hazina hizo nje ya saraka yake ya nyumbani (home directory), kwa sababu kwenye Ubuntu 24.04 saraka mpya ya nyumbani ina mode 0750 na mtazamo wa wavuti (web view) utakaoongezwa baadaye hautaweza kuisoma.

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 hutengeneza hazina isiyo na nakala ya kufanyia kazi (working copy), ambayo ndiyo kitu ambacho seva huhifadhi. Kusukuma (push) data kwenye hazina yenye working copy hukataliwa na refusing to update checked out branch: refs/heads/main, na hilo ndilo kosa la kawaida zaidi katika ngazi hii.

Sasa ipatie akaunti hiyo key na uifanye clone.

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

Push ya kwanza iliyofanikiwa huishia na * [new branch] main -> main. Ile inayoishia na git@vps.example.com: Permission denied (publickey) haikuidhinishwa, kwa hivyo soma log ya seva kwa kutumia sudo journalctl -u ssh -n 20. Mstari unaosomeka Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys unamaanisha kuwa mode ya faili si sahihi, kwa sababu sshd hupuuza faili ya key ambayo watumiaji wengine wanaweza kuiandikia.

Kisha ondoa uwezo wa shell kutoka kwa akaunti hiyo.

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

git-shell hukubali tu amri chache ambazo Git hutuma kupitia SSH, kwa hivyo kuingia kwa njia ya mwingiliano (interactive login) sasa husimama na ujumbe badala ya prompt:

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

Hiyo ndiyo seva nzima. Hakuna database, na hakuna mchakato wa wavuti wa kusasisha. Unachopoteza ni kila kitu ambacho jukwaa la usimamizi wa code (forge) hutoa: hakuna kuvinjari, hakuna kifuatiliaji cha masuala (issue tracker), hakuna pull requests, na hakuna ruhusa kwa kila mtumiaji. Kila key iliyo kwenye faili hiyo inaweza kusoma na kuandika kila hazina inayomilikiwa na mtumiaji git.

Tier 1: cgit inakupa mwonekano wa wavuti bila database

cgit ni programu ya CGI (common gateway interface) iliyoandikwa kwa C. Seva ya wavuti huiendesha mara moja kwa kila ombi, inasoma hazina (repositories) moja kwa moja kutoka kwenye diski, na haihifadhi hali yoyote ya kwake yenyewe. Ubuntu 24.04 inayo kwenye sehemu ya universe.

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

Ielekeze kwenye saraka ya hazina katika /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 hupitia saraka hiyo na kuorodhesha kila hazina inayoipata, kwa hivyo hazina mpya ya bare huonekana bila usanidi wa ziada. cache-size ni idadi ya kurasa zilizohifadhiwa kwenye cache, na caching hubaki imezimwa wakati thamani hiyo ni sifuri. Soma kile ambacho kifurushi chako tayari kimekiweka katika /etc/cgitrc kabla ya kuongeza mistari, kwa sababu kifurushi cha Debian na Ubuntu huja na chaguo-msingi zake.

Kila ingizo huonyesha mstari wa kwanza wa faili ya description ya hazina, kwa hivyo hazina mpya ya bare hujiorodhesha kama Unnamed repository; edit this file 'description' to name the repository. Rekebisha hilo mara moja kwa kila hazina:

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

Kuna mipaka miwili inayofaa kujulikana kabla ya kuijenga. cgit ni ya kusoma pekee (read-only) na haina login, kwa hivyo kila kitu chini ya scan-path ni cha umma: weka hazina ya faragha nje ya saraka hiyo, au weka HTTP basic authentication mbele ya tovuti nzima. Na CGI huendeshwa kama mtumiaji wa seva ya wavuti, kwa hivyo mtumiaji huyo anahitaji ruhusa ya kupitia /srv/git na kusoma kila hazina. Saraka ambayo haiwezi kuingia huonekana kama index tupu badala ya kutoa kosa.

Tier 2: Forgejo au Gitea kwa ajili ya masuala (issues) na pull requests

Forgejo na Gitea ni dhana moja: binary moja ya Go inayotoa jukwaa la wavuti lenye watumiaji, mashirika, masuala, pull requests, releases, sajili ya vifurushi (package registry) na mfumo wa CI uliounganishwa ndani. Binary pamoja na SQLite ndiyo usakinishaji mzima, ndiyo maana zinafaa kwenye vifaa ambavyo GitLab haiwezi kufanya kazi. Faili ya Compose iliyo hapa chini ni ile iliyo kwenye nyaraka za Forgejo, ikiwa na image tag iliyotajwa kufikia Agosti 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

Mstari wa curl unapaswa kuchapisha mstari wa hali ya HTTP. Kabla ya kumaliza usanidi wa mara ya kwanza, inaweza kuwa ni redirect kwenda /install, ambayo bado inamaanisha huduma inafanya kazi. Ikiwa container inazima badala yake, sababu ya kawaida ni umiliki: saraka ya ./forgejo lazima iwe mali ya UID (kitambulisho cha mtumiaji) katika USER_UID, au mchakato hauwezi kuandika kwenye saraka yake ya data. Docker Compose kwenye VPS inashughulikia mpangilio huo wa faili na kanuni ya umiliki wa volume kikamilifu.

Majibu mawili kwenye ukurasa wa usanidi huamua kama URL za clone zitafanya kazi. Port ya SSH lazima iwe 222, kwa sababu faili ya Compose inaelekeza port 222 ya host kwenye port 22 ya container, na domain lazima iwe jina ambalo watu wataandika kihalisi. Ukikosea mojawapo, kila ukurasa wa repository utatoa amri ya clone inayoshindwa kwa kila mtu anayeinakili. Zote mbili zinapatikana katika sehemu ya [server] ya app.ini baadaye, kama SSH_PORT, SSH_DOMAIN na ROOT_URL.

Kwa instance ya umma, chapisha port ya wavuti kwenye loopback address pekee ('127.0.0.1:3000:3000') na uweke nginx mbele yake kwa ajili ya TLS (transport layer security). Gitea inasakinishwa kwa njia ile ile kutoka kwa image ya gitea/gitea, au kama binary moja yenye unit moja ya systemd na app.ini moja, na release yake ya sasa ya stable ni 1.27.1 kufikia Agosti 2026.

Endelea kutumia SQLite kadiri uwezavyo. Inaiweka instance kwenye mchakato mmoja na faili moja, na inastahimili reboot bila huduma ya ziada ya kusimamia. PostgreSQL inastahili gharama yake wakati watu kadhaa wanaandika kwa wakati mmoja, kwa sababu SQLite hufanya uandishi kwa mfululizo na CI runs ndefu huandika mara kwa mara. Miradi yote miwili inaweza kuhamisha instance iliyopo kwenda PostgreSQL baadaye, kwa hivyo hii si uamuzi ambao utabaki nao milele.

Forgejo au Gitea: nini hasa kinatofautiana

Asili yao inafanana. Gitea ilitokana na Gogs mnamo 2016. Mwishoni mwa 2022, udhibiti wa kikoa na chapa ya biashara ya Gitea ulihamishiwa kwa kampuni ya Gitea Ltd, na watunza programu kadhaa wakishirikiana na Codeberg wakaanzisha Forgejo. Forgejo inachapishwa na Codeberg e.V., chama kisicho cha faida kilichosajiliwa nchini Ujerumani, na ilihamia kutoka leseni ya MIT kwenda GPLv3 (GNU general public license version 3) mnamo 2024. Gitea inabaki na leseni ya MIT na inaendelezwa kwa usaidizi wa kibiashara.

Katika matumizi ya kila siku, seti za vipengele ziko karibu sana. Njia ya kuhama kati yao si rahisi. Forgejo v10.0, ya Januari 2025, ilikuwa toleo la mwisho lililoweza kutumia database ya Gitea moja kwa moja, na hilo liliwezekana tu kutoka Gitea v1.22 au matoleo ya zamani zaidi. Gitea iko kwenye toleo la 1.27.1 kufikia Agosti 2026, kwa hivyo mfano wa sasa wa Gitea hauna njia inayoungwa mkono ya kuhama moja kwa moja kwenda Forgejo. Chagua moja kabla ya kuijaza data, na chukulia hatua yoyote ya kuhama baadaye kama usafirishaji (export) na uingizaji upya (re-import).

Kanuni fupi ya kuchagua. Ikiwa utawala wa mradi ni muhimu kwako, au unataka mradi ubaki chini ya shirika lisilo la faida, tumia Forgejo. Ikiwa unataka msingi mkubwa wa watumiaji na chaguo la usaidizi wa kibiashara, tumia Gitea. Zote mbili zinatunzwa hadharani na hutoa matoleo mara kwa mara: Forgejo hutoa toleo thabiti kila baada ya miezi mitatu na toleo la LTS (long term support) kila mwaka, huku v16.0.2 ikiwa toleo la sasa na v15.0.6 ikiwa toleo la LTS kufikia Agosti 2026.

Tier 3: gharama za GitLab kabla ya kuanza kufanya kazi

GitLab CE ni darasa tofauti la programu. Instance moja ni mkusanyiko wa huduma zinazoshirikiana: Puma kwa ajili ya programu ya wavuti, Sidekiq kwa ajili ya kazi za nyuma (background jobs), PostgreSQL, Redis, Gitaly kwa ajili ya kufikia hazina (repository), na nginx mbele. Kifurushi cha Omnibus husakinisha huduma hizi pamoja, jambo linalorahisisha usakinishaji lakini likiweka kiwango cha chini cha matumizi ya kumbukumbu (RAM) kuwa juu.

Ukurasa wa mahitaji ya GitLab unaeleza kuwa 16 GB ya RAM na 8 vCPU ndio msingi wa usakinishaji wa node moja, huku 8 GB ikitajwa kama kiwango cha chini kabisa katika mazingira yenye kumbukumbu finyu. Ukurasa huo huo unakuelekeza kuzima swap, kwa sababu kutumia swap wakati wa mzigo mkubwa kunashusha utendaji wa instance vibaya sana. Hizo ndizo takwimu zilizochapishwa kufikia Agosti 2026, na zimeendelea kupanda kadiri miaka inavyokwenda, kwa hivyo soma ukurasa huo tena kabla ya kuchagua ukubwa wa seva.

Unapata vitu halisi kwa bajeti hiyo: container registry, package registry, ruhusa za kiwango cha juu (fine-grained permissions), vipengele vya kufuata sheria na ukaguzi (compliance and audit), na CI ambayo imefanyiwa majaribio kwa kiwango kikubwa. Ikiwa hakuna mtu katika timu yako anayeweza kutaja kitu kutoka kwenye orodha hiyo ambacho wanahitaji katika robo hii ya mwaka, unalipia VPS kubwa zaidi bila kupata faida yoyote.

Muundo wa ufikiaji wa SSH: mtumiaji mmoja wa git na funguo nyingi

Kila ngazi hapa inathibitisha utambulisho kwa njia ile ile. Kuna akaunti moja ya Unix inayoitwa git, na kila ufunguo wa umma (public key) huwekwa kwenye ~/.ssh/authorized_keys ya akaunti hiyo. Uthibitishaji ni ufunguo wenyewe. Idhini ni chaguzi zozote unazoandika mbele ya ufunguo kwenye mstari huo huo.

Mstari wa ufunguo wa kawaida humpa mwenye ufunguo uwezo wote wa akaunti hiyo. Amri ya lazima (forced command) huipunguza hadi Git pekee:

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

restrict, inayopatikana tangu OpenSSH 7.2, huzima usambazaji wa port (port forwarding), usambazaji wa wakala (agent forwarding), X11 na utengaji wa PTY (pseudo terminal) kwa neno moja. command= hubadilisha ombi lolote la mteja na lile unalotaja, na Git bado hufanya kazi kwa sababu Git hutuma ombi lake kupitia $SSH_ORIGINAL_COMMAND.

Mfumo wa forge huandika faili hiyo kwa ajili yako, na huo ndio utofauti halisi kati ya ngazi ya 0 na ngazi ya 2. Forgejo na Gitea huandika upya authorized_keys kwa mstari mmoja kwa kila ufunguo uliosajiliwa, kila mmoja ukiwa na amri ya lazima inayotaja ufunguo kwa kitambulisho chake cha database:

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

Amri hiyo ya lazima ndiyo njia ambayo akaunti moja ya Unix iliyoshirikiwa inakuwa na idhini kwa kila mtumiaji: key-3 huambia forge ni mtumiaji yupi anayeunganisha, na huangalia mtumiaji huyo dhidi ya hazina (repository) kabla ya kitu chochote kusogezwa. Usihariri faili hiyo kwa mkono kwenye seva inayodhibitiwa na forge, kwa sababu huandikwa upya kutoka kwenye database na mstari wako utapotea. Funguo za kupeleka (deploy keys) hutoka kwenye utaratibu ule ule: deploy key ni ufunguo wa kawaida wa SSH uliosajiliwa kwa hazina moja, kwa kawaida wa kusoma pekee (read-only), huku ukaguzi ukifanywa kwenye forge badala ya sshd.

Tabia mbili ni muhimu zaidi kuliko usanidi wowote hapo juu. Toa ufunguo mmoja kwa kila mtu au kila mashine, usiwahi kushiriki ufunguo, kwa sababu kubatilisha ufunguo ulioshirikiwa inamaanisha kuubadilisha kwa kila mtu kwa wakati mmoja. Na ondoa funguo siku mtu anapoondoka, kwa sababu ufunguo wa zamani kwenye faili hiyo ni njia ya kudumu ya kuingia ambayo hakuna anayeifuatilia. Usimamizi mzuri wa funguo za SSH kwenye seva inashughulikia aina za funguo na misemo ya siri (passphrases), na yote hayo yanatumika hapa bila mabadiliko. Ikiwa seva ni mpya, dakika kumi za kwanza kwenye VPS mpya ndilo jambo sahihi la kufanya kabla ya kuweka hazina juu yake.

Je, ninaweza kuendesha GitHub Actions kwenye seva yangu ya Git?

Unaweza kuendesha workflow zilizoandikwa kwa sintaksia ya GitHub Actions. Huwezi kuendesha GitHub yenyewe. Forgejo Actions imewezeshwa kwa chaguo-msingi tangu Forgejo v1.21 na inasoma faili za workflow kutoka .forgejo/workflows katika kila hazina (repository). Gitea Actions inafanya kazi kwa njia ileile na inasoma .gitea/workflows. Zote zinahitaji programu ya pili, yaani runner, ambayo inasakinishwa na kusajiliwa kwenye instance yako kwa kutumia token kutoka kwa mipangilio ya msimamizi (admin settings). Actions nyingi zilizochapishwa hufanya kazi bila mabadiliko; chochote kinachopiga simu kwenye GitHub API au kinachotegemea miundombinu inayohifadhiwa na GitHub hakitafanya kazi.

Jipange kwa matokeo mawili. Runner huanzisha container kwa kila kazi, kwa hivyo inahitaji injini ya container na bajeti yake ya kumbukumbu (memory), ndiyo maana haipaswi kuwekwa kwenye seva ileile ya 1 GB inayohifadhi forge. Na runner hutekeleza chochote kinachoandikwa kwenye faili ya workflow, jambo ambalo nyaraka za Forgejo zinalieleza wazi: runner hufanya remote code execution. Ipe host yake yenyewe inapowezekana, au angalau mtumiaji asiye na upendeleo (unprivileged user) na token ya usajili iliyowekewa mipaka kwa hazina moja pekee.

Ikiwa hazina zako zitaendelea kubaki kwenye GitHub na unataka tu nguvu ya kompyuta (compute) kwenye maunzi unayoyadhibiti, huo ni usanidi tofauti wenye hatua tofauti: runner ya GitHub Actions inayojiendesha yenyewe huunganishwa kwenye hazina ya GitHub na haihitaji chochote kati ya hivi. Ikiwa bado unapima gharama za kuhama, kile ambacho GitHub inakupa kihalisi kinatenganisha uhifadhi wa Git na mtandao unaozunguka.

Hifadhi rudufu: hazina za msimbo ni nusu tu ya hali ya mfumo

Hazina tupu (bare repository) ni saraka, kwa hivyo kuinakili kunanakili kila kitu kilichomo. Mirror clone kutoka mashine nyingine ni hifadhi rudufu halisi, na inajisasisha yenyewe mahali ilipo:

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

Hiyo huvuta kila ref na kila object. Haivuti hooks za upande wa seva au faili ya description, kwa hivyo weka nakala ya kiwango cha faili ya saraka hiyo pia ikiwa unatumia hooks.

Forge huhifadhi masuala (issues), maombi ya kuvuta (pull requests), watumiaji, funguo na ruhusa katika hifadhidata yake, na nakala ya hazina pekee hupoteza yote hayo. Miradi yote miwili husafirisha amri ya dump inayoandika hifadhidata, hazina, usanidi na viambatisho kwenye kumbukumbu moja:

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

Chini ya Docker amri hiyo hiyo huendeshwa ndani ya container, na njia ya usanidi inategemea image, kwa hivyo angalia kabla ya kuandika:

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

Iendeshe kama mtumiaji anayemiliki data, na uandike kumbukumbu hiyo kwenye saraka ambayo mtumiaji huyo anaweza kuandika. Kisha nakili kumbukumbu hiyo nje ya seva, kwa sababu hifadhi rudufu inayopatikana kwenye mashine inayochelezwa pekee si hifadhi rudufu. Kurejesha ni hatua ambayo watu huruka: fungua dump moja kwenye mashine ya ziada sasa hivi, ili ujifunze utaratibu huo wakati wa utulivu badala ya wakati wa hitilafu.

Chagua kulingana na hali

Mtu mmoja mwenye kompyuta ndogo na VPS, bila kuhitaji kivinjari: tumia bare repositories kupitia SSH. Hakuna huduma ya ziada inayofanya kazi na hakuna kitu cha kusasisha.

Hali hiyo hiyo, pamoja na kutaka kusoma msimbo kwenye kivinjari na kutuma viungo vyake: ongeza cgit. Bado hakuna database, na hakuna huduma inayokaa kwenye kumbukumbu.

Timu inayokagua msimbo wa kila mmoja na kufuatilia masuala: tumia Forgejo au Gitea, kwenye 2 GB ya RAM au zaidi. Hamisha CI runner kwenye seva ya pili pindi kazi zitakapokuwa nyingi.

Shirika linalohitaji container registry na audit trails, likiwa na 16 GB ya kutumia kwenye seva: tumia GitLab. Chini ya bajeti hiyo, usianze kuitumia.

Kupanda kutoka ngazi tatu za kwanza ni rahisi, kwa sababu katika zote hizo, hazina (repositories) ni saraka za kawaida za Git kwenye diski. Anza kwenye ngazi ya chini kabisa inayokidhi mahitaji yako. Ikiwa unatafakari ni nini kingine kinachostahili nafasi kwenye seva hiyo hiyo, orodha fupi ya kile kinachofaa kujihudumia huweka seva ya Git kando ya huduma nyingine zinazoshindania RAM hiyo.

FAQ

Je, VPS ya 1 GB inaweza kuendesha Forgejo au Gitea?

Ndiyo, kwa timu ndogo, ukitumia SQLite, na bila programu nyingine nzito kwenye seva hiyo. Nyaraka za Gitea zinaeleza kuwa 1 GB ya RAM na CPU cores 2 kwa kawaida zinatosha kwa timu na miradi midogo, na Forgejo ni fork ya Gitea yenye muundo uleule. Usiongeze PostgreSQL au CI runner kwenye mashine hiyo. Ikiwa huduma itapotea bila kutoa error kwenye log yake, endesha sudo dmesg -T | grep -i oom: mstari unaotaja mchakato uliositishwa (killed process) unamaanisha kuwa kernel out of memory killer imeifunga, na suluhisho ni kupata mpango mkubwa zaidi wa seva badala ya kutumia flag ya kurekebisha utendaji.

Kuna tofauti gani kati ya Forgejo na Gitea?

Zinashiriki historia ya codebase na vipengele vingi. Gitea ilitokana na Gogs mwaka 2016, na Forgejo ilitokana na Gitea mwishoni mwa 2022 baada ya udhibiti wa alama ya biashara ya Gitea kuhamishiwa kwa kampuni. Forgejo inachapishwa na Codeberg e.V., shirika lisilo la faida nchini Ujerumani, chini ya leseni ya GPLv3; Gitea inabaki na leseni ya MIT ikiwa na ufadhili wa kibiashara. Tofauti ya kiutendaji ni njia ya kuhama (migration). Forgejo v10.0, ya Januari 2025, ilikuwa toleo la mwisho lililoweza kuchukua database ya Gitea moja kwa moja, na kutoka Gitea v1.22 au ya zamani zaidi pekee, kwa hivyo instance ya sasa ya Gitea haina njia ya moja kwa moja ya kubadili (in-place switch) inayoungwa mkono.

Je, ninaweza kuendesha GitHub Actions workflows kwenye seva ya Git inayojiendesha yenyewe?

Forgejo Actions na Gitea Actions zote huendesha workflows zilizoandikwa kwa sintaksia ya GitHub Actions YAML, zinazosomwa kutoka .forgejo/workflows na .gitea/workflows. Unasakinisha programu tofauti ya runner na kuisajili kwenye instance yako. Actions nyingi zilizochapishwa hufanya kazi bila mabadiliko, wakati chochote kinachopiga simu kwenye GitHub API hakifanyi kazi. Runner huendesha code yoyote kutoka kwenye repositories zako na kuanzisha container kwa kila job, kwa hivyo ipe host yake yenyewe, au angalau mtumiaji asiye na upendeleo (unprivileged user), na uiweke mbali na seva ya 1 GB ambayo tayari inaendesha forge.

Ninawezaje kuhifadhi nakala (backup) ya seva ya Git inayojiendesha yenyewe?

Kwa repositories tupu (bare repositories), git clone --mirror kutoka mashine nyingine hunakili kila ref na object, na git remote update ndani ya mirror hiyo huifanya upya. Kwa Forgejo au Gitea, repositories ni sehemu tu ya hali ya mfumo, kwa sababu issues, pull requests, watumiaji na funguo (keys) hukaa kwenye database. Tumia dump iliyojengewa ndani, sudo -u git forgejo dump -c /etc/forgejo/app.ini, au amri hiyo hiyo ndani ya container kwa usakinishaji wa Docker. Nakili archive hiyo nje ya seva, na ujaribu kuirejesha kwenye mashine ya ziada mara moja ili uhakikishe kuwa utaratibu huo unafanya kazi.