Self-hosted Git server: Forgejo, Gitea না cgit?
RAM অনুযায়ী bare repository, cgit, Forgejo, Gitea ও GitLab তুলনা করুন। 1 GB VPS-এ কোনটি চলবে এবং কোন বিকল্পে কত memory লাগবে, তা জানুন।
কোন self-hosted Git server চালাবেন
Self-hosted Git server কোনো একক product নয়। আপনার VPS-এর RAM (random access memory) নির্ধারণ করে আপনি এর কোন সংস্করণ চালাতে পারবেন। Git-এর নিজস্ব daemon প্রয়োজন হয় না। সবচেয়ে ছোট ভাড়ার server-এও একটি bare repository এবং একটি SSH (secure shell) account থাকলেই কার্যকর server পাওয়া যায়। এর পরের প্রতিটি ধাপ হলো সেই server-এর পাশে চালানোর জন্য বেছে নেওয়া একটি web application। প্রতিটি ধাপে এমন পরিমাণ memory প্রয়োজন হতে পারে, যা ছোট VPS-এ নাও থাকতে পারে।
এখানে চারটি ধাপ আছে। SSH-এর মাধ্যমে bare repository, যেখানে আগে থেকেই listening না থাকা কোনো অতিরিক্ত service listening করে না। cgit হলো database ছাড়া দ্রুত read-only web view। Forgejo বা Gitea হলো account, issue এবং pull request-সহ পূর্ণাঙ্গ forge, যা কয়েকশো megabyte memory-তে চলে। GitLab-এর জন্য অন্যগুলোর তুলনায় বহু গুণ বড় server প্রয়োজন।
আপনার প্রয়োজনীয় কাজের ভিত্তিতে সিদ্ধান্ত নিন। এরপর আপনি যে plan-এর জন্য অর্থ দিচ্ছেন, তার memory সীমার সঙ্গে প্রয়োজনীয় memory মিলিয়ে দেখুন।
প্রতিটি বিকল্পের বাস্তবে কত RAM প্রয়োজন
এই প্রকল্পগুলোর মধ্যে মাত্র দুটি হার্ডওয়্যার-সংক্রান্ত পরিমাণ প্রকাশ করে। প্রকাশিত পরিমাণকে নিশ্চিত প্রয়োজনীয়তা নয়, বরং সর্বনিম্ন সীমা হিসেবে ধরুন। আপনার instance চালু হওয়ার পর systemd-cgtop বা ps -o rss= -C forgejo ব্যবহার করে নিজেই পরিমাপ করুন।
The data behind this chart
[
{
"label": "Gitea, small team",
"ram_gb": 1
},
{
"label": "GitLab, memory constrained",
"ram_gb": 8
},
{
"label": "GitLab, single node baseline",
"ram_gb": 16
}
]Gitea-এর নথিতে বলা হয়েছে, ছোট দল ও প্রকল্পের জন্য 2টি CPU core সহ 1 GB RAM সাধারণত যথেষ্ট। সেখানে ছোট workload-এর জন্য Raspberry Pi 3-কেও যথেষ্ট বলা হয়েছে। GitLab একক-node installation-এর baseline হিসেবে 16 GB এবং তাদের নিজস্ব পৃষ্ঠায় memory constrained environment হিসেবে বর্ণিত অবস্থার সর্বনিম্ন সীমা হিসেবে 8 GB উল্লেখ করে। Forgejo কোনো হার্ডওয়্যার প্রয়োজনীয়তা প্রকাশ করে না। এটি Gitea-এর fork এবং একই ধরনের আচরণ করে। তাই আপনার হাতে থাকা সবচেয়ে কাছের প্রকাশিত নির্দেশনা হলো Gitea-এর পরিমাণ।
1 GB VPS-এ এর অর্থ হলো: bare repository এবং cgit-এর জন্য পর্যাপ্ত অতিরিক্ত RAM থাকে, কারণ কোনোটিই resident service চালায় না। Forgejo বা Gitea চালু হবে এবং SQLite ব্যবহার করে ছোট দলের অনুরোধ পরিচালনা করতে পারবে। তবে আপনি প্রকাশিত সর্বনিম্ন সীমাতেই থাকবেন। তাই PostgreSQL এবং CI (continuous integration) runner-কে ওই সার্ভারে চালু রাখবেন না। কোনো error ছাড়াই web interface অদৃশ্য হয়ে গেলে sudo dmesg -T | grep -i oom চালান এবং Out of memory: Killed process 1181 (forgejo)-এর মতো কোনো লাইন খুঁজুন। এর অর্থ kernel-এর out of memory killer প্রক্রিয়াটিকে বন্ধ করেছে। 1 GB সার্ভারে GitLab চালানো tuning-এর সমস্যা নয়। এটি চলবে না।
স্তর 0: SSH-এর মাধ্যমে bare repository
Git-এর জন্য কোনো network daemon চালু করার প্রয়োজন নেই। git push SSH-এর মাধ্যমে দূরবর্তী প্রান্তে git-receive-pack-কে একটি সাধারণ Unix process হিসেবে চালায়। তাই যে key দিয়ে আপনি কোনো account-এ সংযোগ করতে পারেন, সেটিই ইতিমধ্যে একটি Git remote। Repository-গুলোর জন্য একটি account তৈরি করুন। Repository-গুলো সেই 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-এ repository রাখার জন্য এটিই প্রয়োজন। Working copy থাকা repository-তে push করলে refusing to update checked out branch: refs/heads/main দিয়ে তা প্রত্যাখ্যান করা হয়। এই স্তরে এটিই সবচেয়ে সাধারণ ভুল।
এখন account-টির জন্য একটি key দিন এবং repository 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_keysgit 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) দিয়ে শেষ হলে authentication সম্পন্ন হয়নি। তাই sudo journalctl -u ssh -n 20 ব্যবহার করে server log পড়ুন। Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys লেখা কোনো line-এর অর্থ হলো file mode সঠিক নয়। কারণ অন্য user-রা লিখতে পারে এমন key file sshd গ্রহণ করে না।
এরপর account-টির shell access সরিয়ে দিন।
command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" gitgit-shell Git SSH-এর মাধ্যমে পাঠানো অল্প কয়েকটি command-ই গ্রহণ করে। তাই 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 request নেই এবং per-user permission নেই। ওই file-এর প্রতিটি key git user-এর মালিকানাধীন সব repository পড়তে ও লিখতে পারে।
স্তর 1: cgit কোনো database ছাড়াই web view দেয়
cgit হলো C ভাষায় লেখা একটি CGI (common gateway interface) program। প্রতিটি request-এর জন্য web server এটি একবার চালায়, এটি সরাসরি disk থেকে repository পড়ে, এবং নিজস্ব কোনো 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/gitscan-path ওই directory scan করে এবং সেখানে পাওয়া প্রতিটি repository তালিকাভুক্ত করে। তাই অতিরিক্ত configuration ছাড়াই নতুন bare repo তালিকায় দেখা যায়। cache-size হলো cached page-এর সংখ্যা। এটি zero হলে caching বন্ধ থাকে। নতুন line যোগ করার আগে আপনার package ইতিমধ্যে /etc/cgitrc-এ কী লিখেছে তা পড়ুন, কারণ Debian এবং Ubuntu package নিজস্ব কিছু default দেয়।
প্রতিটি 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/descriptionnginx site file এবং এটি যাচাই করার পদ্ধতি
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 Listenroot /usr/share/cgit, cgit.css এবং cgit.png-কে plain file হিসেবে serve করে। অন্য সব request try_files, /usr/lib/cgit/cgit.cgi-এ থাকা CGI-তে পাঠায়। /var/log/nginx/error.log-এ connect() to unix:/run/fcgiwrap.socket failed (2: No such file or directory)-সহ 502 page দেখা গেলে socket unit চালু নেই, অথবা এটি অন্য path-এ listen করছে। systemctl show line-টি বাস্তবে ব্যবহৃত path দেখায়।
এটির ওপর ভিত্তি করে configuration তৈরির আগে দুটি সীমাবদ্ধতা জানা দরকার। cgit read-only এবং এতে login ব্যবস্থা নেই। তাই scan-path-এর অধীনে থাকা সবকিছু public। private repository এই directory-এর বাইরে রাখুন, অথবা পুরো site-এর সামনে HTTP basic authentication যুক্ত করুন। CGI web server user হিসেবে চলে। তাই ওই user-এর /srv/git traverse করা এবং প্রতিটি repository পড়ার permission প্রয়োজন। যে directory-তে user ঢুকতে পারে না, সেটি error-এর বদলে empty index হিসেবে দেখা যায়।
স্তর 2: issue এবং pull request-এর জন্য Forgejo বা Gitea
Forgejo এবং Gitea একই ধরনের সমাধান: একটি Go binary, যা users, organisations, issues, pull requests, releases, package registry এবং built-in CI system-সহ একটি web forge চালায়। Binary এবং SQLite-ই সম্পূর্ণ installation, তাই এগুলো এমন 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 -1curl line-টি একটি HTTP status line দেখাবে। প্রথমবারের 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 URL কাজ করবে কি না তা নির্ধারণ করে। SSH port অবশ্যই 222 হতে হবে, কারণ Compose file host port 222-কে container-এর port 22-এ map করে। Domain-ও এমন নাম হতে হবে, যা users বাস্তবে টাইপ করবে। যেকোনো একটি ভুল হলে প্রতিটি repository page-এ এমন clone command দেওয়া হবে, যা কপি করা সবার জন্য ব্যর্থ হবে। পরে দুটিই [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 করা যায়, অথবা একটি systemd unit এবং একটি app.ini-সহ single binary হিসেবে চালানো যায়। August 2026 অনুযায়ী এর বর্তমান stable release হলো 1.27.1।
সম্ভব হলে SQLite ব্যবহার করে চলুন। এতে instance একটি process এবং একটি file-এই সীমাবদ্ধ থাকে, এবং supervise করার জন্য অতিরিক্ত service ছাড়াই reboot-এর পরেও এটি সচল থাকে। একই সময়ে একাধিক ব্যক্তি লিখলে PostgreSQL-এর অতিরিক্ত খরচ যুক্তিসঙ্গত হয়, কারণ SQLite write serialise করে এবং দীর্ঘ CI run ক্রমাগত write করে। উভয় project-ই পরে বিদ্যমান instance PostgreSQL-এ স্থানান্তর করতে পারে, তাই এটি এমন সিদ্ধান্ত নয় যেটিতে আপনি স্থায়ীভাবে আটকে থাকবেন।
Forgejo এবং Gitea: প্রকৃত পার্থক্য কী
দুই প্রকল্পের উৎস একই। Gitea 2016 সালে Gogs থেকে fork হয়। 2022 সালের শেষদিকে Gitea domain ও trademark-এর নিয়ন্ত্রণ Gitea Ltd নামের একটি কোম্পানির হাতে যায়। এরপর কয়েকজন maintainer এবং Codeberg মিলে Forgejo শুরু করে। Forgejo Codeberg e.V. প্রকাশ করে। এটি জার্মানিতে নিবন্ধিত একটি non-profit association। 2024 সালে Forgejo MIT licence থেকে GPLv3 (GNU general public license version 3)-এ পরিবর্তিত হয়। Gitea এখনও MIT licensed এবং এর পেছনে commercial backing রয়েছে।
দৈনন্দিন ব্যবহারে দুইটির feature set কাছাকাছি। তবে একটির database থেকে অন্যটিতে যাওয়ার পথ সরাসরি নয়। January 2025-এর Forgejo v10.0 ছিল সর্বশেষ release, যা সরাসরি Gitea database গ্রহণ করতে পারত। তাও শুধু Gitea v1.22 বা তার আগের সংস্করণ থেকে। August 2026 অনুযায়ী Gitea-এর সংস্করণ 1.27.1। তাই বর্তমান Gitea instance থেকে Forgejo-তে যাওয়ার কোনো supported in-place switch নেই। ডেটা যোগ করার আগে একটি বেছে নিন। পরে পরিবর্তন করতে হলে সেটিকে export এবং re-import হিসেবে পরিকল্পনা করুন।
বেছে নেওয়ার সংক্ষিপ্ত নিয়ম হলো: governance আপনার কাছে গুরুত্বপূর্ণ হলে, অথবা project-টি non-profit-এর অধীনে রাখতে চাইলে Forgejo চালান। বড় install base এবং commercial support option চাইলে Gitea চালান। দুটিই open development model-এ রক্ষণাবেক্ষণ করা হয় এবং নিয়মিত release প্রকাশ করে। Forgejo প্রতি তিন মাসে একটি stable release এবং প্রতি বছর একটি LTS (long term support) release প্রকাশ করে। August 2026 অনুযায়ী বর্তমান সংস্করণ v16.0.2 এবং LTS সংস্করণ v15.0.6।
Tier 3: GitLab কোনো কাজ করার আগেই এর খরচ
GitLab CE ভিন্ন শ্রেণির software। একটি instance পরস্পরের সঙ্গে কাজ করা একাধিক service-এর সমন্বয়: web application-এর জন্য Puma, background job-এর জন্য Sidekiq, PostgreSQL, Redis, repository access-এর জন্য Gitaly এবং সামনে nginx। Omnibus package এগুলো একসঙ্গে install করে। ফলে installation সহজ হয়, কিন্তু memory-এর ন্যূনতম চাহিদা বেশি থাকে।
GitLab-এর requirements page একটি single-node installation-এর baseline হিসেবে 16 GB RAM এবং 8 vCPU উল্লেখ করে। Memory-constrained environment-এ 8 GB-কে নিম্নতম সীমা হিসেবে উল্লেখ করা হয়েছে। একই page-এ swap disable করতে বলা হয়েছে, কারণ load-এর সময় swapping হলে instance-এর performance মারাত্মকভাবে কমে যায়। August 2026 অনুযায়ী এগুলো প্রকাশিত figure। বছরের পর বছর এই চাহিদা বেড়েছে। তাই server-এর capacity নির্ধারণের আগে page-টি আবার পড়ুন।
এই budget-এর বিনিময়ে আপনি বাস্তব সুবিধা পান: container registry, package registry, সূক্ষ্ম স্তরের permission, compliance ও audit feature এবং বড় scale-এ পরীক্ষিত CI। আপনার team-এর কেউ যদি এই তালিকা থেকে চলতি quarter-এ প্রয়োজন এমন কোনো feature-এর নাম বলতে না পারেন, তাহলে আপনি কোনো সুবিধা ছাড়াই বড় VPS-এর জন্য অর্থ দিচ্ছেন।
SSH access model: একটি git user এবং একাধিক key
এখানে প্রতিটি 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@laptopOpenSSH 7.2 থেকে পাওয়া restrict একসঙ্গে port forwarding, agent forwarding, X11 এবং PTY (pseudo terminal) allocation বন্ধ করে। command= client যে request পাঠিয়েছে, তার বদলে আপনার নির্ধারিত command ব্যবহার করে। Git তবুও কাজ করে, কারণ Git তার request $SSH_ORIGINAL_COMMAND-এ পাঠায়।
একটি forge এই file আপনার হয়ে তৈরি করে। tier 0 এবং tier 2-এর মধ্যে এটাই মূল পার্থক্য। Forgejo এবং Gitea authorized_keys-কে rewrite করে। সেখানে নিবন্ধিত প্রতিটি key-এর জন্য একটি করে line থাকে। প্রতিটি line-এ key-টিকে তার database id দিয়ে শনাক্ত করা 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এই forced command-এর মাধ্যমেই একটি shared Unix account-এর permission প্রতি user অনুযায়ী আলাদা হয়। key-3 forge-কে জানায় কোন user connect করছে। কোনো object স্থানান্তরের আগে forge ওই user-এর repository-সংক্রান্ত অনুমতি যাচাই করে। forge-managed box-এ এই file নিজে edit করবেন না। এটি database থেকে আবার লেখা হয়, তাই আপনার line মুছে যাবে। Deploy key-ও একই mechanism ব্যবহার করে। Deploy key হলো একটি সাধারণ SSH key, যা একটি নির্দিষ্ট repository-এর সঙ্গে নিবন্ধিত থাকে। এটি সাধারণত read-only হয়। যাচাইটি sshd-এর বদলে forge-এ সম্পন্ন হয়।
উপরের configuration-এর চেয়ে দুটি অভ্যাস বেশি গুরুত্বপূর্ণ। প্রতি ব্যক্তি বা প্রতি machine-এর জন্য একটি করে key ব্যবহার করুন। কখনো shared key ব্যবহার করবেন না। কারণ shared key revoke করতে হলে একসঙ্গে সবার key rotate করতে হয়। কেউ organization ছাড়ার দিনই তার key সরিয়ে ফেলুন। কারণ ওই file-এ থেকে যাওয়া পুরোনো key এমন একটি স্থায়ী login তৈরি করে, যা কেউ monitor করছে না। একটি server-এ ভালো SSH key management-এ key type এবং passphrase সম্পর্কে আলোচনা আছে। সেগুলো এখানে অপরিবর্তিতভাবে প্রযোজ্য। Box-টি নতুন হলে repository রাখার আগে নতুন VPS-এ প্রথম দশ মিনিট-এ বর্ণিত কাজগুলো করা উচিত।
আমি কি নিজের Git সার্ভারে GitHub Actions চালাতে পারি?
আপনি GitHub Actions syntax-এ লেখা workflow চালাতে পারবেন। তবে GitHub চালাতে পারবেন না। Forgejo v1.21 থেকে Forgejo Actions ডিফল্টভাবে সক্রিয় আছে এবং প্রতিটি repository-এর .forgejo/workflows থেকে workflow file পড়ে। Gitea Actions একইভাবে কাজ করে এবং .gitea/workflows পড়ে। উভয়ের জন্যই runner নামে একটি দ্বিতীয় program ইনস্টল করতে হবে এবং admin settings-এর token দিয়ে সেটিকে আপনার instance-এর সঙ্গে register করতে হবে। প্রকাশিত অনেক action কোনো পরিবর্তন ছাড়াই চলে; তবে যেগুলো GitHub API কল করে বা GitHub-hosted infrastructure প্রত্যাশা করে, সেগুলো চলে না।
দুটি ফলাফলের জন্য প্রস্তুত থাকুন। runner প্রতিটি job-এর জন্য একটি container চালু করে। তাই এর নিজস্ব container engine এবং memory budget প্রয়োজন। এই কারণেই এটিকে forge-এর একই 1 GB server-এ রাখা উচিত নয়। এছাড়া workflow file-এ যা বলা আছে runner তা-ই execute করে। Forgejo-এর documentation-এ বিষয়টি স্পষ্টভাবে বলা হয়েছে: runner remote code execution সম্পাদন করে। সম্ভব হলে runner-এর জন্য আলাদা host ব্যবহার করুন। অন্তত এটিকে নিজস্ব unprivileged user এবং একটি repository-তে সীমাবদ্ধ registration token দিন।
আপনার repository যদি GitHub-এই থাকে এবং শুধু আপনার নিয়ন্ত্রণাধীন hardware-এ compute চালাতে চান, তবে সেটি আলাদা setup এবং তার ধাপও আলাদা: একটি self-hosted GitHub Actions runner GitHub repository-এর সঙ্গে যুক্ত হয় এবং এর জন্য ওপরের কোনো কিছুই প্রয়োজন হয় না। GitHub ছেড়ে গেলে কী খরচ হবে, তা নিয়ে এখনও বিবেচনা করলে GitHub আসলে কী দেয় অংশটি Git hosting এবং এর চারপাশের network service-গুলোকে আলাদা করে ব্যাখ্যা করে।
ব্যাকআপ: repository কেবল মোট অবস্থার অর্ধেক
একটি 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 hook বা description file সংগ্রহ করা হয় না। তাই hook ব্যবহার করলে directory-টির file-level copy-ও রাখুন।
একটি forge তার database-এ issue, pull request, user, key এবং permission রাখে। শুধু repository copy করলে এগুলো সব হারিয়ে যাবে। উভয় project-ই এমন একটি dump command সরবরাহ করে, যা database, repository, configuration এবং attachment-গুলোকে একটি archive-এ লেখে:
sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zipDocker-এর অধীনে একই 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যে user data-এর মালিক, সেই user হিসেবে এটি চালান। Archive এমন একটি directory-তে লিখুন, যেখানে ওই user-এর write permission আছে। এরপর archive-টি server-এর বাইরে copy করুন। যে machine-এর backup নেওয়া হচ্ছে, শুধু সেই machine-এ থাকা backup প্রকৃত backup নয়। Restore হলো যে ধাপটি অনেকে বাদ দেন। এখনই একটি spare box-এ একটি dump unpack করুন। এতে outage চলাকালীন নয়, শান্ত সময়ে procedure-টি শিখে নিতে পারবেন।
পরিস্থিতি অনুযায়ী নির্বাচন
একজন ব্যক্তি, একটি laptop এবং একটি VPS; browsing প্রয়োজন নেই: SSH-এর মাধ্যমে bare repository ব্যবহার করুন। অতিরিক্ত কোনো service চালাতে হবে না এবং upgrade করার মতো কিছু থাকবে না।
একই পরিস্থিতিতে browser-এ code পড়তে এবং code-এর link পাঠাতে চাইলে: cgit যোগ করুন। এখনও database লাগবে না এবং কোনো resident process চলবে না।
যে team একে অপরের code review করে এবং issue track করে: 2 GB বা তার বেশি RAM-এ Forgejo অথবা Gitea ব্যবহার করুন। job বাস্তবে বড় হলে CI runner দ্বিতীয় box-এ সরিয়ে নিন।
যে organisation-এর container registry এবং audit trail প্রয়োজন, এবং server-এর জন্য 16 GB RAM বরাদ্দ করা যায়: GitLab ব্যবহার করুন। এই budget-এর নিচে এটি চালু করবেন না।
প্রথম তিনটি tier-এর মধ্যে উপরের দিকে যাওয়া সস্তা, কারণ প্রতিটি tier-এ repository-গুলো disk-এ থাকা সাধারণ Git directory। কাজের জন্য যথেষ্ট এমন সর্বনিম্ন tier দিয়ে শুরু করুন। একই server-এ আর কোন service-এর জন্য জায়গা রাখা উচিত তা নির্ধারণ করলে, self-hosting করার মতো service-এর সংক্ষিপ্ত তালিকা Git server-কে একই RAM-এর জন্য প্রতিদ্বন্দ্বিতা করা অন্যান্য service-এর পাশে দেখায়।
FAQ
1 GB VPS কি Forgejo বা Gitea চালাতে পারে?
হ্যাঁ, ছোট দলের জন্য SQLite ব্যবহার করলে এবং সার্ভারে অন্য কোনো ভারী workload না থাকলে পারে। Gitea-এর documentation অনুযায়ী ছোট দল ও project-এর জন্য সাধারণত 1 GB RAM এবং 2 CPU core যথেষ্ট। Forgejo হলো Gitea-এর fork, তাই এর প্রয়োজনও একই ধরনের। ওই machine-এ PostgreSQL বা CI runner যোগ করবেন না। নিজের log-এ কোনো error ছাড়াই service অদৃশ্য হয়ে গেলে sudo dmesg -T | grep -i oom চালান। সেখানে নিহত process-এর নামসহ একটি line থাকলে বুঝবেন kernel-এর out-of-memory killer process-টিকে বন্ধ করেছে। এ ক্ষেত্রে tuning flag নয়, বড় plan নেওয়াই সমাধান।
Forgejo এবং Gitea-এর মধ্যে পার্থক্য কী?
দুটির codebase-এর ইতিহাস এবং অধিকাংশ feature একই। Gitea 2016 সালে Gogs থেকে fork হয়। 2022 সালের শেষ দিকে Gitea trademark-এর নিয়ন্ত্রণ একটি company-এর কাছে যাওয়ার পর Forgejo, Gitea থেকে fork হয়। Forgejo জার্মানির non-profit সংস্থা Codeberg e.V. প্রকাশ করে এবং এটি GPLv3-এর অধীনে বিতরণ করা হয়। Gitea MIT license-এর অধীনেই থাকে এবং এর commercial backing রয়েছে। বাস্তব পার্থক্যটি হলো migration path। January 2025-এর Forgejo v10.0 ছিল সর্বশেষ release, যা সরাসরি Gitea database নিতে পারত; সেটিও শুধু Gitea v1.22 বা তার আগের version থেকে। তাই বর্তমান Gitea instance-এ supported in-place switch করার সুযোগ নেই।
Self-hosted Git server-এ কি GitHub Actions workflow চালাতে পারি?
Forgejo Actions এবং Gitea Actions দুটিই GitHub Actions YAML syntax-এ লেখা workflow চালায়। এগুলো .forgejo/workflows এবং .gitea/workflows থেকে পড়া হয়। আপনাকে আলাদা runner program install করে সেটিকে নিজের instance-এর সঙ্গে register করতে হবে। প্রকাশিত অনেক action কোনো পরিবর্তন ছাড়াই কাজ করে। তবে GitHub API call করে এমন action কাজ করে না। Runner আপনার repository থেকে arbitrary code চালায় এবং প্রতি job-এর জন্য একটি container শুরু করে। তাই এটিকে আলাদা host-এ চালান, অথবা অন্তত আলাদা unprivileged user ব্যবহার করুন। ইতিমধ্যে forge চালানো 1 GB server-এ runner চালাবেন না।
Self-hosted Git server-এর backup কীভাবে নেব?
Bare repository-এর ক্ষেত্রে অন্য machine থেকে git clone --mirror চালালে প্রতিটি ref এবং object copy হয়। সেই mirror refresh করতে mirror-এর ভিতরে git remote update চালান। Forgejo বা Gitea-এর ক্ষেত্রে repository state-এর কেবল একটি অংশ। কারণ issue, pull request, user এবং key database-এ থাকে। Built-in dump ব্যবহার করুন: sudo -u git forgejo dump -c /etc/forgejo/app.ini। Docker install হলে একই command container-এর ভিতরে চালান। Archive-টি server-এর বাইরে copy করুন। এরপর spare machine-এ একবার restore করে দেখুন, যাতে procedure-টি কার্যকর কি না নিশ্চিত হতে পারেন।