आपका अपना Git server।
Repository ही org chart है।

सबसे छोटी उस चीज़ से शुरू करें जो आपकी समस्या हल करती है, क्योंकि उसके ऊपर की हर परत एक ऐसी service है जिसे आपको operate करना होगा। SSH पर एक bare repository आपके पास पहले से मौजूद किसी server पर बस एक command है, और यह आपको authentication, history और push access वाला एक असली Git remote दे देता है। न कोई web application, न कोई database, न कोई upgrade treadmill, sshd से आगे कुछ भी patch करने को नहीं। अगर आप एक अकेले व्यक्ति हैं जो अपने commits को किसी laptop से और किसी platform से बाहर निकालना चाहते हैं, तो यह एक पूरा जवाब है और आप step 02 के बाद पढ़ना बंद कर सकते हैं।

# On the server, as an unprivileged user:
mkdir -p ~/git/project.git && cd ~/git/project.git
git init --bare

# On your laptop:
git remote add origin ssh://user@git.example.com/~/git/project.git
git push -u origin main

आपको forge की ज़रूरत तब पड़ती है जब कोई दूसरा व्यक्ति शामिल हो, या जब आपको उन चार चीज़ों में से कोई चाहिए जो bare repositories की एक directory नहीं कर सकती: history को browser में browse करना, बदलावों को pull requests के तौर पर review करना, code के बग़ल में issues track करना, और एक व्यक्ति को एक repository का access देना। यह क्षमता में एक असली कदम ऊपर है और operational बोझ में भी एक असली कदम ऊपर है। जान-बूझकर चुनें:

Forgejo और Gitea का पुरखा एक ही है और रोज़मर्रा के इस्तेमाल में आज भी लगभग एक जैसे दिखते हैं। Forgejo early 2024 में एक hard fork बना और इसे Codeberg e.V. रखती है, जो Berlin में registered एक गैर-लाभकारी association है; Gitea को एक for-profit company विकसित करती है जो अपने trademark की मालिक है और contributors से copyright assignment माँगती है। दोनों अच्छे software हैं। इनमें से सिर्फ़ एक का custodian ऐसा है जिसकी प्रेरणाएँ उस वजह से मेल खाती हैं जिसके लिए आप यह पेज पढ़ रहे हैं।

इस guide का बाक़ी हिस्सा Forgejo इस्तेमाल करता है। steps 02 से 06 तक सब कुछ Gitea पर लगभग हू-ब-हू लागू होता है — container का नाम और कुछ environment variables बदल जाते हैं, ढाँचा नहीं बदलता।

Forgejo, PostgreSQL और Caddy। Forgejo repositories रखता है और interface serve करता है, PostgreSQL वह सब कुछ रखता है जो कोई Git object नहीं है, और Caddy TLS terminate करता है और बिना दोबारा पूछे certificate हासिल कर लेता है। PostgreSQL को जान-बूझकर host पर publish नहीं किया जाता: यह सिर्फ़ Compose network पर, नाम से, उसी एक container से पहुँच लायक है जिसे इसकी ज़रूरत है।

/srv/forgejo/.env

FORGEJO_DOMAIN=git.example.com
FORGEJO_VERSION=15                             # the LTS line; 16 is current stable
POSTGRES_PASSWORD=$(openssl rand -base64 32)   # paste the value, do not leave the $( )

/srv/forgejo/docker-compose.yml

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_VERSION}
    container_name: forgejo
    environment:
      USER_UID: 1000
      USER_GID: 1000
      FORGEJO__database__DB_TYPE: postgres
      FORGEJO__database__HOST: db:5432
      FORGEJO__database__NAME: forgejo
      FORGEJO__database__USER: forgejo
      FORGEJO__database__PASSWD: ${POSTGRES_PASSWORD}
      FORGEJO__server__DOMAIN: ${FORGEJO_DOMAIN}
      FORGEJO__server__ROOT_URL: https://${FORGEJO_DOMAIN}/
      FORGEJO__server__SSH_DOMAIN: ${FORGEJO_DOMAIN}
      FORGEJO__server__SSH_PORT: "2222"          # what clones will say
      FORGEJO__server__SSH_LISTEN_PORT: "22"     # what the container listens on
      FORGEJO__service__DISABLE_REGISTRATION: "true"
      FORGEJO__repository__DEFAULT_PRIVATE: private
      FORGEJO__security__INSTALL_LOCK: "true"
    restart: unless-stopped
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"    # web, reached only by Caddy
      - "2222:22"                # git over SSH, public
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    container_name: forgejo-db
    environment:
      POSTGRES_USER: forgejo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: forgejo
    restart: unless-stopped
    volumes:
      - ./postgres:/var/lib/postgresql/data
    # No ports: block. This is the point.

  caddy:
    image: caddy:2-alpine
    container_name: forgejo-caddy
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config

/srv/forgejo/Caddyfile

git.example.com {
    encode zstd gzip
    request_body {
        max_size 512MB          # raise it if you push large repositories
    }
    reverse_proxy 127.0.0.1:3000
}

वे दो SSH lines हैं जिन्हें लोग ग़लत कर बैठते हैं, इसलिए इन्हें दो बार पढ़ना उचित है। SSH_LISTEN_PORT वह port है जो container के अंदर है, जहाँ Forgejo का built-in SSH server bind होता है। SSH_PORT वह port है जिसे Forgejo आपको दिखाई गई clone URLs में print करता है — इसे port mapping के public side से मेल खाना चाहिए। इन्हें आपस में उलझा दें तो सब कुछ काम करता है सिवाय उस एक चीज़ के जिसे users copy-paste करते हैं।

इसे up करें, फिर administrator को command line से बनाएँ। web installer इस्तेमाल न करें। किसी नए instance पर यह उस किसी के लिए भी पहुँच लायक होता है जो hostname ढूँढ ले, और इसके ज़रिए बनाया गया पहला account administrator बन जाता है — ऐसी दौड़ जिसमें उतरने की ज़रूरत नहीं। ऊपर वाली file में INSTALL_LOCK container के शुरू होने से पहले ही इसे बंद कर देता है।

docker compose up -d
docker compose logs -f forgejo        # wait for "Starting new Web server"

docker compose exec -u git forgejo forgejo admin user create \
  --admin --username you --email you@example.com --random-password

browser में hostname खोलें, print हुए password से sign in करें और उसे बदल दें। फिर उन settings से गुज़रें जो एक चलते हुए instance को एक बंद instance में बदल देती हैं — इनमें से ज़्यादातर पहले से ही ऊपर वाले environment block से सेट हैं, और मान लेने के बजाय हर एक की पुष्टि करना उचित है:

याद रखने लायक एक path: live configuration host पर ./data/gitea/conf/app.ini पर होता है। मौजूदा installations के साथ compatibility के लिए Forgejo ने gitea directory का नाम रखा रहने दिया, जो हर किसी को ठीक एक बार हैरान करता है। FORGEJO__section__KEY जैसे रूप के environment variables शुरू होते समय उस file में लिख दिए जाते हैं, इसलिए आप पूरा configuration Compose file से manage कर सकते हैं — लेकिन अगर आप app.ini को हाथ से edit करें, तो उसी key का एक environment variable अगले restart पर आपके edit को overwrite कर देगा। दोनों में से एक चुनें और उसी पर टिके रहें।

Forgejo Actions, GitHub Actions जैसे ही format में workflow files .forgejo/workflows/ से पढ़ता है, और उन्हें एक अलग program को सौंप देता है जिसे Forgejo Runner कहा जाता है। runner forge का हिस्सा नहीं है और उसे उसी machine पर रहने की ज़रूरत नहीं — यही पूरा design है, और यही वजह है कि इस step पर बेपरवाही नहीं बल्कि एक चेतावनी दी गई है।

instance पर Actions enable करें, फिर administration panel से एक registration token लें — पूरे instance के लिए, या किसी एक organisation या एक repository तक scoped — जो कि पक्का न होने पर बेहतर डिफ़ॉल्ट है। runner बाहर की ओर forge से जुड़ता है, इसलिए इसे किसी inbound port की ज़रूरत नहीं और यह किसी भी firewall के पीछे बैठ सकता है, यहाँ तक कि किसी बिना public address वाली machine पर भी।

# In the Compose environment of the forge, or app.ini:
#   FORGEJO__actions__ENABLED: "true"
# Then: Site administration -> Actions -> Runners -> Create new runner

# On the runner machine:
forgejo-runner generate-config > config.yml

forgejo-runner register --no-interactive \
  --instance https://git.example.com \
  --token <REGISTRATION_TOKEN> \
  --name runner-01 \
  --labels docker:docker://node:22-bookworm,debian:docker://debian:12

forgejo-runner --config config.yml daemon

labels ही workflow और runner के बीच का करार हैं: जो job runs-on: docker माँगती है उसे दाईं ओर की image से बना एक container मिलता है। सिर्फ़ वही labels declare करें जिन्हें आप सचमुच serve करने को तैयार हैं, क्योंकि जो job किसी ऐसे label की माँग करती है जिसे कोई नहीं देता, वह असफल होने के बजाय हमेशा के लिए रुकी रहती है, जिसे किसी लंबे दिन के आख़िर में debug करना उलझन भरा होता है।

.forgejo/workflows/ci.yml

on: [push, pull_request]

jobs:
  test:
    runs-on: docker
    container:
      image: node:22-bookworm
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

secrets को भी उसी तरह scope करें। Forgejo इन्हें repository, organisation और instance स्तर पर रखता है; जिस deployment key की ज़रूरत सिर्फ़ एक repository को है वह सिर्फ़ उसी repository पर होनी चाहिए, ताकि किसी असंबंधित project में compromise हुआ workflow उसे पढ़ न सके। जहाँ भी target support करे वहाँ लंबी उम्र वाले tokens की बजाय छोटी उम्र वाले tokens को तरजीह दें, और कभी किसी workflow file में कोई secret न डालें — workflow file repository में ही है, और repository की एक history होती है।

अगर आपके builds हर run पर वही base images खींचते हैं, तो उन्हें cache करें। एक local registry mirror या एक persistent runner cache दो-मिनट के image pull को दो-सेकंड का बना देता है, और जिन upstream registries पर आप बार-बार बोझ डाल रहे हैं उनके साथ यह शिष्टाचार भी है। और उस pattern पर ग़ौर करें जिसे यह पूरा design न्योता देता है, और यही वजह है कि यह guide agent runtime गाइड के बग़ल में बैठी है: runner एक general-purpose worker है जो आपके forge से jobs खींचता है, इसलिए scheduled maintenance, data pipelines और agent workloads का ठिकाना भी यही है।

किसी forge को self-host करना इस बात में एक असली बदलाव है कि आपका काम किसके पास रहता है, और यह अदृश्यता नहीं है। ऊपर की सारी बातें पूरी हो जाने के बाद भी चार चीज़ें सच बनी रहती हैं, और इन्हें जानना ही एक असली बचाव और अपने-आप से कही गई कहानी के बीच का फ़र्क़ है।

Disk किसी और की इमारत में है। किराए का एक server दरवाज़ों और staff वाले किसी datacentre के hardware पर चलता है। NordBastion customer workloads का निरीक्षण नहीं करता, और transparency report व warrant canary बताते हैं कि अगर हमसे कुछ पूछा जाए तो क्या होगा — लेकिन ईमानदार बात architectural वाली है: जो बदलता है वह यह है कि अब आपकी repositories का कोई product-level index नहीं, आपके commits पर कोई analytics pipeline नहीं और कोई ऐसी privacy policy नहीं जिसे बदला जा सके। जो नहीं बदलता वह यह है कि machine भौतिक है और यह आपके घर में नहीं है।

Certificate जारी होते ही hostname सार्वजनिक हो जाता है। हर publicly trusted certificate certificate-transparency logs में publish होता है जिन्हें कोई भी खोज सकता है, तो git.yourproject.com खोजा जा सकता है भले ही आप इसे कभी link न करें। यह आपके code का लीक नहीं है, पर यह इस तथ्य का लीक है कि project मौजूद है और मोटे तौर पर कब शुरू हुआ। किसी ऐसे नाम के subdomain का इस्तेमाल करें जिसे आप पहले से publish करते हैं, या public certificate को पूरी तरह छोड़ दें और forge तक WireGuard या किसी onion service पर पहुँचें।

अब आप एक web application patch कर रहे हैं। forge एक login page है, untrusted markup के लिए एक rendering pipeline है, एक SSH server है और एक CI engine है, यह सब internet से पहुँच लायक। यह step 01 वाली bare repository से कहीं बड़ा surface है, और इसे मौजूदा बनाए रखना आपका काम है। release announcements को subscribe करें, और किसी security release को same-quarter नहीं बल्कि same-week काम की तरह बरतें।

Federation अभी यहाँ नहीं पहुँचा है। Forgejo forge federation पर असली काम कर रहा है और इसकी प्रगति publish करता है, लेकिन आज की तारीख़ में आप अपने instance से किसी और के instance पर pull request उस तरह नहीं खोल सकते जैसे किसी shared platform पर खोल सकते हैं। व्यवहार में, इसका मतलब है कि किसी बाहरी contributor को अब भी आपके forge पर एक account चाहिए, या आप patches को email से स्वीकार करें, या drive-by contributions के लिए एक public mirror रखें। इन तीनों में से जो भी आपके project से मेल खाए उसकी योजना बनाएँ, बजाय इसके कि आप इससे चौंक जाएँ।

आपने असल में जो ख़रीदा है, बिल्कुल सटीक रूप से: आप क्या बनाते हैं, किसके साथ, और कब, इसका दर्ज़ रिकॉर्ड अब किसी ऐसी company के पास नहीं है जिसके business model में उसे विश्लेषित करना शामिल है। यह एक संकुचित दावा है, और यह एक असली दावा है। यह अपनी क़ीमत के लायक तभी है जब step 06 पूरा हो चुका हो — बिना जाँचे गए restore वाला एक self-hosted forge कोई privacy सुधार नहीं है, यह बेहतर branding वाला एक single point of failure है।