Forgejo, Gitea o cgit: Alin ang Git server 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 iyong VPS ang nagtatakda kung aling bersyon nito ang maaari mong patakbuhin. Hindi kailangan ng Git ng sarili nitong daemon: sapat na ang bare repository at SSH (secure shell) account upang maging gumaganang server sa pinakamaliit na box na maaari mong rentahan. Ang lahat ng lampas dito ay web application na pinipili mong patakbuhin kasama nito, at bawat pag-angat ay nangangailangan ng memory na maaaring wala sa isang maliit na VPS.

May apat na antas. Bare repository sa SSH, na walang ibang nagli-listen na proseso bukod sa mga dati nang nagli-listen. cgit, isang mabilis na read-only web view na walang database. Forgejo o Gitea, isang full forge na may mga account, issue, at pull request sa loob ng ilang daang megabyte. GitLab, na nangangailangan ng server na maraming ulit ang laki kumpara sa iba.

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

Gaano karaming RAM ang talagang kailangan ng bawat option

Dalawa lamang sa mga project na ito ang naglalathala ng hardware figure. Ituring ang inilathalang figure bilang minimum lamang, hindi 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
  }
]

Ayon sa dokumentasyon ng Gitea, karaniwang sapat ang 1 GB na RAM at 2 CPU core para sa maliliit na team at project. Binabanggit din nito na sapat ang Raspberry Pi 3 para sa maliliit na workload. Itinuturing naman ng 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 inilalathalang 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.

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

Tier 0: isang bare repository gamit ang SSH

Walang network daemon ang Git na kailangan mong simulan. Pinapatakbo ng git push sa pamamagitan ng SSH ang git-receive-pack sa remote end 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, dahil sa Ubuntu 24.04, ang bagong home directory ay mode 0750 at hindi ito mababasa ng web view na idaragdag sa hinaharap.

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, na siyang karaniwang hinahawakan ng server. Tinatanggihan ang pag-push sa repository na may working copy gamit ang refusing to update checked out branch: refs/heads/main, at ito ang pinakamadalas na 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 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

Tumatanggap lamang ang git-shell ng 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 maaaring magbasa at magsulat 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 sa bawat request, direktang binabasa nito sa disk ang mga repository, at wala itong sariling state na sine-save. Kasama ito sa universe component ng Ubuntu 24.04.

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

Binabagtas ng scan-path ang directory na iyon at inililista ang bawat repository na makita nito, kaya lumilitaw ang bagong bare repo nang walang karagdagang configuration. Ang cache-size ang bilang ng mga page na naka-cache, at mananatiling naka-off ang caching kapag zero ito. Basahin muna ang inilagay na 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 ililista ng bagong bare repo ang sarili nito bilang Unnamed repository; edit this file 'description' to name the repository. Ayusin iyon 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 dapat malaman bago ito gawing batayan. Read-only ang cgit at wala itong login, kaya public ang lahat ng nasa ilalim ng scan-path: ilayo ang private repository sa directory na iyon, o maglagay ng HTTP basic authentication sa harap ng buong site. Tumatakbo ang CGI bilang web server user, kaya kailangan ng user na iyon na mabagtas ang /srv/git at mabasa ang bawat repository. Ang directory na hindi nito mapasok ay lalabas 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 nagbibigay 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 angkop ang mga ito sa hardware na hindi kayang patakbuhin ang GitLab. Ang Compose file sa ibaba ay mula sa Forgejo documentation, gamit ang image tag na nakalista roon noong August 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 mo makumpleto ang first-run setup, maaaring redirect ito sa /install, na nangangahulugan pa ring gumagana ang service. Kung sa halip ay mag-exit ang container, ownership ang karaniwang sanhi: dapat pagmamay-ari ng UID (user id) sa USER_UID ang ./forgejo directory, kung hindi ay 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 dalawa, may clone command na hindi gumagana para sa sinumang kumopya nito sa bawat repository page. Nasa [server] section ng app.ini ang dalawang setting 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 ang nginx sa harap nito para sa TLS (transport layer security). Pareho ang installation ng Gitea mula sa gitea/gitea image, o bilang single binary na may isang systemd unit at isang app.ini, at ang kasalukuyang stable release nito ay 1.27.1 noong August 2026.

Manatili sa SQLite hangga't maaari. Isang process at isang file lamang ang kailangan ng instance, at nagpapatuloy itong gumana pagkatapos ng reboot nang walang karagdagang service na kailangang i-supervise. Sulit ang PostgreSQL kapag maraming taong sabay-sabay na nagsusulat, dahil sini-serialize ng SQLite ang writes at patuloy na nagsusulat ang mahahabang CI run. Maaaring ilipat ng parehong proyekto ang isang existing instance sa PostgreSQL sa hinaharap, kaya hindi ito desisyong hindi na mababago.

Forgejo o Gitea: ano talaga ang pinagkaiba

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

Magkalapit ang feature sets ng mga ito sa pang-araw-araw na paggamit. Ngunit hindi magkapareho ang migration path. Ang Forgejo v10.0, na inilabas noong January 2025, ang huling release na maaaring direktang gumamit ng Gitea database, at Gitea v1.22 o mas luma lamang ang suportado. Nasa 1.27.1 na ang Gitea noong August 2026, kaya walang supported in-place switch papunta sa Forgejo ang kasalukuyang Gitea instance. Pumili ng isa bago mo ito lagyan ng data, at ituring ang anumang paglipat sa hinaharap bilang export at panibagong import.

Isang maikling tuntunin sa pagpili: Kung mahalaga sa iyo ang governance, o gusto mong manatili ang project sa isang non-profit, gamitin ang Forgejo. Kung gusto mo ng mas malaking install base at commercial support option, gamitin ang Gitea. Pareho silang dine-develop nang open at madalas maglabas ng release. Naglalabas ang Forgejo ng stable release kada tatlong buwan at isang LTS (long term support) release bawat taon. Noong August 2026, ang kasalukuyang release ay v16.0.2, at ang LTS ay v15.0.6.

Tier 3: magkano ang kailangan ng GitLab bago ito gumana

Iba ang uri ng software ng GitLab CE. Ang isang instance ay binubuo ng mga serbisyong nagtutulungan: Puma para sa web application, Sidekiq para sa background jobs, PostgreSQL, Redis, Gitaly para sa repository access, at nginx sa harap. Ini-install ng Omnibus package ang mga ito nang magkakasama, kaya simple ang installation ngunit mataas ang minimum memory requirement.

Itinatala sa requirements page ng GitLab ang 16 GB ng RAM at 8 vCPU bilang baseline para sa single-node installation, at tinutukoy ang 8 GB bilang pinakamababang halaga sa environment na limitado ang memory. Sinasabi rin sa parehong page na i-disable ang swap, dahil malaki ang pagbagal ng instance kapag nag-swap habang may load. Iyan ang mga published figure noong August 2026. Patuloy na tumaas ang mga ito sa paglipas ng mga taon, kaya basahin muli ang page bago magtakda ng laki ng server.

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

Modelo ng SSH access: isang git user at maraming key

Pareho ang paraan ng authentication sa bawat tier dito. May isang Unix account na pinangalanang git, at lahat ng public key ay inilalagay sa ~/.ssh/authorized_keys ng account na iyon. Ang key ang ginagamit para sa authentication. Ang authorisation ay nakabatay sa mga option na inilalagay 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 sa Git:

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

Ang restrict, na available simula 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 ng tinukoy mo, at gumagana pa rin ang Git dahil ipinapadala nito ang request sa $SSH_ORIGINAL_COMMAND.

Ang forge ang sumusulat ng file na iyon para sa iyo, at ito ang tunay na pagkakaiba ng tier 0 at tier 2. Nirerewrite ng Forgejo at Gitea ang authorized_keys gamit ang 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 per-user ang permission kahit iisang Unix account lang ang ginagamit: sinasabi ng key-3 sa forge kung sinong user ang kumokonekta, at sinusuri nito ang user laban sa repository bago ilipat ang anumang object. Huwag mano-manong i-edit ang file na iyon sa box na pinamamahalaan ng forge, dahil nirerewrite ito mula sa database at mawawala ang idinagdag mong linya. Pareho ang mekanismo para sa deploy keys: ang deploy key ay ordinaryong SSH key na naka-register sa isang repository lang, karaniwan ay read-only, at sa forge ginagawa ang pagsusuri sa halip na sa sshd.

Mas mahalaga kaysa sa karamihan ng configuration sa itaas ang dalawang gawi. Mag-issue ng isang key para sa bawat tao o bawat machine. Huwag gumamit ng shared key, dahil kapag ni-revoke ito, kailangan itong i-rotate para sa lahat nang sabay-sabay. Alisin ang mga key sa araw mismo ng pag-alis ng isang tao, dahil ang lumang key sa file na iyon ay permanenteng login na walang nagmo-monitor. Sinasaklaw ng Mahusay na pamamahala ng SSH key sa server ang mga uri ng key at passphrase, at pareho itong naaangkop dito nang walang pagbabago. Kung bago ang box, ang unang sampung minuto sa bagong VPS ang dapat mong gawin bago ka maglagay ng mga repository dito.

Maaari ba akong magpatakbo ng GitHub Actions sa sarili kong Git server?

Maaari kang magpatakbo ng mga workflow na gumagamit ng syntax ng GitHub Actions. Hindi mo maaaring patakbuhin ang GitHub. Naka-enable bilang default ang Forgejo Actions mula pa 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 naka-install at naka-register sa iyong instance gamit ang token mula sa admin settings. Maraming published action ang tumatakbo nang walang pagbabago; hindi gagana ang anumang tumatawag sa GitHub API o umaasa sa infrastructure na naka-host ng GitHub.

Paghandaan ang dalawang epekto. Nagsisimula ang runner ng container para sa bawat job, kaya kailangan nito ng container engine at sarili nitong memory budget. Dahil dito, hindi ito dapat ilagay sa parehong 1 GB box na ginagamit ng forge. Isinasagawa rin ng runner ang anumang nakasaad sa workflow file. Malinaw itong sinasabi sa dokumentasyon ng Forgejo: nagsasagawa ang runner ng remote code execution. Kung maaari, bigyan ito ng 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 compute lamang ang gusto mong patakbuhin 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 pinag-iisipan mo pa kung magkano ang kapalit ng pag-alis, ipinapakita ng mga aktuwal na ibinibigay ng GitHub ang kaibahan ng Git hosting at ng network sa paligid nito.

Mga Backup: kalahati lang ng state ang repositories

Directory ang bare repository, kaya kapag kinopya ito, makokopya ang lahat ng laman nito. Ang mirror clone mula sa ibang machine ay isang aktuwal na backup, at nire-refresh nito ang repository sa mismong 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 ang issues, pull requests, user, key, at permission sa database nito. Kapag repositories lang ang kinopya, mawawala ang lahat ng iyon. Parehong may dump command ang dalawang project na nagsusulat ng database, repositories, configuration, at attachment sa iisang 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. Depende sa image ang configuration path, kaya tingnan 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 lang na bina-backup ay hindi tunay na backup. Ang pag-restore ang hakbang na madalas nilalaktawan. Mag-unpack ng isang dump sa spare box ngayon, para matutuhan mo ang procedure sa mahinahong oras sa halip na sa gitna ng outage.

Pumili batay sa sitwasyon

Isang tao na may laptop at VPS, at walang pangangailangang mag-browse: bare repositories gamit ang SSH. Walang karagdagang service na tumatakbo at walang kailangang i-upgrade.

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

Isang team na nagre-review ng code ng isa't isa at nagta-track ng issues: Forgejo o Gitea, sa server na may 2 GB RAM o higit pa. Ilipat ang CI runner sa pangalawang machine kapag naging mas 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 rito ang budget, 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 sapat para sa pangangailangan. Kung tinutukoy mo kung ano pa ang dapat paglaanan ng space sa parehong server, inilalagay ng shortlist ng mga serbisyong sulit i-self-host ang Git server katabi ng iba pang serbisyong nakikipag-agawan para sa RAM na iyon.

FAQ

Maaari bang magpatakbo ng Forgejo o Gitea ang isang 1 GB VPS?

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 cores. Ang Forgejo ay fork ng Gitea na may katulad na 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 naglalaman ng pangalan ng prosesong pinatay, ibig sabihin ay pinahinto ito ng kernel out-of-memory killer. Mas malaking plan ang kailangan, hindi tuning flag.

Ano ang pagkakaiba ng Forgejo at Gitea?

May pinagsasaluhang kasaysayan ng codebase at karamihan ng mga feature ang mga ito. 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 control sa trademark ng Gitea. Inilalabas ang Forgejo ng Codeberg e.V., isang non-profit sa Germany, sa ilalim ng GPLv3. Nananatiling MIT licensed ang Gitea at sinusuportahan ito ng 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. Kaya walang supported in-place switch ang kasalukuyang Gitea instance.

Maaari ko bang patakbuhin ang GitHub Actions workflows sa isang 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, pero hindi gumagana ang anumang tumatawag sa GitHub API. Nagpapatakbo ang runner ng arbitrary code mula sa iyong mga repository at nagsisimula ng isang container para sa bawat job. Kaya ilagay ito sa sarili nitong host, o kahit sa sarili nitong unprivileged user, at huwag itong ilagay 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. Ina-update ito ng git remote update sa loob ng mirror. 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, sudo -u git forgejo dump -c /etc/forgejo/app.ini, o 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 ekstrang machine upang matiyak na gumagana ang procedure.