Forgejo, Gitea o cgit: Alin ang para sa VPS mo?

Aling self-hosted Git server ang dapat mong patakbuhin

Hindi iisang produkto ang self-hosted Git server, at ang RAM (random access memory) ng VPS mo ang nagtatakda kung aling bersyon nito ang kaya mong patakbuhin. Hindi nangangailangan ang Git ng sarili nitong daemon: gumaganang server na ang isang bare repository kasama ang SSH (secure shell) account, kahit sa pinakamaliit na box na maaari mong rentahan. Ang lahat ng higit pa rito ay isang web application na pinipili mong patakbuhin kasabay nito, at bawat susunod na antas ay nangangailangan ng memory na maaaring wala sa isang maliit na VPS.

May apat na antas. Una, bare repository sa SSH, na walang bagong nakikinig na proseso. Ikalawa, cgit, isang mabilis na read-only web view na walang database. Ikatlo, Forgejo o Gitea, isang kumpletong forge na may mga account, issue, at pull request sa ilang daang megabyte. Ikaapat, GitLab, na nangangailangan ng server na maraming beses na mas malaki kaysa sa iba.

Magpasya batay sa mga gawaing kailangan mong gawin, pagkatapos ay ihambing ang memory figure sa planong binabayaran mo.

Kung gaano karaming RAM ang talagang kailangan ng bawat option

Dalawa lamang sa mga project na ito ang naglalabas ng hardware figure. Ituring ang inilabas na figure bilang minimum, hindi bilang garantiya, at sukatin ang sarili mong instance kapag tumatakbo na ito gamit ang systemd-cgtop o 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
  }
]

Nakadokumento sa Gitea na karaniwang sapat ang 1 GB ng RAM na may 2 CPU core para sa maliliit na team at project. Binabanggit din nito na sapat ang Raspberry Pi 3 para sa maliliit na workload. Nakadokumento naman sa GitLab ang 16 GB bilang baseline para sa single-node installation, at 8 GB bilang pinakamababang antas para sa tinatawag ng sarili nitong page na memory constrained environment. Walang inilalabas na hardware requirement ang Forgejo. Fork ito ng Gitea at katulad nitong kumikilos, kaya ang figure ng Gitea ang pinakamalapit na published guide na mayroon ka.

Ganito ang ibig sabihin nito sa isang 1 GB VPS: kasya ang bare repository at cgit na may natitirang resources, dahil walang resident service na pinapatakbo ang alinman sa mga ito. Magsisimula ang Forgejo o Gitea at makapaglilingkod sa isang maliit na team gamit ang SQLite, pero nasa documented floor ka na. Kaya huwag paganahin ang PostgreSQL at ang CI (continuous integration) runner sa server na iyon. Kung mawawala ang web interface nang walang error, patakbuhin ang sudo dmesg -T | grep -i oom at hanapin ang linyang gaya ng Out of memory: Killed process 1181 (forgejo). Ibig sabihin nito, winasak ito ng kernel out-of-memory killer. Ang GitLab sa isang 1 GB server ay hindi malulutas sa pamamagitan ng tuning. Hindi ito tatakbo.

Tier 0: bare repository sa SSH

Walang network daemon ang Git na kailangan mong simulan. Ang git push sa SSH ay nagpapatakbo ng git-receive-pack sa remote host bilang ordinaryong Unix process, kaya anumang account na maaabot mo gamit ang key ay isa nang Git remote. Gumawa ng isang account para sa mga repository, at ilagay ang mga repository sa labas ng home directory nito. Sa Ubuntu 24.04, ang bagong home directory ay mode 0750, kaya hindi ito mababasa ng web view na idaragdag sa ibang pagkakataon.

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

Gumagawa ang --bare ng repository na walang working copy. Ito ang uri ng repository na inilalagay sa server. Tinatanggihan ang pag-push sa repository na may working copy gamit ang refusing to update checked out branch: refs/heads/main. Ito ang pinakakaraniwang pagkakamali sa tier na ito.

Ngayon, bigyan ng key ang account at i-clone ang 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

Nagtatapos sa * [new branch] main -> main ang unang push na matagumpay. Ang push na nagtatapos sa git@vps.example.com: Permission denied (publickey) ay hindi na-authenticate, kaya basahin ang server log gamit ang sudo journalctl -u ssh -n 20. Ang linyang may Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys ay nangangahulugang mali ang file mode, dahil binabalewala ng sshd ang key file na maaaring sulatan ng ibang user.

Pagkatapos, alisin ang shell sa account.

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

Tinatanggap lamang ng git-shell ang iilang command na ipinapadala ng Git sa SSH, kaya ang interactive login ay hihinto na may mensahe sa halip na prompt:

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

Iyon na ang buong server. Walang database at walang web process na kailangang i-upgrade. Ang mawawala sa iyo ay ang lahat ng feature ng forge: walang browsing, issue tracker, pull request, o per-user permission. Bawat key sa file na iyon ay makakabasa at makakasulat sa bawat repository na pagmamay-ari ng user na git.

Tier 1: Nagbibigay ang cgit ng web view nang walang database

Ang cgit ay isang CGI (common gateway interface) program na nakasulat sa C. Pinapatakbo ito ng web server isang beses sa bawat request, direktang binabasa nito sa disk ang mga repository, at wala itong sariling state na sine-save. Kasama ito ng Ubuntu 24.04 sa universe component.

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

Ituro ito sa directory ng repository sa /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

Ini-scan ng scan-path ang directory na iyon at inililista ang bawat repository na makita nito, kaya awtomatikong lumalabas ang bagong bare repo nang walang karagdagang configuration. Ang cache-size ang bilang ng mga naka-cache na page, at mananatiling naka-off ang caching kapag zero ito. Basahin muna ang inilagay ng package sa /etc/cgitrc bago magdagdag ng mga linya, dahil may sarili nang ilang default ang Debian at Ubuntu package.

Ipinapakita ng bawat entry ang unang linya ng description file ng repository, kaya ang bagong bare repo ay nakalilista bilang Unnamed repository; edit this file 'description' to name the repository. Ayusin ito nang isang beses sa bawat 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

May dalawang limitasyong mahalagang malaman bago mo ito gamitin. Read-only ang cgit at wala itong login, kaya public ang lahat ng nasa ilalim ng scan-path: huwag maglagay ng private repository sa directory na iyon, o maglagay ng HTTP basic authentication sa harap ng buong site. Tumatakbo rin ang CGI bilang user ng web server, kaya kailangang makapasok ang user na iyon sa /srv/git at mabasa ang bawat repository. Kapag hindi nito mapasok ang isang directory, lalabas iyon bilang walang laman na index sa halip na error.

Tier 2: Forgejo o Gitea para sa issues at pull requests

Pareho ang konsepto ng Forgejo at Gitea: isang Go binary na naghahatid ng web forge na may users, organisations, issues, pull requests, releases, package registry, at built-in CI system. Ang binary kasama ang SQLite ang buong installation, kaya kasya ang mga ito sa hardware na hindi kayang patakbuhin ang GitLab. Ang Compose file sa ibaba ay mula sa Forgejo documentation, kasama ang image tag na tinutukoy nito noong October 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

Dapat mag-print ang curl line ng HTTP status line. Bago matapos ang first-run setup, maaaring redirect ito sa /install, na nangangahulugan pa ring gumagana ang service. Kung nag-e-exit naman ang container, ownership ang karaniwang sanhi: kailangang pagmamay-ari ng UID (user id) sa USER_UID ang ./forgejo directory; kung hindi, hindi maisusulat ng process ang sarili nitong data directory. Sinasaklaw nang buo ng Docker Compose sa isang VPS ang file layout na ito at ang volume ownership rule.

Dalawang sagot sa setup page ang nagtatakda kung gagana ang clone URLs. Dapat 222 ang SSH port, dahil mina-map ng Compose file ang host port 222 sa port 22 ng container, at dapat ang domain ay ang pangalang aktuwal na ita-type ng mga user. Kapag mali ang alinman sa mga ito, may clone command na hindi gagana para sa sinumang kokopya nito sa bawat repository page. Parehong makikita ang mga ito sa [server] section ng app.ini pagkatapos, bilang SSH_PORT, SSH_DOMAIN at ROOT_URL.

Para sa public instance, i-publish lamang ang web port sa loopback address ('127.0.0.1:3000:3000'), at ilagay sa harap nito ang nginx para sa TLS (transport layer security). Pareho ang installation ng Gitea mula sa docker.gitea.com/gitea image na ginagamit ng documentation nito, o bilang isang single binary na may isang systemd unit at isang app.ini. Ang kasalukuyang stable release nito ay v28.1.0, na inilabas noong 6 October 2026. Noong v28.0.0 sa pagtatapos ng September, inalis ng project ang dating 1. prefix, kaya 28 ang release pagkatapos ng 1.27, hindi 1.28.

Manatili sa SQLite hangga't maaari. Isang process at isang file lamang ang kailangan nito, at nagpapatuloy itong gumana matapos ang reboot nang walang karagdagang service na kailangang i-supervise. Sulit gamitin ang PostgreSQL kapag sabay-sabay na nagsusulat ang maraming user, dahil sine-serialize ng SQLite ang writes at patuloy na nagsusulat ang mahahabang CI run. Maaaring ilipat ng parehong project ang isang umiiral na instance sa PostgreSQL kalaunan, kaya hindi ito desisyong hindi na mababago.

Forgejo o Gitea: ano talaga ang pagkakaiba

Magkapareho ang pinagmulan ng mga ito. Nag-fork ang Gitea mula sa Gogs noong 2016. Noong huling bahagi ng 2022, napunta sa isang kompanya, ang Gitea Ltd, ang kontrol sa Gitea domain at trademark. Pagkatapos nito, nagsimula ang ilang maintainer kasama ang Codeberg ng Forgejo. Inilalathala ang Forgejo ng Codeberg e.V., isang non-profit association na rehistrado sa Germany. Lumipat ito mula sa MIT licence patungo sa GPLv3 (GNU general public license version 3) noong 2024. Nananatiling MIT licensed ang Gitea at dine-develop ito na may commercial backing.

Magkalapit ang feature set ng mga ito sa pang-araw-araw na paggamit. Ngunit magkaiba ang migration path. Ang Forgejo v10.0, na inilabas noong Enero 2025, ang huling release na maaaring direktang gumamit ng Gitea database. Gagana lamang ito mula sa Gitea v1.22 o mas luma. Nasa v28.1.0 ang Gitea noong Oktubre 2026. Kaya walang supported in-place switch papuntang Forgejo ang kasalukuyang Gitea instance. Pumili ng isa bago mo ito lagyan ng data. Ituring ang anumang paglipat sa hinaharap bilang export at muling pag-import.

Narito ang maikling tuntunin sa pagpili. Kung mahalaga sa iyo ang governance, o gusto mong manatili ang proyekto sa isang non-profit, gamitin ang Forgejo. Kung gusto mo ng mas malaking install base at commercial support option, gamitin ang Gitea. Parehong pinananatili ang mga ito nang bukas at madalas maglabas ng mga update. Naglalabas ang Forgejo ng stable release bawat tatlong buwan at ng LTS (long term support) release bawat taon. Ang kasalukuyang bersyon noong Oktubre 2026 ay v16.0.5, at ang LTS ay v15.0.9. Sinusuportahan ng Forgejo ang v16 hanggang 29 Oktubre 2026 at ang v15 hanggang 15 Hulyo 2027. Kaya suriin ang releases page nito bago mag-pin ng major version.

Tier 3: magkano ang kinakain ng GitLab bago ito gumawa ng kahit ano

Ibang klase ng software ang GitLab CE. Ang isang instance nito ay binubuo ng magkakaugnay na serbisyo: Puma para sa web application, Sidekiq para sa background jobs, PostgreSQL, Redis, Gitaly para sa repository access, at nginx sa unahan. Pinag-i-install ng Omnibus package ang mga ito nang sabay-sabay, kaya simple ang installation ngunit mataas ang minimum na memory requirement.

Nakatala sa requirements page ng GitLab ang 16 GB RAM at 8 vCPU bilang baseline para sa single-node installation, habang 8 GB ang tinutukoy nitong pinakamababang halaga para sa memory-constrained environment. Sinasabi rin sa parehong page na i-disable ang swap, dahil malaki ang itinatamang degradation sa instance kapag nag-swap ito habang may load. Iyan ang mga published figure hanggang October 2026. Tumaas ang mga ito sa paglipas ng mga taon, kaya basahin muli ang page bago mag-size ng server.

May makukuha kang mga konkretong feature kapalit ng budget na iyon: container registry, package registry, fine-grained permissions, compliance at audit features, at CI na nasubukan sa malakihang scale. Kung walang sinuman sa team mo ang makapagsabi ng feature mula sa listahang iyon na kailangan nila ngayong quarter, nagbabayad ka para sa mas malaking VPS nang walang kapalit.

Ang SSH access model: isang git user at maraming key

Ganito ang paraan ng authentication sa bawat tier. May isang Unix account na pinangalanang git, at inilalagay ang bawat public key sa ~/.ssh/authorized_keys ng account na iyon. Ang key ang ginagamit para sa authentication. Ang authorization ay nakadepende sa anumang options na ilalagay mo bago ang key sa parehong linya.

Ang plain key line ay nagbibigay sa may hawak ng lahat ng kayang gawin ng account na iyon. Nililimitahan ito ng forced command para sa Git:

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

Ang restrict, na available mula noong OpenSSH 7.2, ay nagdi-disable sa port forwarding, agent forwarding, X11, at PTY (pseudo terminal) allocation gamit ang isang salita. Pinapalitan ng command= ang anumang hiniling ng client para gamitin ang tinukoy mo, at gumagana pa rin ang Git dahil ipinapadala ng Git ang request nito sa $SSH_ORIGINAL_COMMAND.

Ang forge ang sumusulat ng file na iyon para sa iyo, at iyon ang tunay na pagkakaiba ng tier 0 at tier 2. Isinusulat muli ng Forgejo at Gitea ang authorized_keys na may isang linya para sa bawat registered key. May forced command ang bawat linya na tumutukoy sa key gamit ang database id nito:

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

Sa pamamagitan ng forced command, nagiging magkahiwalay ang permission ng bawat user kahit iisang Unix account ang ginagamit: sinasabi ng key-3 sa forge kung sinong user ang kumokonekta, at sinusuri nito ang user laban sa repository bago mailipat ang anumang object. Huwag mong manual na i-edit ang file na iyon sa isang forge-managed box, dahil isinusulat itong muli mula sa database at mawawala ang idinagdag mong linya. Pareho ang mekanismo para sa deploy key: ang deploy key ay isang ordinaryong SSH key na naka-register sa isang repository lang. Karaniwan itong read-only, at ginagawa ng forge ang pagsusuri sa halip na sshd.

Mas mahalaga ang dalawang gawi kaysa sa karamihan ng configuration sa itaas. Gumamit ng isang key para sa bawat tao o bawat machine, at huwag gumamit ng shared key, dahil kapag binawi ang shared key, kailangan itong palitan para sa lahat nang sabay-sabay. Alisin din ang mga key sa araw na umalis ang isang tao, dahil ang lumang key sa file na iyon ay permanenteng login na walang sumusubaybay. Sinasaklaw ng Wastong pamamahala ng SSH key sa isang server ang mga uri ng key at passphrase, at pareho itong naaangkop dito. Kung bago ang box, ang unang sampung minuto sa isang bagong VPS ang dapat mong gawin bago ka maglagay ng mga repository rito.

Maaari ko bang patakbuhin ang GitHub Actions sa sarili kong Git server?

Maaari kang magpatakbo ng mga workflow na nakasulat sa syntax ng GitHub Actions. Hindi mo maaaring patakbuhin ang GitHub. Naka-enable bilang default ang Forgejo Actions mula noong Forgejo v1.21 at binabasa nito ang mga workflow file mula sa .forgejo/workflows sa bawat repository. Pareho ang paraan ng paggana ng Gitea Actions at binabasa nito ang .gitea/workflows. Pareho silang nangangailangan ng pangalawang program, ang runner, na dapat i-install at i-register sa iyong instance gamit ang token mula sa admin settings. Maraming naka-publish na action ang gumagana nang walang pagbabago; hindi gumagana ang anumang tumatawag sa GitHub API o umaasa sa infrastructure na naka-host ng GitHub.

Maghanda para sa dalawang epekto. Nagsisimula ang runner ng container para sa bawat job, kaya kailangan nito ng sariling container engine at memory budget. Dahil dito, hindi ito dapat ilagay sa parehong 1 GB box na ginagamit ng forge. Isinasagawa rin ng runner ang anumang nakasulat sa workflow file. Malinaw itong nakasaad sa documentation ng Forgejo: nagsasagawa ang runner ng remote code execution. Kung maaari, ilagay ito sa sarili nitong host. Kung hindi, gumamit man lang ng sarili nitong unprivileged user at registration token na limitado sa isang repository.

Kung mananatili sa GitHub ang iyong mga repository at gusto mo lamang gamitin ang compute resources sa hardware na kontrolado mo, ibang setup ito na may ibang mga hakbang: ang self-hosted GitHub Actions runner ay kumokonekta sa isang GitHub repository at hindi nangangailangan ng alinman sa mga ito. Kung sinusuri mo pa rin ang kapalit ng pag-alis, ipinapakita ng mga aktuwal na ibinibigay ng GitHub kung paano hiwalay ang Git hosting sa network na nakapaligid dito.

Mga Backup: kalahati lamang ng state ang repositories

Ang bare repository ay isang directory, kaya kapag kinopya ito, nakokopya ang lahat ng laman nito. Ang mirror clone mula sa ibang machine ay isang totoong backup, at nire-refresh nito ang repository sa kasalukuyang lokasyon:

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

Kinukuha nito ang bawat ref at bawat object. Hindi nito kinukuha ang server-side hooks o ang description file, kaya magtabi rin ng file-level copy ng directory kung gumagamit ka ng hooks.

Iniimbak ng forge sa database nito ang issues, pull requests, users, keys, at permissions. Kapag repositories lamang ang kinopya, mawawala ang lahat ng iyon. May dump command ang parehong project na nagsusulat ng database, repositories, configuration, at attachments sa isang archive:

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

Sa Docker, tumatakbo ang parehong command sa loob ng container. Nagkakaiba ang configuration path depende sa image, kaya suriin muna ito bago mag-type:

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

Patakbuhin ito bilang user na nagmamay-ari ng data. Isulat ang archive sa directory na maaaring sulatan ng user na iyon. Pagkatapos, kopyahin ang archive palabas ng server. Ang backup na nasa machine lamang na bina-back up ay hindi backup. Ang pag-restore ang hakbang na madalas nilalaktawan. I-unpack ngayon ang isang dump sa isang spare box para matutuhan mo ang procedure sa mahinahong panahon, sa halip na habang may outage.

Pumili ayon sa sitwasyon

Isang tao na may laptop at VPS, at hindi nangangailangan ng web browsing: bare repositories sa SSH. Walang karagdagang service na tumatakbo at walang kailangang i-upgrade.

Pareho sa itaas, pero gusto mong magbasa ng code sa browser at magpadala ng mga link dito: idagdag ang cgit. Wala pa ring database at wala pa ring resident service.

Isang team na nagre-review ng code ng isa't isa at sumusubaybay sa mga issue: Forgejo o Gitea, sa server na may 2 GB RAM o higit pa. Ilipat ang CI runner sa pangalawang machine kapag naging seryoso na ang mga job.

Isang organisasyon na nangangailangan ng container registry at audit trail, at may 16 GB na budget para sa server: GitLab. Kung mas mababa sa budget na ito, huwag itong simulan.

Mura ang pag-akyat sa unang tatlong tier dahil sa lahat ng ito, ordinaryong Git directory sa disk ang mga repository. Magsimula sa pinakamababang tier na kayang tumugon sa pangangailangan. Kung tinutukoy mo kung ano pa ang karapat-dapat bigyan ng space sa parehong server, inilalagay ng shortlist ng mga serbisyong sulit i-self-host ang Git server kasama ng iba pang serbisyong nakikipagkumpitensya para sa RAM na iyon.

FAQ

Maaari bang patakbuhin ng 1 GB VPS ang Forgejo o Gitea?

Oo, para sa maliit na team, gamit ang SQLite, at kung walang ibang mabigat na workload sa server. Ayon sa documentation ng Gitea, karaniwang sapat para sa maliliit na team at proyekto ang 1 GB RAM at 2 CPU core. Ang Forgejo ay fork ng Gitea at kapareho ang ganitong resource requirement. Huwag magdagdag ng PostgreSQL o CI runner sa machine na iyon. Kung nawawala ang serbisyo nang walang error sa sarili nitong log, patakbuhin ang sudo dmesg -T | grep -i oom. Kapag may linyang tumutukoy sa prosesong pinatay, nangangahulugan itong pinatay ito ng kernel out-of-memory killer. Mas malaking plan ang kailangan, hindi tuning flag.

Ano ang pagkakaiba ng Forgejo at Gitea?

May magkasanib silang kasaysayan ng codebase at karamihan ng mga feature. Nag-fork ang Gitea mula sa Gogs noong 2016, at nag-fork naman ang Forgejo mula sa Gitea noong huling bahagi ng 2022 matapos mapunta sa isang kumpanya ang kontrol sa trademark ng Gitea. Ang Forgejo ay inilalathala ng Codeberg e.V., isang non-profit sa Germany, sa ilalim ng GPLv3. Nananatiling MIT licensed ang Gitea at may commercial backing. Ang praktikal na pagkakaiba ay nasa migration path. Ang Forgejo v10.0, na inilabas noong January 2025, ang huling release na maaaring direktang gumamit ng Gitea database, at mula lamang sa Gitea v1.22 o mas luma. Dahil dito, walang supported in-place switch para sa kasalukuyang Gitea instance.

Maaari ko bang patakbuhin ang GitHub Actions workflow sa self-hosted Git server?

Ang Forgejo Actions at Gitea Actions ay parehong nagpapatakbo ng mga workflow na gumagamit ng GitHub Actions YAML syntax. Binabasa ang mga ito mula sa .forgejo/workflows at .gitea/workflows. Mag-install ka ng hiwalay na runner program at i-register ito sa iyong instance. Maraming published action ang gumagana nang walang pagbabago, ngunit hindi gagana ang anumang tumatawag sa GitHub API. Nagpapatakbo ang runner ng arbitrary code mula sa iyong mga repository at nagsisimula ng container para sa bawat job. Kaya ilagay ito sa sarili nitong host, o kahit sa sarili nitong unprivileged user, at huwag itong patakbuhin sa isang 1 GB server na nagpapatakbo na ng forge.

Paano ako magba-back up ng self-hosted Git server?

Para sa bare repository, kinokopya ng git clone --mirror mula sa ibang machine ang bawat ref at object. Nire-refresh ito ng git remote update sa loob ng mirror na iyon. Para sa Forgejo o Gitea, bahagi lamang ng state ang mga repository dahil nasa database ang issues, pull request, user, at key. Gamitin ang built-in dump na sudo -u git forgejo dump -c /etc/forgejo/app.ini, o gamitin ang parehong command sa loob ng container kung Docker install ang gamit. Kopyahin ang archive palabas ng server, at minsang i-restore ito sa isang spare machine upang matiyak mong gumagana ang procedure.