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

# Failproof AI Cloud को Self-host करें

> Failproof AI नियंत्रण विमान को ग्राहक-प्रबंधित Kubernetes क्लस्टर पर तैनात करें।

<Note>
  Self-hosting एक Enterprise तैनाती है। Enterprise लाइसेंस प्राप्त करने के लिए [Failproof AI से संपर्क करें](mailto:support@befailproof.ai)।
</Note>

## पूर्वापेक्षाएँ

* Kubernetes 1.27 या नवीनतर संस्करण, cluster-admin पहुंच के साथ
* Kustomize समर्थन के साथ `kubectl`
* Helm 3
* निजी `ghcr.io/agenteye-enterprise` images तक पहुंच
* दो DNS नाम: एक डैशबोर्ड के लिए और एक ingest के लिए
* PostgreSQL और ClickHouse के लिए persistent storage
* cert-manager और Traefik, या समकक्ष ingress और certificate infrastructure जो आपके overlay में अनुकूलित हो
* उत्पादन OTP लॉगिन और सूचनाओं के लिए SMTP

स्रोत tree AWS/EKS-उन्मुख overlay और एक अलग GCP/GKE overlay प्रदान करता है। उनके certificate, load-balancer, या backup निर्देशों को संयोजित न करें: GKE अपना DNS-01, GCS, और autoscaling कॉन्फ़िगरेशन उपयोग करता है।

## तैनाती अनुक्रम

<Steps>
  <Step title="क्लस्टर तैयार करें">
    cert-manager और सार्वजनिक/डैशबोर्ड ingress नियंत्रकों को स्थापित करें, उनके load balancers को सत्यापित करें, फिर namespace, image-pull credentials, database credentials, bootstrap admin key, और authentication/SMTP secrets बनाएं।
  </Step>

  <Step title="सार्वजनिक डोमेन कॉन्फ़िगर करें">
    overlay की जेनरेट की गई domain environment file में `INGEST_DOMAIN` और `DASHBOARD_DOMAIN` सेट करें और DNS रिकॉर्ड बनाएं जो मेल खाने वाले load balancers की ओर इशारा करते हों।
  </Step>

  <Step title="एक platform overlay लागू करें और सत्यापित करें">
    customer/EKS या GCP overlay का उपयोग करें। प्रदान किए गए Kustomize output का निरीक्षण करें, इसे लागू करें, और सभी workloads और certificates के अपने इच्छित state तक पहुंचने की पुष्टि करें, इससे पहले कि मशीनों को नामांकित करें।
  </Step>

  <Step title="पहुंच और ingestion को bootstrap करें">
    संरक्षित admin के रूप में साइन इन करें, एक organization-scoped machine key बनाएं, और सार्वजनिक ingest endpoint के माध्यम से एक छोटा परीक्षण सत्र भेजें।
  </Step>
</Steps>

## आवश्यक और वैकल्पिक सेवाएं

| Component             | आवश्यकता                                                                                            |
| --------------------- | --------------------------------------------------------------------------------------------------- |
| ClickHouse            | आवश्यक। सर्वर अपने canonical event store के बिना शुरू होने से इनकार करता है।                        |
| PostgreSQL            | उपयोगकर्ताओं, संगठनों, saved objects, और control-plane state के लिए आवश्यक।                         |
| Redis                 | वैकल्पिक। सर्वर और डैशबोर्ड अनुपलब्ध होने पर database-backed व्यवहार में बदल जाते हैं।              |
| SMTP                  | विकास के लिए वैकल्पिक, उत्पादन ईमेल OTP और सूचना वितरण के लिए आवश्यक।                               |
| Evaluator             | वैकल्पिक। `EVALUATOR_ENDPOINT` के बिना स्वचालित मूल्यांकन अक्षम रहता है।                            |
| Assistant/audit LLM   | वैकल्पिक। Assistant और LLM-backed audit विशेषताएं LLM कनेक्शन कॉन्फ़िगर होने तक निष्क्रिय रहती हैं। |
| Object storage backup | PostgreSQL और ClickHouse backup archives के लिए अत्यधिक अनुशंसित।                                   |

### Audit क्षमता और विफलता वितरण

जब उपलब्ध हो तो dedicated audit-agent deployment पर audits चलाएं। प्रत्येक audit-agent pod डिफ़ॉल्ट रूप से एक investigation स्वीकार करता है; प्रति-pod concurrency को बढ़ाए बिना replicas के साथ throughput स्केल करें, साथ ही memory को भी बढ़ाएं। सर्वर `server replicas × AUDIT_WORKERS` audits को समवर्ती रूप से dispatch कर सकता है, इसलिए dispatcher क्षमता audit-agent fleet को भरने के लिए पर्याप्त होनी चाहिए।

जब प्रत्येक audit-agent slot व्यस्त हो, एक audit प्रतीक्षा करता है और अपने cadence के एक चौथाई तक retry करता है, छह घंटे तक सीमित। यदि कोई slot उपलब्ध नहीं होता, तो run निष्कर्ष के बिना पूरा होता है और विफलता ईमेल भेजता है। बार-बार "busy" विफलताएं अधिक audit-agent replicas या अधिक व्यापक रूप से अलग schedule anchors के लिए कॉल करती हैं। बार-बार "shutting down" विफलताएं अस्थिर pods या अपर्याप्त क्षमता के बजाय एक लूपिंग rollout का संकेत देती हैं।

विफलता सूचनाओं के लिए एक सक्षम ईमेल चैनल और SMTP की आवश्यकता है। वे audit के recipients का उपयोग करते हैं, फिर `alerts.email_default_recipients` पर fallback करते हैं जब audit के पास कोई ईमेल चैनल नहीं है।

## तैनाती को सत्यापित करें

<Tabs>
  <Tab title="डैशबोर्ड">
    1. कॉन्फ़िगर किए गए डैशबोर्ड डोमेन को खोलें, admin OTP प्रवाह को पूरा करें, और organization का नाम और slug सुनिश्चित करें।
    2. **Administration → Keys** पर जाएं और एक संकीर्ण रूप से scoped machine key बनाएं।
    3. एक परीक्षण सत्र भेजें, फिर इसे **Observe → Events** और **Observe → Sessions** में सुनिश्चित करें।
    4. एक alert channel परीक्षण करें और, जब कॉन्फ़िगर किया जाए, एक manual evaluation और audit परीक्षण करें।
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    kubectl get pods -n agenteye
    kubectl get certificates -n agenteye
    kubectl logs -n agenteye deploy/server --tail=100

    fp --base-url https://failproof.example.com login
    fp --base-url https://failproof.example.com whoami
    fp --base-url https://failproof.example.com usage
    ```

    उत्पादन मशीनों को नामांकित करने से पहले सार्वजनिक health endpoint और एक authenticated `/v1` request को सत्यापित करें।
  </Tab>
</Tabs>

## प्रमाणीकरण और ईमेल

डैशबोर्ड ईमेल और one-time codes का उपयोग करता है। SMTP के अभाव में, विकास तैनाती server output में OTP codes log करती है। जब `SMTP_HOST` सेट हो, तो username, password, और sender एक समूह के रूप में आवश्यक हैं या सर्वर शुरू होने से इनकार करता है।

`SMTP_TLS` एक boolean है। समर्थित encrypted transport STARTTLS है, सामान्यतः port 587 पर; implicit SMTPS port 465 पर वर्तमान server transport द्वारा समर्थित नहीं है।

सार्वजनिक डैशबोर्ड URL को सही तरीके से सेट करें क्योंकि OTP, alert, incident, और audit ईमेल deep links के लिए इसका उपयोग करते हैं। Organization membership नियंत्रित करता है कि कौन कोड का अनुरोध कर सकता है; प्रत्येक organization **Administration → Settings** में अपने स्वयं के member sign-ins को आगे restrict कर सकता है।

## Multi-tenant आवश्यकताएं

दूसरा organization बनाने से पहले, एक मजबूत, स्थिर organization ClickHouse derivation secret कॉन्फ़िगर करें और इसे सभी server replicas में समान रखें। इसे coordinated migration के बिना rotate करने से organization-specific ClickHouse users orphan हो सकते हैं।

instance-admin listener को आंतरिक रखें। प्रदान किया गया operator console opt-in है और `kubectl port-forward` के लिए डिज़ाइन किया गया है, सार्वजनिक ingress के लिए नहीं। इसे सक्षम करने के लिए इसके स्वयं के मजबूत API key, एक super-admin mailbox, और कार्यशील SMTP second-factor delivery की आवश्यकता है।

### Break-glass organization CLI

`agenteye-orgctl` server image के अंदर ships करता है और directly PostgreSQL और ClickHouse से बात करता है। यह सार्वजनिक server या operator console unhealthy होने पर उपलब्ध रहता है।

```bash theme={null}
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org create --slug acme --name "Acme Corp"
kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email ops@acme.com --set admin --protected
```

समर्थित organization operations में create, list, rename, soft-delete, restore, ClickHouse-user reprovisioning, billing-date management, feature flags, और irreversible purge शामिल हैं। Member operations में add, list, update, remove, permission overrides, और protected-admin state शामिल हैं।

purge से पहले soft-delete का उपयोग करें। `org purge` irreversible है और organization को पहले delete किए जाने की आवश्यकता है। संरक्षित members को organization के सामान्य Users page के माध्यम से तब तक remove या demote नहीं किया जा सकता जब तक एक operator explicitly उन्हें unprotect नहीं करता।

## उत्पादन तत्परता checklist

* Ingest और डैशबोर्ड DNS विभिन्न इच्छित ingress paths में resolve होते हैं।
* TLS valid है; जहां आपकी तैनाती इसकी आवश्यकता है वहां ingest पर mutual TLS का उपयोग करें।
* PostgreSQL और ClickHouse volumes में capacity alerts हैं।
* Backups में दोनों datastores शामिल हैं और एक tested restore procedure है।
* Health checks ingest silence, failed workloads, certificate expiry, storage pressure, और stale backups पर alert करते हैं।
* Structured logs को एक मौजूदा cluster log pipeline को duplicate किए बिना एकत्रित किया जाता है।
* Evaluator, audit, और alert worker concurrency को measured queue evidence के बिना change नहीं किया गया है।
* एक pinned application release और rollback procedure upgrades से पहले recorded हैं।

<Warning>
  तैनाती manifests में platform-specific security और availability assumptions हैं। उन्हें apply करने से पहले अपनी platform team के साथ rendered resources, network policies, ingress exposure, secret references, storage classes, disruption budgets, और backup destinations की समीक्षा करें।
</Warning>