> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kombify.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Gitea

> नेटिव HTTPS Git और ओनर कस्टडी के साथ जारी किया गया निजी Git dev वर्कलोड चलाएँ

Gitea [Development](/hi/guides/stackkits/use-cases/development) यूज़ केस उपलब्ध कराता है। Gitea वाला dev वर्कलोड एक चुने हुए नोड पर SQLite के साथ रूटलेस कंटेनर में निजी Git सर्वर चलाता है। सार्वजनिक रजिस्ट्रेशन बंद है और नई रिपॉज़िटरी अनिवार्य रूप से निजी बनती हैं। यह SSH एक्सपोज़ नहीं करता, CI रनर इंस्टॉल नहीं करता और Actions सक्षम नहीं करता; अतिरिक्त उपयोगकर्ताओं और API टोकन के वर्कफ़्लो नेटिव Gitea ऑपरेशन बने रहते हैं। प्रकाशित रिलीज़ जो घटक घोषित करती है, वे [यूज़-केस कैटलॉग](/hi/stackkits/reference/use-case-catalog) में सूचीबद्ध हैं।

## dev वर्कलोड को स्पष्ट रूप से चुनें

खाली ओनर वर्कस्पेस से, Gitea चुनें और उसकी स्थानीय ओनर कस्टडी स्थापित करें:

```bash theme={null}
stackkit init basement-kit --platform standalone-compose \
  --use-case dev --use-case-alternative dev=gitea \
  --use-case-alternative basement-core=standalone \
  --module-compute-profile stackkits-basement-core-runtime=standard \
  --module-compute-profile stackkits-gitea-runtime=standard \
  --owner-source local --owner-email owner@example.com --non-interactive
```

जनरेट करने से पहले, नीचे दिए फ़ील्ड को अपने [StackSpec](/hi/guides/stackkits/configure-stack-spec) के मौजूदा `capabilities`, `data` और `routes` अनुभागों में मर्ज करें। उनकी अन्य प्रविष्टियाँ बनाए रखें। यह अंश शुरुआती `home` साइट और `home-private` एक्सेस नीति उपयोग करता है; उन संदर्भों, होम डोमेन और होस्ट स्टोरेज रूट को अपने वास्तविक होस्ट के अनुसार बदलें।

```yaml theme={null}
capabilities:
  enable: [internal-pki]
data:
  bindings:
    dev:
      classes: [personal]
      primarySiteRef: home
routes:
  dev:
    serviceRef: dev
    moduleRef: stackkits-gitea-runtime
    exposure: local
    protocol: https
    port: 443
    targetPort: 3000
    host: dev.home.test
    path: /
    accessPolicyRef: home-private
```

उपयोगी नेटिव क्लोन URL के लिए Gitea को यह स्पष्ट HTTPS रूट और डेटा बाइंडिंग चाहिए। परिणाम को सत्यापित और जनरेट करें:

```bash theme={null}
stackkit validate
stackkit generate --local-node main --local-site home
```

फिर सामान्य डिलीवरी लाइफ़साइकिल का पालन करें: सत्यापित करें, प्लान का निरीक्षण करें, और [समीक्षा करें, लागू करें और सत्यापित करें](/hi/guides/stackkits/review-plan-and-apply) में बताए अनुसार apply और verify करें। देखा गया होस्ट इन्वेंटरी चुने गए मॉड्यूल प्रोफ़ाइल को पूरा करती होनी चाहिए; उदाहरण कॉन्फ़िगरेशन हार्डवेयर का प्रमाण नहीं है।

## नाम उपलब्ध कराएँ और रूट के काम करने पर भरोसा करें

नेटिव HTTPS Git को दो चीज़ें चाहिए जो आपके होस्ट को पहले से पूरी करनी होंगी:

* रूट का होस्टनाम (उदाहरण में `dev.home.test`) उन सभी क्लाइंट से उस होस्ट पर रिज़ॉल्व होना चाहिए जिनसे आप क्लोन करना चाहते हैं।
* Git क्लाइंट को होस्ट का आंतरिक CA सर्टिफ़िकेट भरोसेमंद मानना चाहिए। क्लाइंट ट्रस्ट के बिना HTTPS क्लोनिंग ऑथेंटिकेशन से पहले ही विफल हो जाती है।

## ओनर पासवर्ड दिखाएँ और साइन इन करें

पहली बार शुरू होने पर, ट्रैफ़िक परोसने से पहले SQLite डेटाबेस माइग्रेट होता है और एडमिनिस्ट्रेटर `owner` बनता है; ओनर ईमेल आपकी स्थानीय ओनर पहचान से आता है, और `owner-password` संदर्भ मौजूदा स्थानीय सीक्रेट कस्टडी में रखा जाता है। पासवर्ड निजी टर्मिनल में पढ़ें:

```bash theme={null}
stackkit secrets reveal --workload dev --slot owner-password
```

कमांड केवल वर्तमान सत्यापित StackSpec में घोषित स्लॉट स्वीकार करती है, मान को stdout पर लिखती है — कभी डिप्लॉयमेंट लॉग में नहीं — और न पासवर्ड बनाती है, न रीसेट करती है। कोई मौजूदा बेमेल एडमिनिस्ट्रेटर या बिना स्वामी वाला उपयोगकर्ता डेटाबेस, खाते बदले या पासवर्ड रीसेट किए बिना, डिलीवरी को विफल कर देता है।

`owner` के रूप में साइन इन करें, निजी रिपॉज़िटरी बनाएँ और उसका HTTPS क्लोन URL अपने नेटिव Git क्रेडेंशियल स्टोरेज के साथ उपयोग करें। Git सीधे Gitea से ऑथेंटिकेट होता है: कोई ब्राउज़र फ़ॉरवर्ड-ऑथ गेट Git अनुरोधों को नहीं रोकता। केवल HTTP प्रोसेस और SQLite को पहुँच योग्य बताने वाली तैयारी यह साबित नहीं करती कि आपने कुछ क्लोन, पुश या रिकवर किया है — इच्छित क्लाइंट से वास्तविक पुश परखें।

## स्टोरेज और रिकवरी की सीमा

| Allocation | Container path | Contents |
| - | - | - |
| `gitea/data` | `/var/lib/gitea` | SQLite डेटाबेस, रिपॉज़िटरी, LFS ऑब्जेक्ट, एप्लिकेशन डेटा |
| `gitea/config` | `/etc/gitea` | `app.ini` और स्थायी एप्लिकेशन की/कॉन्फ़िगरेशन |

दोनों नामित वॉल्यूम वर्कलोड के डेटा और बैकअप कॉन्ट्रैक्ट का हिस्सा हैं। सही रिकवरी एप्लिकेशन के एकल राइटर को शांत करती है, दोनों वॉल्यूम कैप्चर करती है और राइट रोककर उन्हें एक साथ सक्रिय करती है — SQLite फ़ाइल की अकेली लाइव कॉपी वह कॉन्ट्रैक्ट नहीं है। वर्कस्पेस लाइफ़साइकिल के लिए [बैकअप और रिस्टोर](/hi/guides/stackkits/back-up-and-restore) का पालन करें। रूटलेस और रूटफ़ुल Gitea अलग लेआउट उपयोग करते हैं, इसलिए इमेज बदलना स्टोरेज माइग्रेशन नहीं है।

## ज्ञात सीमाएँ

* SSH एक्सपोज़ नहीं है; नेटिव HTTPS ही दस्तावेज़ित Git एक्सेस पथ है।
* Gitea Actions और CI रनर इंस्टॉल नहीं होते; रनर इंटीग्रेशन का अभी कोई दस्तावेज़ित पथ नहीं है।
* कंटेनर को बलपूर्वक दोबारा बनाने पर भी ओनर एक्सेस, निजी रिपॉज़िटरी मेटाडेटा और एप्लिकेशन कॉन्फ़िगरेशन बना रहता है, लेकिन पूर्ण Linux होस्ट प्रोविज़निंग, असली LAN DNS/CA वितरण और पूरा बैकअप/रिस्टोर चक्र अलग प्रमाण स्तर हैं और यहाँ सिद्ध नहीं हैं।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.