> 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/inference-server/configuration/security.md).

# स्व-होस्टेड सर्वर को सुरक्षित करना

डिफ़ॉल्ट रूप से self-hosted Inference को local रखें, चुनें कि कौन Workflows चला सकता है, और model, media, तथा transport controls कॉन्फ़िगर करें।

Self-hosted Inference स्थानीय विकास को खुला रखता है: कस्टम Python डिफ़ॉल्ट रूप से स्थानीय रूप से चलता है, और जब तक आप प्रमाणीकरण कॉन्फ़िगर नहीं करते, सर्वर को API key की आवश्यकता नहीं होती। CLI सर्वर को पर प्रकाशित करता है `127.0.0.1` डिफ़ॉल्ट रूप से, नीचे दिए गए अपवादों के साथ, इसलिए अन्य मशीनें उस प्रकाशित पोर्ट तक नहीं पहुँच सकतीं।

अपग्रेड व्यवहार और संस्करण-सीमा के लिए, देखें [Security Configuration Migration](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md).

## नेटवर्क पहुँच सीमित करें

Workflow की कौन-सी सुविधाएँ वे उपयोग कर सकते हैं, यह बदलने से पहले तय करें कि क्लाइंट आपके सर्वर तक कैसे पहुँचेंगे।

<table data-search="false"><thead><tr><th>लॉन्च विधि</th><th>डिफ़ॉल्ट नेटवर्क पहुँच</th><th>कॉन्फ़िगरेशन</th></tr></thead><tbody><tr><td>CPU या GPU होस्ट पर Inference CLI</td><td>होस्ट लूपबैक, 127.0.0.1:9001</td><td>कोई दूसरा होस्ट पता चुनने के लिए --bind-address या -b का उपयोग करें।</td></tr><tr><td>Jetson इमेज के साथ Inference CLI</td><td>सभी होस्ट इंटरफ़ेस, 0.0.0.0:9001</td><td>केवल स्थानीय पहुँच के लिए --bind-address 127.0.0.1 का उपयोग करें।</td></tr><tr><td>macOS और Windows डेस्कटॉप बंडल</td><td>127.0.0.1</td><td>कोई दूसरा इंटरफ़ेस चुनने के लिए HOST को स्पष्ट रूप से सेट करें।</td></tr><tr><td>मैनुअल Docker या Compose</td><td>पोर्ट मैपिंग द्वारा निर्धारित</td><td>केवल स्थानीय पहुँच के लिए 127.0.0.1:9001:9001 का उपयोग करें।</td></tr><tr><td>--tunnel के साथ Inference CLI</td><td>CLI 0.0.0.0 पर प्रकाशित करता है ताकि टनल कनेक्ट हो सके।</td><td>LAN और टनल दोनों की पहुँच की समीक्षा करें।</td></tr></tbody></table>

### CLI के साथ सर्वर शुरू करना

`inference server start` पर पोर्ट 9001 प्रकाशित करता है `127.0.0.1`, इसलिए इस तरह शुरू किया गया सर्वर केवल उसे शुरू करने वाली मशीन के प्रक्रियाओं को जवाब देता है। यह स्थानीय विकास के लिए सही डिफ़ॉल्ट है, और यही एकमात्र कॉन्फ़िगरेशन है जिसमें इस पेज के permissive डिफ़ॉल्ट सुरक्षित हैं। गैर-लूपबैक पते पर प्रकाशित करते समय CLI चेतावनी देता है।

```bash
# डिफ़ॉल्ट: केवल इस मशीन से पहुँचा जा सकता है
inference server start

# जानबूझकर LAN पहुँच: इस होस्ट तक रूट कर सकने वाली हर मशीन से पहुँचा जा सकता है - पहले इसे सुरक्षित करें
inference server start --bind-address 0.0.0.0 --env-file inference.env
```

{% hint style="warning" %}
**NVIDIA Jetson अपवाद है।** Jetson इमेजेज़ headless edge devices हैं जिन्हें लगभग हमेशा किसी दूसरी मशीन से नियंत्रित किया जाता है, इसलिए `inference server start` उन्हें पर प्रकाशित करता है `0.0.0.0` - डिवाइस तक रूट कर सकने वाली किसी भी चीज़ से पहुँच योग्य, जिसमें वह पूरी Wi‑Fi नेटवर्क भी शामिल है जिससे यह जुड़ा है। नीचे दिए गए नियंत्रण लागू करें, या इसे इसके साथ सीमित करें `inference server start --bind-address 127.0.0.1`.
{% endhint %}

### के साथ सर्वर शुरू करना `docker run`

इमेज आपके लिए यह चयन नहीं कर सकती, इसलिए **आपको इसे कमांड लाइन पर करना होगा**. `HOST` इंटरफ़ेस चुनता है *के अंदर* कंटेनर, और कंटेनर का अपना network namespace होता है: एक इमेज जो शिप की गई थी `HOST=127.0.0.1` कंटेनर के अपने लूपबैक से bind होती, जिसे प्रकाशित पोर्ट पहुँच नहीं सकते, और सर्वर host से भी unreachable हो जाता। यही कारण है कि हर इमेज शिप होती है `HOST=0.0.0.0`. Bridge-networked कंटेनर के अंदर इसे वैसे ही रखें और प्रतिबंध को इसके बजाय पोर्ट मैपिंग के host पक्ष पर लगाएँ:

```bash
# केवल इस मशीन से पहुँचा जा सकता है
docker run --rm -p 127.0.0.1:9001:9001 roboflow/roboflow-inference-server-cpu:latest

# इस होस्ट तक रूट कर सकने वाली हर मशीन से पहुँचा जा सकता है - पहले इसे सुरक्षित करें
docker run --rm -p 9001:9001 roboflow/roboflow-inference-server-cpu:latest
```

दो मामलों का व्यवहार अलग होता है:

* **`--network host`** (Linux) पोर्ट मैपिंग को पूरी तरह हटा देता है, इसलिए कंटेनर host इंटरफ़ेस से सीधे bind होता है। वहाँ, `-e HOST=127.0.0.1` *है* सर्वर को स्थानीय रखने का तरीका।
* **Kubernetes** हर pod को अपना network namespace देता है, इसलिए `HOST=0.0.0.0` को रखें और bind address के बजाय Service type और NetworkPolicy के साथ exposure नियंत्रित करें।

{% hint style="warning" %}
**`-p 9001:9001` का अर्थ है हर इंटरफ़ेस।** स्पष्ट पता न होने पर, Docker पर प्रकाशित करता है `0.0.0.0`में, जिसमें host के पास कोई public IP भी शामिल है। Linux पर, Docker के अपने forwarding rules पहले मूल्यांकित किए जाते हैं `ufw`/`firewalld` अधिकांश डिफ़ॉल्ट सेटअप में नियमों से पहले, इसलिए आपने अलग से कॉन्फ़िगर किया हुआ host firewall इसे रोक नहीं सकता। वास्तव में क्या सुन रहा है, यह जाँचें `docker port <container>` या `ss -tlnp | grep 9001`.
{% endhint %}

{% hint style="info" %}
प्रत्यक्ष Python server launches, host networking, और manual Docker publishing को अपनी खुद की network configuration चाहिए; CLI डिफ़ॉल्ट उन रास्तों को सीमित नहीं करता।
{% endhint %}

लूपबैक के अलावा किसी और चीज़ पर bind करने का मतलब है कि अविश्वसनीय क्लाइंट सर्वर तक पहुँच सकते हैं, और इस पेज पर बताए गए डिफ़ॉल्ट इसके लिए नहीं लिखे गए हैं। इसके साथ काम करें [दूरस्थ क्लाइंट्स को अनुमति देने से पहले](#before-allowing-remote-clients) पहले।

## प्रमाणीकरण लागू करें

सेट करें `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` को अनुमत Workspace slugs पर, ताकि inference, Workflow, और integrated `/inference_pipelines/*` अनुरोधों के लिए API key आवश्यक हो। क्लाइंट कुंजी को इसमें भेज सकते हैं `Authorization: Bearer YOUR_API_KEY`को, `api_key` query parameter, या समर्थित JSON request body में; सर्वर Roboflow API के माध्यम से Workspace सदस्यता सत्यापित करता है।

उदाहरण के लिए, इसे में रखें `inference.env` फ़ाइल में जो CLI को पास की जाती है:

```dotenv
WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug
```

यदि आप कोई अलग identity system उपयोग करते हैं या Roboflow API कनेक्टिविटी के बिना प्रमाणीकरण चाहिए, तो सर्वर के सामने एक authenticated proxy रखें और क्लाइंट्स को उसे बायपास करने से रोकें।

### स्वास्थ्य और observability

Workspace जाँच छोड़ती है `/`, `/docs`, `/redoc`, `/info`, `/healthz`, `/readiness`, `/metrics`, `/openapi.json`को, static assets, और वैकल्पिक `/secure-gateway/health` endpoint को API key के बिना उपलब्ध छोड़ती है। इससे health checks और [telemetry](/deployment/hi/self-hosted/inference-server/configuration/telemetry.md)बने रहते हैं; यदि उनका output संवेदनशील हो, तो network access सीमित करें। सक्षम होने पर TLS client-certificate आवश्यकताएँ फिर भी इन endpoints पर लागू होती हैं।

## विश्वसनीय callers के लिए Custom Python उपलब्ध रखें

`ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=True` और `WORKFLOWS_CUSTOM_PYTHON_EXECUTION_MODE=local` डिफ़ॉल्ट बने रहते हैं, इसलिए स्थानीय उपयोगकर्ता opt in किए बिना Custom Python चला सकते हैं। वह कोड सर्वर process में उसकी अनुमतियों के साथ चलता है: प्रमाणीकरण नियंत्रित करता है कि उसे कौन submit कर सकता है, लेकिन किसी authenticated caller को sandbox नहीं करता। जब local Custom Python Workspace authentication के बिना सक्षम होता है, तो सर्वर security notice लॉग करता है।

### जब आवश्यकता न हो तो local execution अक्षम करें

सेट करें `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=False` स्थानीय Custom Python execution को अस्वीकार करने के लिए। Modal execution एक अलग mode है और इस flag से अक्षम नहीं होता; देखें [Custom Blocks](https://docs.roboflow.com/workflows/blocks/custom-blocks) और [offline migration guidance](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md#offline-custom-python).

## मॉडल पहुँच की सुरक्षा करें

[Model Package Security](/deployment/hi/self-hosted/inference-server/configuration/model-security.md) Workspace प्रमाणीकरण, प्रति-मॉडल authorization, और executable packages लोड करने की अनुमति के बीच अंतर करता है। विशेष रूप से, ऑनलाइन per-model authorization को सीधे स्थानीय package loading के साथ जोड़ा नहीं जा सकता क्योंकि filesystem path के पास authorize करने के लिए कोई Roboflow model identity नहीं होती।

## वीडियो workloads कॉन्फ़िगर करें

[Video Configuration](/deployment/hi/self-hosted/inference-server/configuration/video-configuration.md) managed pipeline process limit, warm workers, और server-side media references को कवर करता है। Process cap resource use को सीमित करता है; यह callers को authenticate नहीं करता या उनके code को isolate नहीं करता।

## नेटवर्क परिवहन की सुरक्षा करें

उपयोग करें [HTTPS](/deployment/hi/self-hosted/inference-server/configuration/https.md) server पर या host से आगे जाने वाले traffic के लिए authenticated TLS proxy का। Outbound [Secure Gateway](/deployment/hi/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers) connections की अपनी TLS configuration होती है, जो server के listening address से अलग है।

## इमेज फ़ेचिंग सीमित करें

कॉलर द्वारा दिया गया image URL सर्वर को internal services या metadata endpoints से संपर्क करने के लिए मजबूर कर सकता है। [स्वीकृत इनपुट फ़ॉर्मैट](/deployment/hi/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images) समझाता है कि URL input को कैसे अक्षम करें, destinations को कैसे सीमित करें, और redirect को कैसे validate करें, जबकि आपके application को आवश्यक formats बनाए रखें। ये image-fetching नियंत्रण अन्य Workflow integrations या video transports के लिए network restrictions का विकल्प नहीं हैं।

## Webhook Sink destinations सीमित करें

Webhook Sink Workflow डेटा को private networks पर सेवाओं तक भेज सकता है। Self-hosted Inference इन destinations को डिफ़ॉल्ट रूप से अनुमति देता है ताकि मौजूदा factory और LAN webhooks काम करते रहें।

सेट करें `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` जब callers को destinations चुनने पर भरोसा न हो। यह loopback, private, link-local (cloud metadata सहित), CGNAT, reserved, और multicast addresses को अस्वीकार करता है। Webhook requests hostnames को एक बार resolve करती हैं और सत्यापित address से connect करती हैं। किसी भी setting के लिए redirects और HTTP(S) proxies अस्वीकार किए जाते हैं।

## दूरस्थ क्लाइंट्स को अनुमति देने से पहले

लूपबैक के अलावा किसी और चीज़ पर bind करने का मतलब है कि अविश्वसनीय क्लाइंट सर्वर तक पहुँच सकते हैं, और इस पेज के permissive डिफ़ॉल्ट इसके लिए नहीं लिखे गए हैं। पोर्ट को expose करने से पहले, कम-से-कम:

* Bind address जानबूझकर चुनें: `inference server start` बिना `--bind-address`के, या `-p 127.0.0.1:9001:9001` के साथ `docker run`का, जब तक कि आपको remote clients की आवश्यकता न हो।
* पहुंच को ज्ञात clients तक सीमित रखें: private network या VPC पर रहें और server तक public IP के बजाय VPN, SSH tunnel, या service mesh के माध्यम से पहुँचें, और port `9001` केवल उन विशिष्ट clients से अनुमति देने के लिए host और cloud firewalls या security groups का उपयोग करें जिन्हें इसकी आवश्यकता है।
* Workspace authentication या proxy पर अपना authentication सक्षम करें। इसके बिना, जो भी port `9001` तक पहुँच सकता है, वह आपके hardware पर, आपके Roboflow account के quota पर models और Workflows चला सकता है।
* जो traffic किसी अविश्वसनीय नेटवर्क से होकर जाता है, उसके लिए TLS कॉन्फ़िगर करें।
* Custom Python और executable model packages केवल उन callers के लिए उपलब्ध रखें जिन पर आप server की permissions के साथ भरोसा करते हैं। किसी पहुँच योग्य server पर सक्षम छोड़ा जाए, तो local Custom Python किसी भी व्यक्ति के लिए remote code execution है जो Workflow भेज सकता है।
* URL image input को अक्षम करें, या इसे destination allow-list और redirect validation के साथ harden करें, जैसा कि में वर्णित है [स्वीकृत इनपुट फ़ॉर्मैट](/deployment/hi/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images).
* सेट करें `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` जब तक कि callers को trusted private या local services पर webhooks भेजने की आवश्यकता न हो।
* यदि आपको इसे अधिक व्यापक रूप से expose करना है, तो server के सामने एक reverse proxy रखें (nginx, Traefik, Caddy, या cloud load balancer); इससे TLS, rate limiting, और access logging जोड़ने के लिए एक ही स्थान मिलता है।
* सत्यापित करें कि आपके health checks और metrics collector अभी भी connect कर सकते हैं।

प्रमाणीकरण और TLS लगे बिना inference port को सीधे public internet पर कभी publish न करें।

का उपयोग करें [Production Readiness Checklist](/deployment/hi/production-checklist.md) retries, capacity, और monitoring के लिए।
