> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/hi/self-hosted/enterprise/secure-gateway.md).

# Secure Gateway

Secure Gateway Roboflow Deployment servers को आपकी कंपनी के DMZ में आवश्यक routes proxy करता है, और model weights तथा container images को स्थानीय रूप से cache करता है।

Secure Gateway, Roboflow API और आपके मॉडलों के वज़नों के लिए एक प्रॉक्सी है, जब आप Roboflow Inference Server को इंटरनेट से फ़ायरवॉल करते हैं। यह का उत्तराधिकारी है [लाइसेंस सर्वर](/deployment/hi/self-hosted/enterprise/license-server.md) और मॉडल वज़नों तथा कंटेनर इमेजों की स्थानीय कैशिंग जोड़ता है, ताकि इनफ़रेंस सर्वरों का एक बेड़ा egress के एक नियंत्रित बिंदु को साझा करे।

{% hint style="info" %}
यह पेज मूल बातें कवर करता है। पूरी कॉन्फ़िगरेशन और संचालन संदर्भ के लिए, देखें [सुरक्षित गेटवे मैनुअल](https://secure-gateway.roboflow.com/manual/).
{% endhint %}

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

* Docker Engine 20.10+, या Kubernetes v1.24+
* api.roboflow\.com और repo.roboflow\.com तक पहुँच वाला एक होस्ट
* 80 पोर्ट उपलब्ध, और TLS को गेटवे के सामने एक लोड बैलेंसर पर या कंटेनर के अंदर समाप्त किया गया हो
* 4GB+ मेमोरी
* कैश के लिए एक S3 बकेट, या 50GB+ स्थानीय डिस्क

{% hint style="info" %}
Red Hat Enterprise Linux पर डिप्लॉय कर रहे हैं? [RHEL पर Podman के साथ Secure Gateway](/deployment/hi/self-hosted/enterprise/secure-gateway-podman.md) RHEL होस्ट्स को बिना Docker या Kubernetes के कवर करता है, और [MicroShift पर सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) MicroShift चला रहे Red Hat Device Edge होस्ट्स को कवर करता है। दोनों समान air-gapped bundle मॉडल के साथ समर्पित इंस्टॉलर का उपयोग करते हैं।
{% endhint %}

## Secure Gateway का उपयोग

एक मशीन पर जिसके पास पहुँच हो `https://api.roboflow.com` और `https://repo.roboflow.com`, Secure Gateway कंटेनर को pull करें:

```
docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

यह `नवीनतम` टैग सबसे हालिया रिलीज़ को ट्रैक करता है। प्रोडक्शन के लिए, और विशेष रूप से air-gapped डिप्लॉयमेंट्स के लिए, इसके बजाय एक विशिष्ट संस्करण pin करें ताकि upgrades जानबूझकर और पुनरुत्पाद्य रहें, उदाहरण के लिए `repo.roboflow.com/roboflow-edge/secure-gateway:0.2.0`.

इसे स्थानीय डिस्क कैश और स्थानीय परीक्षण के लिए loopback-only HTTP listener या उसी होस्ट पर TLS proxy के साथ चलाएँ:

```
docker run -d --name secure-gateway -p 127.0.0.1:80:80 --restart unless-stopped \\
    -v gateway-cache:/var/cache/secure-gateway \\
    repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

सुनिश्चित करें कि यह चल रहा है:

```
curl http://localhost/health
```

स्थानीय डिस्क के बजाय S3 पर कैश करने के लिए, `CACHE_S3_BUCKET` और `CACHE_S3_REGION` पर्यावरण चर सेट करें। किसी instance या IAM role का उपयोग करने के लिए credentials खाली छोड़ दें।

## TLS प्रमाणपत्र

डिफ़ॉल्ट रूप से गेटवे plain HTTP पर सुनता है, और आप उसके सामने एक load balancer पर TLS समाप्त करते हैं। स्वयं गेटवे से HTTPS सर्व करने के लिए, अपना certificate और private key कंटेनर में mount करें और दोनों सेट करें `TLS_CERT_FILE` और `TLS_KEY_FILE`. फिर गेटवे अपने configured port पर HTTPS सर्व करता है:

```
docker run -d --name secure-gateway -p 443:443 --restart unless-stopped \\
    -e PORT=443 \\
    -e TLS_CERT_FILE=/etc/ssl/certs/gateway.crt \\
    -e TLS_KEY_FILE=/etc/ssl/private/gateway.key \\
    -v /path/to/certs:/etc/ssl:ro \\
    -v gateway-cache:/var/cache/secure-gateway \\
    repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

दोनों `TLS_CERT_FILE` और `TLS_KEY_FILE` inbound HTTPS सक्षम करने के लिए आवश्यक हैं, और प्रत्येक एक PEM-encoded फ़ाइल की ओर इशारा करता है।

जब gateway का outbound traffic Zscaler जैसे corporate TLS inspection proxy से होकर गुजरता है, तो `TLS_CA_BUNDLE` को उस proxy के CA bundle पर सेट करें ताकि gateway api.roboflow\.com और repo.roboflow\.com से अपने connections पर भरोसा करे:

```
-e TLS_CA_BUNDLE=/etc/ssl/certs/corporate-ca.pem
```

## Inference Servers को कनेक्ट करना

प्रत्येक Inference Server को gateway के HTTPS listener या TLS proxy पर एक स्पष्ट `SECURE_GATEWAY` URL के साथ point करें। सर्वर अपने Roboflow API calls और model downloads को उस address के through route करता है।

```bash
sudo docker run --rm -p 127.0.0.1:9001:9001 \\
    --env SECURE_GATEWAY=https://gateway.example.com \\
    roboflow/roboflow-inference-server-cpu:latest
```

जब यह 443 से अलग हो, जैसे `https://gateway.example.com:8443`. प्रमाणपत्र में URL में होस्टनाम या IP शामिल होना चाहिए, और Inference Server कंटेनर को उसके issuing CA पर भरोसा करना चाहिए; gateway के outbound को configure करना `TLS_CA_BUNDLE` clients पर trust स्थापित नहीं करता।

का उपयोग करें [Podman के साथ RHEL](/deployment/hi/self-hosted/enterprise/secure-gateway-podman.md) या [MicroShift](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) उन deployments का उपयोग करते समय client installation instructions.

### पुराने पते और स्थानीय टनल

सभी संस्करणों में एक स्पष्ट HTTPS scheme का उपयोग करें। pending runtime-hardening build में, bare addresses HTTP से HTTPS में बदल जाते हैं, और plaintext remote या LAN gateways अस्वीकृत होते हैं; देखें [उस build में False](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md#gateway-transport).

वह build explicit HTTP केवल loopback IP या `localhost`, जैसे `SECURE_GATEWAY=http://127.0.0.1:8080`. tunnel को Inference Server के अपने network namespace से reachable होना चाहिए; bridge container का loopback उसके host का loopback नहीं है।

सिर्फ gateway को api.roboflow\.com और repo.roboflow\.com तक outbound access की आवश्यकता होती है। Inference Server शुरू होने के बाद, एक model चलाएँ और पुष्टि करें कि requests gateway के access logs में दिखाई देती हैं।

पुराना `LICENSE_SERVER` variable अभी भी के alias के रूप में स्वीकार किया जाता है `SECURE_GATEWAY`, समान transport rules के साथ। `SECURE_GATEWAY` नए configurations के लिए

## कैशिंग

Secure Gateway पहली डाउनलोड पर प्रत्येक response को कैश करता है, और इसे इस आधार पर tier किया जाता है कि सामग्री कितनी बार बदलती है। content-addressed container blobs और model weights सबसे लंबे समय तक रखे जाते हैं, और mutable API responses थोड़े छोटे window के लिए। किसी भी Inference Server से आने वाले subsequent requests कैश से सर्व किए जाते हैं, जिससे एक fleet में bandwidth use और cold starts कम होते हैं।
