Self-hosted Git server साठी Forgejo, Gitea की cgit?

कोणता self-hosted Git server चालवावा

self-hosted Git server हे एकच उत्पादन नाही. तुमच्या VPS मधील RAM (random access memory) मुळे त्याची कोणती आवृत्ती चालवता येईल हे ठरते. Git ला स्वतःचा daemon आवश्यक नसतो. तुम्ही भाड्याने घेऊ शकता अशा सर्वात लहान server वर bare repository आणि SSH (secure shell) account एवढेच कार्यरत server साठी पुरेसे असतात. यापेक्षा पुढील प्रत्येक पर्याय म्हणजे त्या server सोबत चालवायचे web application आहे. प्रत्येक पुढील पायरीसाठी लागणारी memory लहान VPS कडे कदाचित उपलब्ध नसेल.

याचे चार स्तर आहेत. SSH द्वारे bare repository, ज्यासाठी आधीपासून listening नसलेली कोणतीही नवीन सेवा listening ठेवावी लागत नाही. cgit हे database शिवायचे, जलद read-only web view आहे. Forgejo किंवा Gitea हे accounts, issues आणि pull requests असलेले पूर्ण forge आहेत; त्यांना काही hundred megabytes memory लागते. GitLab ला इतर पर्यायांपेक्षा अनेक पटींनी मोठ्या server ची अपेक्षा असते.

तुम्हाला करायच्या कामानुसार निर्णय घ्या. त्यानंतर तुम्ही ज्या plan साठी पैसे देत आहात, त्यातील memory figure शी त्याची तुलना करा.

प्रत्येक पर्यायासाठी प्रत्यक्षात किती RAM आवश्यक आहे

या प्रकल्पांपैकी फक्त दोन प्रकल्प hardware requirement प्रकाशित करतात. प्रकाशित केलेला आकडा किमान मर्यादा समजा, हमी नव्हे. तुमची instance सुरू झाल्यानंतर systemd-cgtop किंवा ps -o rss= -C forgejo वापरून स्वतःच्या instance चे मोजमाप करा.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

लहान teams आणि projects साठी 2 CPU cores सह 1 GB RAM साधारणपणे पुरेशी असते, असे Gitea च्या documentation मध्ये नमूद केले आहे. लहान workloads साठी Raspberry Pi 3 पुरेसा असल्याचेही त्यात सांगितले आहे. एका single-node installation साठी 16 GB ही baseline आणि memory-constrained environment साठी 8 GB ही किमान पातळी असल्याचे GitLab च्या documentation मध्ये नमूद केले आहे. Forgejo कोणतीही hardware requirement प्रकाशित करत नाही. ते Gitea चे fork आहे आणि त्याचप्रमाणे कार्य करते. त्यामुळे उपलब्ध published guide म्हणून Gitea चा आकडा सर्वात जवळचा आहे.

1 GB VPS वर याचा अर्थ असा होतो: bare repositories आणि cgit साठी पुरेशी RAM उरते, कारण यापैकी कोणतीही सेवा resident service म्हणून चालत नाही. Forgejo किंवा Gitea सुरू होईल आणि SQLite वर लहान team ला सेवा देईल. मात्र तुम्ही 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 ने ती process बंद केली आहे. 1 GB box वर GitLab चालवणे ही tuning ची समस्या नाही. ते चालणार नाही.

Tier 0: SSH द्वारे bare repository

Git मध्ये सुरू करावा लागणारा कोणताही network daemon नाही. git push SSH द्वारे दूरच्या बाजूला सामान्य Unix process म्हणून git-receive-pack चालवतो. त्यामुळे key द्वारे ज्या account पर्यंत पोहोचता येते, तो account आधीपासूनच Git remote असतो. Repositories साठी एक account तयार करा. Repositories त्या account च्या home directory च्या बाहेर ठेवा, कारण Ubuntu 24.04 मध्ये नवीन home directory चा mode 0750 असतो आणि नंतर जोडलेला web view त्यामध्ये प्रवेश करू शकत नाही.

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 working copy नसलेले repository तयार करतो. Server वर ठेवण्यासाठी हेच अपेक्षित असते. Working copy असलेल्या repository मध्ये push करणे refusing to update checked out branch: refs/heads/main मुळे नाकारले जाते. या tier मधील ही सर्वात सामान्य चूक आहे.

आता 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

यशस्वी झालेल्या पहिल्या push चा शेवट * [new branch] main -> main ने होतो. git@vps.example.com: Permission denied (publickey) ने शेवट झालेला push authenticate झालेलाच नसतो. त्यामुळे server log sudo journalctl -u ssh -n 20 ने वाचा. Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys अशी ओळ दिसल्यास file mode चुकीचा आहे. इतर users लिहू शकतील अशी key file असल्यास sshd ती दुर्लक्षित करतो.

यानंतर account कडून shell काढून टाका.

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

git-shell Git SSH द्वारे पाठवणाऱ्या मोजक्याच commands स्वीकारतो. त्यामुळे 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 नाहीत आणि प्रत्येक user साठी स्वतंत्र permission नाही. त्या file मधील प्रत्येक key ला git user च्या मालकीच्या प्रत्येक repository वर read आणि write access असतो.

टियर 1: cgit डेटाबेसशिवाय वेब दृश्य देते

cgit हा C मध्ये लिहिलेला CGI (common gateway interface) प्रोग्राम आहे. वेब सर्व्हर प्रत्येक विनंतीसाठी तो एकदा चालवतो. तो repositories थेट डिस्कवरून वाचतो आणि स्वतःची कोणतीही स्थिती साठवत नाही. 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 मधून पुढे जातो आणि त्याला सापडणाऱ्या प्रत्येक repository ची सूची तयार करतो. त्यामुळे नवीन bare repo साठी अतिरिक्त configuration आवश्यक नसते. cache-size ही cached pages ची संख्या आहे. ती zero असताना caching बंद राहते. नवीन lines जोडण्यापूर्वी package ने /etc/cgitrc मध्ये आधीच ठेवलेले configuration वाचा, कारण Debian आणि Ubuntu package स्वतःचे काही defaults देते.

प्रत्येक 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

यावर आधारित पुढील configuration करण्यापूर्वी दोन मर्यादा माहिती असणे आवश्यक आहे. cgit read-only आहे आणि त्यामध्ये login सुविधा नाही. त्यामुळे scan-path अंतर्गत सर्व काही public आहे. Private repository त्या directory च्या बाहेर ठेवा किंवा संपूर्ण site समोर HTTP basic authentication लावा. तसेच CGI web server user म्हणून चालतो. त्यामुळे त्या user ला /srv/git मधून traverse करण्याची आणि प्रत्येक repository वाचण्याची परवानगी आवश्यक आहे. ज्या directory मध्ये तो प्रवेश करू शकत नाही, ती error ऐवजी empty index म्हणून दिसते.

स्तर 2: issues आणि pull requests साठी Forgejo किंवा Gitea

Forgejo आणि Gitea ही एकाच संकल्पनेची अंमलबजावणी आहेत: users, organisations, issues, pull requests, releases, package registry आणि अंगभूत CI system देणारी एक Go binary. Binary आणि SQLite एवढेच संपूर्ण installation असल्यामुळे GitLab ज्या hardware वर चालणार नाही, त्यावरही हे बसतात. खालील Compose file Forgejo documentation मधील आहे. त्यात 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 दाखवली पाहिजे. First-run setup पूर्ण करण्यापूर्वी ती /install कडे redirect असू शकते. तरीही service सुरू आहे, असा त्याचा अर्थ होतो. त्याऐवजी container बंद होत असेल, तर नेहमीचे कारण 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 वरून copy केलेली clone command वापरणाऱ्या प्रत्येक व्यक्तीसाठी fail होईल. नंतर ही दोन्ही माहिती [server] section मध्ये app.ini अंतर्गत 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 इतक्यापुरता राहतो. देखरेख करण्यासाठी अतिरिक्त service नसल्याने reboot नंतरही तो सुरू राहतो. एकाच वेळी अनेक users लिहित असतील, तेव्हा PostgreSQL चा अतिरिक्त खर्च योग्य ठरतो. SQLite writes चे serialisation करते आणि दीर्घ CI runs सतत write करतात. दोन्ही projects विद्यमान instance नंतर PostgreSQL वर हलवण्याची सुविधा देतात. त्यामुळे हा बदलता न येणारा निर्णय नाही.

Forgejo आणि Gitea: प्रत्यक्षात काय वेगळे आहे

दोन्हींचा उगम समान आहे. Gitea ने 2016 मध्ये Gogs पासून fork केले. 2022 च्या उत्तरार्धात Gitea domain आणि trademark वरील नियंत्रण Gitea Ltd या कंपनीकडे गेले. त्यानंतर Codeberg सोबत काही maintainers ने Forgejo सुरू केले. Forgejo चे प्रकाशन Codeberg e.V. करते. ही जर्मनीमध्ये नोंदणीकृत non-profit association आहे. 2024 मध्ये Forgejo MIT licence वरून GPLv3 (GNU general public license version 3) वर गेले. Gitea अजूनही MIT licensed आहे आणि त्याचा विकास व्यावसायिक पाठबळासह केला जातो.

दैनंदिन वापरात दोन्हींचे feature sets जवळपास सारखे आहेत. मात्र त्यांच्यामधील स्थलांतराचा मार्ग वेगळा आहे. जानेवारी 2025 मधील Forgejo v10.0 ही Gitea database थेट वापरू शकणारी शेवटची release होती. ती देखील फक्त Gitea v1.22 किंवा त्यापेक्षा जुन्या आवृत्तीवरून स्थलांतर करू शकत होती. ऑगस्ट 2026 पर्यंत Gitea 1.27.1 वर आहे. त्यामुळे सध्याच्या Gitea instance साठी Forgejo कडे समर्थित in-place switch उपलब्ध नाही. डेटा भरायच्या आधी एक निवडा. त्यानंतरचे कोणतेही स्थलांतर export आणि re-import म्हणून करा.

निवडीसाठी साधा नियम असा आहे. Governance तुमच्यासाठी महत्त्वाचे असेल किंवा प्रकल्प non-profit संस्थेकडेच राहावा असे वाटत असेल, तर Forgejo चालवा. मोठा install base आणि commercial support option हवे असेल, तर Gitea चालवा. दोन्ही प्रकल्प open पद्धतीने maintained आहेत आणि वारंवार release होतात. Forgejo दर तीन महिन्यांनी stable release आणि दरवर्षी LTS (long term support) release प्रकाशित करते. ऑगस्ट 2026 पर्यंत v16.0.2 current आहे आणि v15.0.6 ही LTS आवृत्ती आहे.

टियर 3: GitLab काहीही करण्यापूर्वी लागणारा खर्च

GitLab CE हे वेगळ्या श्रेणीतील सॉफ्टवेअर आहे. एका instance मध्ये परस्पर सहकार्य करणाऱ्या अनेक सेवा असतात: web application साठी Puma, background jobs साठी Sidekiq, PostgreSQL, Redis, repository access साठी Gitaly आणि समोर nginx. Omnibus package या सर्व सेवा एकत्र install करते. त्यामुळे install सोपे होते, पण किमान memory आवश्यकता जास्त राहते.

GitLab च्या requirements page वर single-node installation साठी 16 GB RAM आणि 8 vCPU हे baseline म्हणून दिले आहेत. Memory-constrained environment साठी 8 GB ही किमान पातळी म्हणून नमूद केली आहे. त्याच page वर swap disable करण्यास सांगितले आहे, कारण load असताना swapping मुळे instance ची कार्यक्षमता मोठ्या प्रमाणात खालावते. ही प्रकाशित आकडेवारी August 2026 पर्यंतची आहे. गेल्या काही वर्षांत ती वाढली आहे. त्यामुळे server चे sizing करण्यापूर्वी ती page पुन्हा वाचा.

या budget मध्ये तुम्हाला प्रत्यक्ष उपयुक्त सुविधा मिळतात: container registry, package registry, सूक्ष्म पातळीवरील permissions, compliance आणि audit features, तसेच मोठ्या प्रमाणावर चाचणी केलेली CI. या यादीतील चालू quarter मध्ये आवश्यक असलेली एकही सुविधा तुमच्या team मधील कोणी सांगू शकत नसेल, तर तुम्ही कोणताही प्रत्यक्ष लाभ न घेता मोठ्या VPS साठी पैसे देत आहात.

SSH प्रवेशाची रचना: एक git वापरकर्ता आणि अनेक keys

येथील प्रत्येक tier मध्ये authentication ची पद्धत समान आहे. git नावाचे एक Unix account आहे आणि प्रत्येक public key त्या account च्या ~/.ssh/authorized_keys मध्ये ठेवली जाते. Authentication साठी key वापरली जाते. Authorisation म्हणजे त्याच ओळीवर key च्या आधी लिहिलेले options.

साधी key line त्या account ला करता येणारी सर्व कामे key धारकाला देते. Forced command वापरल्यास ती Git पुरती मर्यादित करता येते:

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

OpenSSH 7.2 पासून उपलब्ध असलेले restrict port forwarding, agent forwarding, X11 आणि PTY (pseudo terminal) allocation एका शब्दाने बंद करते. command= client ने मागितलेल्या command ऐवजी तुम्ही निर्दिष्ट केलेली command वापरते. Git योग्यरीत्या चालते, कारण Git आपली request $SSH_ORIGINAL_COMMAND मध्ये पाठवते.

Forge ही file तुमच्यासाठी लिहिते. tier 0 आणि tier 2 मधील हा मुख्य फरक आहे. Forgejo आणि Gitea authorized_keys मध्ये प्रत्येक registered key साठी एक line लिहितात. प्रत्येक line मध्ये database id द्वारे key ओळखणारी forced command असते:

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

सामायिक Unix account साठी per-user permission लागू करण्याचे साधन ही forced command आहे: key-3 कोणता user connect होत आहे हे forge ला सांगते आणि कोणतेही objects हलवण्यापूर्वी forge त्या user ची repository विरुद्ध पडताळणी करते. Forge-managed box वर ही file manually edit करू नका. ती database मधून पुन्हा लिहिली जाते आणि तुमची line नाहीशी होते. Deploy keys याच mechanism मधून येतात. Deploy key ही एका repository शी registered केलेली सामान्य SSH key असते. ती सहसा read-only असते आणि तपासणी sshd ऐवजी forge मध्ये केली जाते.

वरील कोणत्याही configuration पेक्षा दोन सवयी अधिक महत्त्वाच्या आहेत. प्रत्येक व्यक्ती किंवा प्रत्येक machine साठी एक key जारी करा; shared key कधीही वापरू नका. Shared key revoke केल्यास ती सर्वांसाठी एकाच वेळी rotate करावी लागते. एखादी व्यक्ती संस्था सोडते त्याच दिवशी तिच्या keys काढून टाका. त्या file मधील जुनी key म्हणजे कोणीही monitor करत नसलेला कायमस्वरूपी login असतो. Server वर SSH key चे चांगले व्यवस्थापन या लेखात key types आणि passphrases समजावले आहेत; ते सर्व येथेही अपरिवर्तितपणे लागू होते. Box नवीन असल्यास repositories ठेवण्यापूर्वी नवीन VPS वरील पहिले दहा मिनिटे हा योग्य पुढचा टप्पा आहे.

मी माझ्या स्वतःच्या Git सर्व्हरवर GitHub Actions चालवू शकतो का?

तुम्ही GitHub Actions syntax मध्ये लिहिलेले workflows चालवू शकता. मात्र GitHub चालवता येत नाही. Forgejo Actions हे Forgejo v1.21 पासून default ने enabled आहे आणि प्रत्येक repository मधील .forgejo/workflows येथून workflow files वाचते. Gitea Actions याच प्रकारे काम करते आणि .gitea/workflows येथून वाचते. दोन्हींसाठी दुसरा प्रोग्राम, म्हणजे runner, install करावा लागतो आणि admin settings मधील token वापरून तो तुमच्या instance विरुद्ध register करावा लागतो. प्रकाशित केलेल्या अनेक actions मध्ये कोणताही बदल न करता त्या चालतात; मात्र GitHub API ला call करणाऱ्या किंवा GitHub-hosted infrastructure ची अपेक्षा ठेवणाऱ्या actions चालत नाहीत.

दोन परिणामांचा विचार करा. प्रत्येक job साठी runner एक container सुरू करतो. त्यामुळे runner साठी container engine आणि स्वतंत्र memory budget आवश्यक असते. म्हणून तो forge असलेल्या त्याच 1 GB मशीनवर ठेवू नका. Workflow file मध्ये जे निर्देश असतात ते runner execute करतो. Forgejo च्या documentation मध्ये हे स्पष्टपणे नमूद केले आहे: runner remote code execution करतो. शक्य असल्यास runner साठी स्वतंत्र host द्या. किमान त्याच्यासाठी स्वतंत्र unprivileged user वापरा आणि एका repository पुरता मर्यादित registration token द्या.

तुमच्या repositories GitHub वरच ठेवायच्या असतील आणि फक्त compute तुम्ही नियंत्रित करत असलेल्या hardware वर चालवायचा असेल, तर ती वेगळी रचना आहे आणि तिच्या पायऱ्याही वेगळ्या आहेत: self-hosted GitHub Actions runner हा GitHub repository शी जोडला जातो आणि यापैकी कोणत्याही गोष्टीची आवश्यकता नसते. GitHub सोडल्यास काय गमवावे लागेल याचा तुम्ही अजून विचार करत असाल, तर GitHub प्रत्यक्षात काय देते हे Git hosting आणि त्याभोवतालच्या network मधील फरक स्पष्ट करते.

बॅकअप: repositories ही एकूण स्थितीचा केवळ अर्धा भाग आहेत

Bare repository ही एक directory असते. त्यामुळे तिची copy केल्यास त्यातील सर्वकाही copy होते. दुसऱ्या machine वरून केलेला mirror clone हा वास्तविक backup असतो आणि तो त्याच ठिकाणी अद्ययावत होतो:

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 issues, pull requests, users, keys आणि permissions ही माहिती database मध्ये ठेवतो. त्यामुळे केवळ repositories ची copy ठेवल्यास ही सर्व माहिती नष्ट होते. दोन्ही projects database, repositories, configuration आणि attachments एकाच archive मध्ये लिहिण्यासाठी dump command देतात:

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

Docker अंतर्गत हीच command container मध्ये चालवली जाते. Configuration path image नुसार बदलतो. त्यामुळे command टाइप करण्यापूर्वी तो तपासा:

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

Data चा मालक असलेल्या user म्हणून ही command चालवा. Archive अशा directory मध्ये लिहा जिथे त्या user ला write permission आहे. त्यानंतर archive server बाहेर copy करा. कारण ज्या machine चा backup घेतला जात आहे त्याच machine वर असलेला backup हा backup मानला जात नाही. Restore करणे ही पायरी अनेक जण टाळतात. आत्ताच एखादा dump spare box वर unpack करा. त्यामुळे outage दरम्यान नव्हे, तर शांतपणे प्रक्रिया शिकता येईल.

परिस्थितीनुसार निवड

लॅपटॉप आणि VPS असलेली एक व्यक्ती, ज्याला ब्राउझिंगची गरज नाही: SSH द्वारे bare repositories. कोणतीही अतिरिक्त सेवा चालू राहत नाही आणि upgrade करण्यासारखे काही नसते.

तीच परिस्थिती, पण code ब्राउझरमध्ये वाचायचा आणि त्याच्या links पाठवायचे असतील: cgit जोडा. तरीही database लागत नाही आणि कोणतीही सेवा सतत चालू राहत नाही.

एकमेकांच्या code चे review करणारा आणि issues track करणारा संघ: 2 GB किंवा अधिक RAM असलेल्या सर्व्हरवर Forgejo किंवा Gitea. Jobs प्रत्यक्ष वापरात आल्यानंतर CI runner दुसऱ्या box वर हलवा.

Container registry आणि audit trails आवश्यक असलेली संस्था, आणि सर्व्हरसाठी 16 GB RAM उपलब्ध असल्यास: GitLab. यापेक्षा कमी budget असल्यास ते सुरू करू नका.

पहिल्या तीन स्तरांमध्ये वरच्या स्तरावर जाणे स्वस्त असते, कारण या सर्व स्तरांमध्ये repositories disk वरील सामान्य Git directories असतात. काम पूर्ण करणारा सर्वात खालचा स्तर निवडा. त्याच सर्व्हरवर आणखी कोणत्या सेवांना जागा द्यायची हे ठरवत असल्यास, self-hosting करण्यास योग्य सेवांची shortlist त्या RAM साठी स्पर्धा करणाऱ्या इतर सेवांच्या शेजारी Git server चे स्थान स्पष्ट करते.

FAQ

1 GB VPS वर Forgejo किंवा Gitea चालवता येईल का?

होय. लहान टीमसाठी, SQLite वापरून आणि त्या सर्व्हरवर इतर कोणतेही जड workload नसल्यास ते चालू शकते. Gitea च्या documentation नुसार लहान टीम आणि प्रोजेक्टसाठी 1 GB RAM आणि 2 CPU cores सामान्यतः पुरेसे असतात. Forgejo हा Gitea चा fork असल्यामुळे त्याची गरजही साधारण तशीच आहे. त्या मशीनवर PostgreSQL किंवा CI runner जोडू नका. सेवेच्या स्वतःच्या log मध्ये कोणतीही त्रुटी नसताना ती अदृश्य होत असेल, तर sudo dmesg -T | grep -i oom चालवा. Killed process चे नाव असलेली ओळ दिसल्यास kernel out of memory killer ने तो process बंद केला आहे. अशा वेळी tuning flag वापरण्याऐवजी मोठा plan घ्या.

Forgejo आणि Gitea मध्ये काय फरक आहे?

त्यांचा codebase history समान आहे आणि बहुतेक features देखील समान आहेत. Gitea ने 2016 मध्ये Gogs पासून fork घेतला. Gitea च्या trademark वरील नियंत्रण एका कंपनीकडे गेल्यानंतर, 2022 च्या उत्तरार्धात Forgejo ने Gitea पासून fork घेतला. Forgejo जर्मनीतील non-profit संस्था Codeberg e.V. प्रकाशित करते आणि ते GPLv3 अंतर्गत उपलब्ध आहे. Gitea MIT license अंतर्गतच राहते आणि त्याला commercial backing आहे. प्रत्यक्ष वापरातील मुख्य फरक migration path मध्ये आहे. जानेवारी 2025 मधील Forgejo v10.0 ही अशी शेवटची release होती जी Gitea database थेट स्वीकारू शकत होती. त्यासाठी Gitea v1.22 किंवा त्याहून जुनी आवृत्ती आवश्यक होती. त्यामुळे सध्याच्या Gitea instance मध्ये supported in-place switch उपलब्ध नाही.

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 करावा लागतो. प्रकाशित केलेल्या अनेक actions मध्ये कोणताही बदल आवश्यक नसतो. मात्र GitHub API ला call करणारे actions चालत नाहीत. Runner तुमच्या repositories मधील arbitrary code चालवतो आणि प्रत्येक job साठी एक container सुरू करतो. त्यामुळे त्यासाठी स्वतंत्र host वापरा किंवा किमान स्वतंत्र unprivileged user वापरा. आधीच forge चालू असलेल्या 1 GB server वर तो runner ठेवू नका.

Self-hosted Git server चा backup कसा घ्यावा?

Bare repositories साठी, दुसऱ्या मशीनवरून 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 install असल्यास container मध्ये हाच command चालवा. Archive server बाहेर copy करा. प्रक्रिया कार्यरत आहे याची खात्री करण्यासाठी एकदा तो archive spare machine वर restore करा.