Self-hosted Git server: Forgejo، Gitea یا cgit؟

کون سا self-hosted Git server چلانا چاہیے

self-hosted Git server کوئی ایک product نہیں ہے، اور آپ کے VPS کی RAM (random access memory) یہ طے کرتی ہے کہ آپ اس کی کون سی قسم چلا سکتے ہیں۔ Git کو اپنے کسی daemon کی ضرورت نہیں ہوتی: bare repository اور SSH (secure shell) account سب سے چھوٹے ایسے box پر بھی ایک فعال server فراہم کرتے ہیں جسے آپ کرائے پر لے سکتے ہیں۔ اس سے آگے ہر چیز ایک web application ہے جسے آپ اس کے ساتھ چلانے کا انتخاب کرتے ہیں، اور ہر اگلا درجہ اتنی memory استعمال کرتا ہے جو کسی چھوٹے VPS میں دستیاب نہ ہو۔

اس کے چار درجے ہیں۔ SSH کے ذریعے bare repository، جس میں کوئی ایسی چیز listening نہیں کر رہی ہوتی جو پہلے سے listening نہ ہو۔ cgit، ایک تیز read-only web view، جسے database کی ضرورت نہیں ہوتی۔ Forgejo یا Gitea، ایک مکمل forge، جس میں accounts، issues اور pull requests چند سو megabytes میں دستیاب ہوتے ہیں۔ GitLab، جس کے لیے باقی options کے مقابلے میں کئی گنا بڑا server درکار ہوتا ہے۔

اپنے مطلوبہ کام کی بنیاد پر فیصلہ کریں، پھر memory کی مقدار کا موازنہ اس plan سے کریں جس کی آپ ادائیگی کر رہے ہیں۔

ہر آپشن کو حقیقت میں کتنی RAM درکار ہوتی ہے

ان میں سے صرف دو projects hardware figure شائع کرتے ہیں۔ شائع کردہ figure کو حتمی ضمانت کے بجائے کم از کم حد سمجھیں، اور اپنی instance چلنے کے بعد systemd-cgtop یا 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 کے مطابق چھوٹی teams اور projects کے لیے 2 CPU cores کے ساتھ 1 GB RAM عموماً کافی ہوتی ہے، اور وہ small workloads کے لیے Raspberry Pi 3 کو بھی کافی قرار دیتا ہے۔ GitLab ایک single-node installation کے لیے 16 GB کو baseline، اور اپنی دستاویزات میں memory constrained environment کہلانے والی صورت کے لیے 8 GB کو کم از کم حد قرار دیتا ہے۔ Forgejo کوئی hardware requirement شائع نہیں کرتا۔ یہ Gitea کا fork ہے اور اسی طرح کام کرتا ہے، اس لیے آپ کے پاس دستیاب قریب ترین published guide، Gitea کی figure ہی ہے۔

1 GB VPS پر اس کا مطلب یہ ہے: bare repositories اور cgit کافی گنجائش کے ساتھ چل جاتے ہیں، کیونکہ ان میں سے کوئی بھی resident service نہیں چلاتا۔ Forgejo یا Gitea start ہو جائے گا اور SQLite پر ایک چھوٹی team کو service دے گا، لیکن آپ documented floor پر ہیں، اس لیے PostgreSQL اور CI (continuous integration) runner کو اسی box پر فعال نہ کریں۔ اگر web interface بغیر کسی error کے غائب ہو جائے تو sudo dmesg -T | grep -i oom چلائیں اور Out of memory: Killed process 1181 (forgejo) جیسی line تلاش کریں۔ اس کا مطلب ہے کہ kernel کے out of memory killer نے اسے ختم کر دیا۔ 1 GB box پر GitLab کا مسئلہ tuning کا نہیں ہے۔ یہ نہیں چلے گا۔

درجہ 0: SSH کے ذریعے bare repository

Git میں ایسا network daemon نہیں ہے جسے آپ کو start کرنا پڑے۔ git push، SSH کے ذریعے دور موجود سرے پر git-receive-pack کو عام Unix process کے طور پر چلاتا ہے، اس لیے جس account تک آپ key کے ذریعے پہنچ سکتے ہیں وہ پہلے ہی Git remote ہے۔ repositories کے لیے ایک account بنائیں، اور repositories کو اس کی home directory سے باہر رکھیں، کیونکہ Ubuntu 24.04 میں نئی home directory کا mode 0750 ہوتا ہے اور بعد میں شامل کیا جانے والا web view اس کے اندر موجود files نہیں پڑھ سکتا۔

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 ایسی repository بناتا ہے جس میں working copy نہیں ہوتی، اور server پر یہی مطلوب ہوتا ہے۔ ایسی repository میں push کرنا جس میں working copy موجود ہو، refusing to update checked out branch: refs/heads/main کے ساتھ مسترد کر دیا جاتا ہے، اور اس درجے پر یہی سب سے عام غلطی ہے۔

اب account کو ایک key دیں اور اسے 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

کامیاب first push کا اختتام * [new branch] main -> main پر ہوتا ہے۔ جس push کا اختتام git@vps.example.com: Permission denied (publickey) پر ہو، اس کی authentication ہوئی ہی نہیں، اس لیے server log کو sudo journalctl -u ssh -n 20 کے ذریعے پڑھیں۔ Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys والی line کا مطلب ہے کہ file mode غلط ہے، کیونکہ sshd ایسی key file کو نظرانداز کرتا ہے جس میں دوسرے users لکھ سکتے ہوں۔

اب account سے shell بھی ہٹا دیں۔

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

git-shell صرف وہ چند commands قبول کرتا ہے جو Git، SSH کے ذریعے بھیجتا ہے، اس لیے interactive login اب prompt کے بجائے ایک message کے ساتھ رک جاتا ہے:

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

یہی مکمل server ہے۔ اس میں database نہیں ہے اور upgrade کرنے کے لیے کوئی web process بھی نہیں ہے۔ اس کے بدلے آپ forge کی تمام سہولتیں چھوڑ دیتے ہیں: browsing نہیں، issue tracker نہیں، pull requests نہیں، اور per-user permission بھی نہیں۔ اس file میں موجود ہر key ہر اس repository کو read اور write کر سکتی ہے جس کی ملکیت git user کے پاس ہے۔

درجہ 1: cgit آپ کو database کے بغیر web view فراہم کرتا ہے

cgit ایک CGI (common gateway interface) پروگرام ہے جو C میں لکھا گیا ہے۔ web server اسے ہر request پر ایک بار چلاتا ہے، یہ repositories کو براہِ راست disk سے پڑھتا ہے، اور اپنی کوئی state محفوظ نہیں کرتا۔ Ubuntu 24.04 اسے universe component میں فراہم کرتا ہے۔

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

اسے /etc/cgitrc میں repository directory کی طرف متوجہ کریں:

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 اس directory کو scan کرتا ہے اور ملنے والی ہر repository کی فہرست بناتا ہے، اس لیے نئی bare repo اضافی configuration کے بغیر ظاہر ہو جاتی ہے۔ cache-size cached pages کی تعداد ہے، اور اس کی قدر zero ہونے پر caching بند رہتی ہے۔ نئی lines شامل کرنے سے پہلے دیکھیں کہ آپ کے package نے /etc/cgitrc میں پہلے سے کیا لکھا ہے، کیونکہ Debian اور Ubuntu package اپنی کچھ default settings فراہم کرتے ہیں۔

ہر entry repository کی description file کی پہلی line دکھاتی ہے، اس لیے نئی bare repo اپنے نام کو Unnamed repository; edit this file 'description' to name the repository. کے طور پر دکھاتی ہے۔ ہر 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

اس پر انحصار کرنے سے پہلے دو limits جاننا ضروری ہے۔ cgit read-only ہے اور اس میں login موجود نہیں، اس لیے scan-path کے اندر موجود ہر چیز public ہے۔ private repository کو اس directory سے باہر رکھیں، یا پوری site کے سامنے HTTP basic authentication لگائیں۔ CGI web server user کے طور پر چلتا ہے، اس لیے اس user کو /srv/git سے گزرنے اور ہر repository کو پڑھنے کی اجازت درکار ہے۔ جس directory میں یہ داخل نہیں ہو سکتا، وہ error کے بجائے empty index کے طور پر ظاہر ہوتی ہے۔

درجہ 2: issues اور pull requests کے لیے Forgejo یا Gitea

Forgejo اور Gitea بنیادی طور پر ایک ہی تصور ہیں: ایک Go binary جو users، organisations، issues، pull requests، releases، package registry اور built-in CI system کے ساتھ web forge فراہم کرتی ہے۔ مکمل installation کے لیے binary اور SQLite ہی کافی ہیں، اسی لیے یہ ایسے hardware پر بھی چل جاتے ہیں جسے GitLab استعمال نہیں کر سکتا۔ ذیل کی Compose file Forgejo documentation میں دی گئی file ہے، جس میں August 2026 تک درج image tag استعمال کیا گیا ہے۔

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

`curl line کو HTTP status line دکھانی چاہیے۔ پہلے run کی setup مکمل کرنے سے قبل یہ /install پر redirect بھی ہو سکتی ہے، اور اس کا مطلب پھر بھی یہ ہے کہ service چل رہی ہے۔ اگر container اس کے بجائے exit ہو جائے تو عام وجہ ownership ہوتی ہے: ./forgejo directory کا مالک USER_UID` میں درج UID (user id) ہونا چاہیے، ورنہ process اپنی data directory میں نہیں لکھ سکتا۔ VPS پر Docker Compose میں اس file layout اور volume ownership rule کی مکمل وضاحت ہے۔

Setup page پر موجود دو جوابات طے کرتے ہیں کہ clone URLs کام کریں گے یا نہیں۔ SSH port `222 ہونا چاہیے، کیونکہ Compose file host port 222 کو container کے port 22 سے map کرتی ہے، اور domain وہی ہونا چاہیے جسے users حقیقتاً type کریں گے۔ ان میں سے کوئی ایک بھی غلط ہو تو ہر repository page ایسا clone command فراہم کرے گا جو اسے copy کرنے والے ہر user کے لیے ناکام ہو جائے گا۔ دونوں بعد میں app.ini کے [server] section میں SSH_PORT، SSH_DOMAIN اور ROOT_URL` کے طور پر موجود ہوتے ہیں۔

Public instance کے لیے web port صرف loopback address پر publish کریں (`'127.0.0.1:3000:3000') اور TLS (transport layer security) کے لیے اس کے سامنے nginx رکھیں۔ Gitea اسی طرح gitea/gitea image سے install ہوتا ہے، یا ایک single binary کے طور پر ایک systemd unit اور ایک app.ini` کے ساتھ چلتا ہے، اور August 2026 تک اس کی current stable release 1.27.1 ہے۔

جب تک ممکن ہو SQLite استعمال کرتے رہیں۔ اس سے instance ایک process اور ایک file تک محدود رہتا ہے، اور reboot کے بعد نگرانی کے لیے کسی اضافی service کی ضرورت نہیں ہوتی۔ جب بیک وقت کئی users لکھتے ہوں تو PostgreSQL کی اضافی لاگت قابلِ جواز ہو جاتی ہے، کیونکہ SQLite writes کو serialise کرتا ہے اور طویل CI runs مسلسل لکھتی رہتی ہیں۔ دونوں projects موجودہ instance کو بعد میں PostgreSQL پر منتقل کر سکتے ہیں، اس لیے یہ ایسا فیصلہ نہیں جس میں آپ پھنس جائیں۔

Forgejo یا Gitea: عملی طور پر کیا فرق ہے

دونوں کا ماخذ ایک ہی ہے۔ Gitea نے 2016 میں Gogs سے fork کیا تھا۔ 2022 کے اواخر میں Gitea کے domain اور trademark کا کنٹرول ایک کمپنی، Gitea Ltd، کو منتقل ہو گیا، اور متعدد maintainers نے Codeberg کے ساتھ مل کر Forgejo شروع کیا۔ Forgejo کو Codeberg e.V. شائع کرتا ہے، جو جرمنی میں registered non-profit association ہے، اور 2024 میں یہ MIT licence سے GPLv3 (GNU general public license version 3) پر منتقل ہوا۔ Gitea بدستور MIT licensed ہے اور اسے commercial backing حاصل ہے۔

روزمرہ استعمال میں دونوں کے feature sets کافی ملتے جلتے ہیں۔ لیکن ان کے درمیان منتقلی کا طریقہ مختلف ہے۔ January 2025 کا Forgejo v10.0 آخری release تھا جو Gitea database کو براہ راست import کر سکتا تھا، اور وہ بھی صرف Gitea v1.22 یا اس سے پرانے version سے۔ August 2026 تک Gitea v1.27.1 پر ہے، اس لیے موجودہ Gitea instance کو Forgejo میں منتقل کرنے کے لیے کوئی supported in-place طریقہ نہیں ہے۔ Data شامل کرنے سے پہلے ایک کا انتخاب کریں، اور بعد کی کسی بھی منتقلی کو export اور دوبارہ import سمجھیں۔

انتخاب کے لیے مختصر اصول یہ ہے۔ اگر governance آپ کے لیے اہم ہے، یا آپ چاہتے ہیں کہ project کسی non-profit کے پاس رہے، تو Forgejo چلائیں۔ اگر آپ زیادہ بڑی install base اور commercial support option چاہتے ہیں، تو Gitea چلائیں۔ دونوں open development کے تحت maintained ہیں اور باقاعدگی سے releases جاری کرتے ہیں: Forgejo ہر تین ماہ میں stable release اور ہر سال LTS (long term support) release جاری کرتا ہے۔ August 2026 تک v16.0.2 موجودہ release ہے، جبکہ v15.0.6 LTS release ہے۔

Tier 3: GitLab کچھ کرنے سے پہلے اس کی لاگت

GitLab CE سافٹ ویئر کی ایک مختلف قسم ہے۔ ایک instance باہم تعاون کرنے والی متعدد services پر مشتمل ہوتا ہے: web application کے لیے Puma، background jobs کے لیے Sidekiq، PostgreSQL، Redis، repository access کے لیے Gitaly، اور سامنے nginx۔ Omnibus package یہ سب ایک ساتھ install کرتا ہے، اس لیے installation آسان، لیکن کم از کم memory requirement زیادہ ہو جاتی ہے۔

GitLab کا requirements page ایک single-node installation کے لیے 16 GB RAM اور 8 vCPU کو baseline قرار دیتا ہے۔ Memory-constrained environment میں 8 GB کو کم ترین حد کے طور پر بیان کیا گیا ہے۔ اسی page کے مطابق swap disable کرنی چاہیے، کیونکہ load کے دوران swapping سے instance کی کارکردگی شدید متاثر ہوتی ہے۔ یہ published figures August 2026 تک کی ہیں، اور گزشتہ برسوں میں ان میں اضافہ ہوا ہے۔ اس لیے server کا size طے کرنے سے پہلے page دوبارہ پڑھیں۔

اس budget میں آپ کو حقیقی سہولیات ملتی ہیں: container registry، package registry، fine-grained permissions، compliance اور audit features، اور بڑے scale پر tested CI۔ اگر آپ کی team میں کوئی شخص اس فہرست میں سے اس quarter کے لیے درکار کسی feature کا نام نہیں بتا سکتا، تو آپ کسی فائدے کے بغیر بڑے VPS کی قیمت ادا کر رہے ہیں۔

SSH رسائی کا ماڈل: ایک git صارف اور متعدد keys

یہاں ہر tier میں authentication کا طریقہ ایک ہی ہے۔ ایک Unix account ہے جس کا نام git ہے، اور ہر public key اس account کی ~/.ssh/authorized_keys میں شامل کی جاتی ہے۔ Authentication key کے ذریعے ہوتی ہے۔ Authorisation کا تعین اسی لائن میں key سے پہلے لکھی گئی options کرتی ہیں۔

سادہ key line رکھنے والے کو وہ تمام کام کرنے دیتی ہے جو یہ account کر سکتا ہے۔ Forced command رسائی کو Git تک محدود کر دیتی ہے:

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

restrict، جو OpenSSH 7.2 سے دستیاب ہے، ایک ہی لفظ میں port forwarding، agent forwarding، X11 اور PTY (pseudo terminal) allocation بند کر دیتا ہے۔ command= client کی بھیجی ہوئی درخواست کو آپ کی نامزد کردہ واحد درخواست سے بدل دیتا ہے، اور Git پھر بھی کام کرتا ہے کیونکہ Git اپنی درخواست $SSH_ORIGINAL_COMMAND میں بھیجتا ہے۔

Forge یہ file خود آپ کے لیے لکھتا ہے، اور tier 0 اور tier 2 کے درمیان اصل فرق یہی ہے۔ Forgejo اور Gitea authorized_keys کو دوبارہ لکھتے ہیں۔ اس میں ہر registered key کے لیے ایک لائن ہوتی ہے، اور ہر لائن میں forced command شامل ہوتی ہے جو database id کے ذریعے key کی شناخت کرتی ہے:

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

یہ forced command ہی ایک مشترکہ Unix account کو ہر user کے لیے الگ permission میں تبدیل کرتی ہے: key-3 forge کو بتاتا ہے کہ کون سا user connect کر رہا ہے، اور forge کسی بھی object کے منتقل ہونے سے پہلے اس user کو repository کے ساتھ verify کرتا ہے۔ Forge-managed box پر اس file کو دستی طور پر edit نہ کریں، کیونکہ یہ database سے دوبارہ لکھی جاتی ہے اور آپ کی لائن غائب ہو جاتی ہے۔ Deploy keys بھی اسی mechanism سے آتی ہیں: deploy key ایک عام SSH key ہوتی ہے جو ایک مخصوص repository کے ساتھ registered ہوتی ہے، عموماً read-only، اور اس کی جانچ sshd کے بجائے forge میں ہوتی ہے۔

اوپر دی گئی configuration سے زیادہ اہم دو عادات ہیں۔ ہر شخص یا ہر machine کے لیے ایک key جاری کریں، shared key کبھی استعمال نہ کریں، کیونکہ shared key revoke کرنے کا مطلب سب کے لیے ایک ہی وقت میں اسے rotate کرنا ہوتا ہے۔ اور جس دن کوئی شخص ادارہ چھوڑے، اسی دن اس کی key remove کریں، کیونکہ اس file میں موجود پرانی key ایسا مستقل login ہے جسے کوئی monitor نہیں کر رہا۔ سرور پر اچھی SSH key management میں key types اور passphrases کا احاطہ کیا گیا ہے، اور اس کی تمام باتیں یہاں بھی اسی طرح لاگو ہوتی ہیں۔ اگر box نیا ہے تو repositories رکھنے سے پہلے نئے VPS پر پہلے دس منٹ والا طریقہ اختیار کریں۔

کیا میں اپنے Git server پر GitHub Actions چلا سکتا ہوں؟

آپ GitHub Actions syntax میں لکھے گئے workflows چلا سکتے ہیں۔ آپ GitHub نہیں چلا سکتے۔ Forgejo Actions، Forgejo v1.21 سے default طور پر enabled ہے اور ہر repository میں .forgejo/workflows سے workflow files پڑھتا ہے۔ Gitea Actions بھی اسی طرح کام کرتا ہے اور .gitea/workflows پڑھتا ہے۔ دونوں کے لیے ایک دوسرے program، یعنی runner، کو install کرنا اور admin settings سے حاصل کردہ token کے ذریعے اپنی instance کے ساتھ register کرنا ضروری ہے۔ بہت سی published actions میں تبدیلی کے بغیر چل جاتی ہیں؛ لیکن جو actions GitHub API کو call کرتی ہیں یا GitHub-hosted infrastructure کی توقع رکھتی ہیں، وہ نہیں چلیں گی۔

دو نتائج کے لیے پہلے سے منصوبہ بنائیں۔ runner ہر job کے لیے ایک container شروع کرتا ہے، اس لیے اسے container engine اور اپنی memory budget درکار ہوتی ہے۔ اسی وجہ سے اسے forge کے ساتھ اسی 1 GB سرور پر نہیں چلانا چاہیے۔ runner workflow file میں دی گئی ہر ہدایت execute کرتا ہے۔ Forgejo کی documentation اسے واضح الفاظ میں بیان کرتی ہے: runner remote code execution انجام دیتا ہے۔ جہاں ممکن ہو، اسے اپنے الگ host پر چلائیں۔ کم از کم اسے اپنے الگ unprivileged user اور صرف ایک repository تک محدود registration token کے ساتھ چلائیں۔

اگر آپ کی repositories GitHub پر ہی رہیں گی اور آپ صرف اپنی زیرِ انتظام hardware پر compute چلانا چاہتے ہیں، تو یہ مختلف setup ہے اور اس کے steps بھی مختلف ہیں: ایک self-hosted GitHub Actions runner، GitHub repository کے ساتھ attach ہوتا ہے اور اسے ان میں سے کسی چیز کی ضرورت نہیں ہوتی۔ اگر آپ اب بھی یہ جائزہ لے رہے ہیں کہ GitHub چھوڑنے کی کیا لاگت ہے، تو GitHub حقیقت میں آپ کو کیا فراہم کرتا ہے، Git hosting کو اس کے گرد موجود network سے الگ کر کے دکھاتا ہے۔

Backups: repositories صرف state کا نصف ہیں

Bare repository ایک directory ہوتی ہے، اس لیے اسے copy کرنے سے اس کے اندر موجود ہر چیز copy ہو جاتی ہے۔ کسی دوسری machine سے mirror clone ایک حقیقی backup ہے، اور یہ اسی جگہ refresh ہو جاتا ہے:

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

یہ ہر ref اور ہر object حاصل کرتا ہے۔ یہ server-side hooks یا description file حاصل نہیں کرتا، اس لیے اگر آپ hooks استعمال کرتے ہیں تو directory کی file-level copy بھی محفوظ رکھیں۔

Forge اپنے database میں issues، pull requests، users، keys اور permissions محفوظ رکھتا ہے۔ صرف repositories کی copy بنانے سے یہ سب ضائع ہو جاتا ہے۔ دونوں projects ایک dump command فراہم کرتے ہیں جو database، repositories، configuration اور attachments کو ایک archive میں لکھتی ہے:

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

Docker کے تحت یہی command container کے اندر چلتی ہے، اور configuration path image کے مطابق مختلف ہوتا ہے۔ اس لیے command چلانے سے پہلے path دیکھ لیں:

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

یہ command اس user کے طور پر چلائیں جو data کا مالک ہے، اور archive ایسی directory میں لکھیں جہاں اس user کو write access حاصل ہو۔ اس کے بعد archive کو server سے باہر copy کریں، کیونکہ جو backup صرف اسی machine پر موجود ہو جس کا backup لیا جا رہا ہے، وہ backup نہیں ہوتا۔ Restore وہ مرحلہ ہے جسے لوگ چھوڑ دیتے ہیں۔ ابھی ایک dump کو spare box پر unpack کریں، تاکہ outage کے دوران نہیں بلکہ پرسکون وقت میں طریقہ کار سیکھ سکیں۔

منظرنامے کے مطابق انتخاب

ایک فرد کے پاس laptop اور VPS ہو اور browsing کی ضرورت نہ ہو: SSH کے ذریعے bare repositories استعمال کریں۔ کوئی اضافی service چلانے کی ضرورت نہیں، اور upgrade کرنے کے لیے بھی کچھ نہیں ہے۔

وہی صورت ہو، لیکن code کو browser میں پڑھنے اور اس کے links دوسروں کو بھیجنے کی ضرورت ہو: cgit شامل کریں۔ پھر بھی database کی ضرورت نہیں، اور کوئی مستقل service بھی نہیں چلتی۔

ایسی team جو ایک دوسرے کے code کا review کرتی ہو اور issues track کرتی ہو: 2 GB RAM یا اس سے زیادہ والے server پر Forgejo یا Gitea استعمال کریں۔ جب jobs واقعی چلنے لگیں تو CI runner کو دوسرے box پر منتقل کریں۔

ایسی organisation جسے container registry اور audit trails درکار ہوں، اور server کے لیے 16 GB RAM دستیاب ہو: GitLab استعمال کریں۔ اس سے کم budget میں اسے شروع نہ کریں۔

پہلی تین سطحوں کے درمیان آگے بڑھنا سستا ہے، کیونکہ ان سب میں repositories disk پر عام Git directories ہوتی ہیں۔ سب سے نچلی وہ سطح اختیار کریں جو آپ کی ضرورت پوری کر دے۔ اگر آپ یہ طے کر رہے ہیں کہ اسی server پر کن دوسری services کے لیے جگہ مختص کی جائے، تو self-hosting کے قابل services کی مختصر فہرست Git server کو ان دوسری services کے ساتھ رکھتی ہے جو اسی RAM کے لیے مقابلہ کر رہی ہیں۔

FAQ

کیا 1 GB VPS Forgejo یا Gitea چلا سکتا ہے؟

ہاں، ایک چھوٹی ٹیم کے لیے، SQLite پر، بشرطیکہ اس سرور پر کوئی دوسری بھاری سروس نہ چل رہی ہو۔ Gitea کی documentation کے مطابق چھوٹی ٹیموں اور projects کے لیے عموماً 1 GB RAM اور 2 CPU cores کافی ہوتے ہیں، اور Forgejo بھی اسی ساخت کے ساتھ Gitea کا fork ہے۔ اس machine پر PostgreSQL یا CI runner شامل نہ کریں۔ اگر سروس اپنی log میں کسی error کے بغیر غائب ہو جائے تو sudo dmesg -T | grep -i oom چلائیں: جس line میں ختم کیے گئے process کا نام ہو، اس کا مطلب ہے کہ kernel کے out of memory killer نے اسے ختم کیا ہے۔ اس صورت میں حل tuning flag نہیں بلکہ بڑا plan ہے۔

Forgejo اور Gitea میں کیا فرق ہے؟

ان کی codebase history اور زیادہ تر features مشترک ہیں۔ Gitea، 2016 میں Gogs سے fork ہوا، جبکہ Gitea کے trademark کا control ایک company کو منتقل ہونے کے بعد Forgejo نے 2022 کے آخر میں Gitea سے fork کیا۔ Forgejo کو جرمنی کی non-profit Codeberg e.V. GPLv3 کے تحت publish کرتی ہے؛ Gitea MIT license کے تحت برقرار ہے اور اسے commercial backing حاصل ہے۔ عملی فرق migration path کا ہے۔ January 2025 کا Forgejo v10.0 آخری release تھا جو Gitea database کو براہِ راست استعمال کر سکتا تھا، اور یہ صرف Gitea v1.22 یا اس سے پرانے version سے ممکن تھا۔ اس لیے موجودہ Gitea instance کو in-place تبدیل کرنے کا کوئی supported طریقہ نہیں ہے۔

کیا میں self-hosted Git server پر GitHub Actions workflows چلا سکتا ہوں؟

Forgejo Actions اور Gitea Actions دونوں GitHub Actions YAML syntax میں لکھے گئے workflows چلاتے ہیں۔ یہ workflows .forgejo/workflows اور .gitea/workflows سے پڑھے جاتے ہیں۔ آپ کو الگ runner program install کرکے اسے اپنے instance کے ساتھ register کرنا ہوگا۔ بہت سے published actions بغیر تبدیلی کے کام کرتے ہیں، لیکن جو بھی GitHub API کو call کرے گا وہ کام نہیں کرے گا۔ Runner آپ کی repositories سے arbitrary code چلاتا ہے اور ہر job کے لیے ایک container شروع کرتا ہے۔ اس لیے اسے الگ host دیں، یا کم از کم الگ unprivileged user کے تحت چلائیں، اور اسے ایسے 1 GB server پر نہ چلائیں جہاں forge پہلے سے running ہو۔

self-hosted Git server کا backup کیسے بناؤں؟

Bare repositories کے لیے، کسی دوسری machine سے git clone --mirror چلانے پر ہر ref اور object copy ہو جاتا ہے، اور اس mirror کے اندر git remote update اسے refresh کرتا ہے۔ Forgejo یا Gitea میں repositories صرف state کا ایک حصہ ہوتی ہیں، کیونکہ issues، pull requests، users اور keys database میں محفوظ ہوتے ہیں۔ Built-in dump، sudo -u git forgejo dump -c /etc/forgejo/app.ini استعمال کریں، یا Docker installation میں یہی command container کے اندر چلائیں۔ Archive کو server سے باہر copy کریں، اور ایک بار اسے spare machine پر restore کریں تاکہ آپ کو یقین ہو جائے کہ طریقہ کار درست ہے۔