> 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 Server को सुरक्षित करना

जब आप अपने स्वयं के हार्डवेयर पर Inference चलाते हैं, **आप इसकी सुरक्षा स्थिति के मालिक होते हैं**. स्थानीय रूप से तैनात सर्वर डिफ़ॉल्ट रूप से प्रमाणीकरण, एन्क्रिप्शन, या नेटवर्क प्रतिबंध लागू नहीं करता: इसे शुरू करना आसान बनाने के लिए बनाया गया है, सुरक्षित रूप से एक्सपोज़ करने के लिए नहीं। डिफ़ॉल्ट रूप से यह अपने तक पहुँचने वाले किसी भी अनुरोध का उत्तर देता है, जिसमें मॉडल चलाने और Workflows निष्पादित करने के अनुरोध भी शामिल हैं।

यह पृष्ठ उन पाँच नियंत्रणों को कवर करता है जिनकी हर self-hosted तैनाती को स्थानीय विकास ट्रैफ़िक से आगे कुछ भी संभालने से पहले समीक्षा करनी चाहिए। ये परस्पर पूरक हैं, इसलिए जितने अधिक आपके वातावरण में संभव हों उतने लागू करें।

{% hint style="warning" %}
**यह आपकी जिम्मेदारी है।** Roboflow प्रबंधित [Serverless Hosted API](/deployment/hi/roboflow-cloud/serverless-api.md) और [Dedicated Deployment](/deployment/hi/roboflow-cloud/dedicated-deployments.md) प्रस्तावों को सुरक्षित करता है। अपने द्वारा चलाए गए सर्वर के लिए, होस्ट, उसके आसपास के नेटवर्क, और वह जिन क्रेडेंशियल्स को स्वीकार करता है, उन्हें सुरक्षित रखना आपकी जिम्मेदारी है। यदि आपका सर्वर नीचे दिए गए नियंत्रणों के बिना किसी अविश्वसनीय नेटवर्क से पहुँच योग्य है, तो उसे पूरी दुनिया के लिए खुला मानें।
{% endhint %}

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

सबसे प्रभावी एकल नियंत्रण है सर्वर को शुरू में ही एक्सपोज़ न करना। Inference डिफ़ॉल्ट रूप से पोर्ट `9001` पर सुनता है और "trusted" नेटवर्क की कोई अवधारणा नहीं है: जो भी उस पोर्ट तक पहुँच सकता है, वह इसका उपयोग कर सकता है।

* **localhost से bind करें** जब केवल उसी होस्ट पर चल रहे प्रक्रियाओं को इसकी आवश्यकता हो, उदाहरण के लिए कंटेनर पोर्ट को प्रकाशित करें `127.0.0.1:9001:9001` के बजाय `9001:9001`.
* **इसे निजी नेटवर्क या VPC पर रखें** और सार्वजनिक IP के बजाय VPN, SSH tunnel, या service mesh के माध्यम से इसे पहुँचें।
* **होस्ट और cloud firewalls या security groups का उपयोग करें** ताकि पोर्ट `9001` को केवल उन विशिष्ट clients से अनुमति दी जा सके जिन्हें इसकी आवश्यकता है।
* **इसके सामने एक reverse proxy रखें** (nginx, Traefik, Caddy, या cloud load balancer), यदि आपको इसे अधिक व्यापक रूप से एक्सपोज़ करना है। इससे आपको TLS, rate limiting, और access logging जोड़ने के लिए एक ही स्थान मिलता है।

प्रमाणीकरण और TLS के बिना inference पोर्ट को सीधे public internet पर कभी प्रकाशित न करें।

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

डिफ़ॉल्ट रूप से self-hosted सर्वर **नहीं** अनुरोध करने के लिए API key की आवश्यकता होती है। प्लेटफ़ॉर्म से डेटा फ़ेच करते समय Roboflow API स्तर पर होने वाले प्रमाणीकरण से आगे, सर्वर स्वयं पर कोई अतिरिक्त सुरक्षा नहीं होती। प्रमाणीकरण चालू करने के लिए, सेट करें `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` को Roboflow workspace slugs की comma-separated सूची पर सेट करें जिन्हें सर्वर का उपयोग करने की अनुमति है:

```bash
docker run --rm -p 9001:9001 \
  -e WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug,another-workspace-url-slug \
  roboflow/roboflow-inference-server-cpu:latest
```

इसे सेट करने पर, सर्वर एक authorization middleware स्थापित करता है। हर inference और Workflow अनुरोध के साथ एक `api_key` आना चाहिए (query parameter के रूप में या JSON body में), जो Roboflow के माध्यम से whitelisted workspaces में से किसी एक से मैप होता हो। गायब, अमान्य, या गैर-whitelisted key वाले अनुरोध `401 Unauthorized`.

{% hint style="info" %}
**API-key जाँच द्वारा क्या कवर नहीं किया गया है।** अनप्रमाणित endpoints का एक छोटा समूह खुला रहता है ताकि सर्वर उपयोगी और निरीक्षण योग्य बना रहे: `/`, `/docs`, `/redoc`, `/info`, `/healthz`, `/readiness`, `/metrics`, `/openapi.json` , और static assets (`/static/...`, `/_next/...`)। `/info` और `/metrics` को ऐसी जानकारी समझें जिसे सर्वर तक पहुँचने वाला कोई भी व्यक्ति पढ़ सकता है, और यह सीमित करने के लिए नेटवर्क प्रतिबंधों (control 1) पर निर्भर रहें कि वह कौन है।
{% endhint %}

**अपना auth साथ लाएँ।** बिल्ट-इन जाँच authorization को Roboflow workspaces से जोड़ती है। यदि आपका अपना identity model है, तो सर्वर के सामने एक reverse proxy या authentication middleware रखें, जो OAuth/OIDC, mTLS, signed headers, API gateway, या जो भी आपका संगठन पहले से उपयोग करता है, उसे लागू करे, और केवल authenticated ट्रैफ़िक को पोर्ट `9001` तक जाने दें। दोनों तरीकों को साथ में इस्तेमाल किया जा सकता है।

## 3. जब नेटवर्क इसकी मांग करे तब TLS सक्षम करें

बिल्ट-इन API-key जाँच credentials को अनुरोध में भेजती है। यदि वे अनुरोध किसी ऐसे नेटवर्क से होकर जाते हैं जिसे आप पूरी तरह नियंत्रित नहीं करते, तो कनेक्शन को एन्क्रिप्ट होना चाहिए, अन्यथा keys और payloads plaintext में उजागर हो जाते हैं।

आपके पास दो विकल्प हैं:

* **reverse proxy या load balancer पर TLS समाप्त करें** सर्वर के सामने। यदि आप पहले से एक चला रहे हैं, तो यह सामान्य विकल्प है।
* **सर्वर से सीधे HTTPS सेवा दें** एक certificate और key माउंट करके और सेट करके `ENABLE_HTTPS=true`. देखें [Serving Inference over HTTPS](/deployment/hi/self-hosted/inference-server/configuration/https.md) पूर्ण मार्गदर्शिका के लिए, जिसमें mutual TLS (client certificates) भी शामिल है `SSL_CA_CERTS`.

पूरी तरह स्थानीय, केवल loopback ट्रैफ़िक के लिए (control 1, bound to `127.0.0.1`), TLS वैकल्पिक है। जब भी अनुरोध होस्ट छोड़कर किसी अविश्वसनीय नेटवर्क पर जाते हैं, TLS आवश्यक है।

## 4. Workflows में custom Python execution अक्षम करें

Workflows में शामिल हो सकते हैं **Custom Python blocks**: मनमाना Python जो सर्वर प्रक्रिया के भीतर चलता है। यह एक शक्तिशाली सुविधा है, लेकिन इसका मतलब है कि जो भी सर्वर को Workflow सबमिट कर सकता है, वह आपके होस्ट पर मनमाना code चला सकता है। अविश्वसनीय clients द्वारा पहुँच योग्य सर्वर पर, यह remote code execution है।

इसे नियंत्रित करता है `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS`.

| सेटिंग                   | प्रभाव                                                                                         |
| ------------------------ | ---------------------------------------------------------------------------------------------- |
| `True` (वर्तमान default) | Workflows custom Python blocks परिभाषित और चला सकते हैं।                                       |
| `False`                  | Custom Python blocks अस्वीकृत कर दिए जाते हैं; अन्य सभी Workflow सुविधाएँ फिर भी काम करती हैं। |

यदि आपके Workflows custom Python पर निर्भर नहीं हैं, तो इसे सेट करें `False`:

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=false \
  roboflow/roboflow-inference-server-cpu:latest
```

{% hint style="warning" %}
**डिफ़ॉल्ट 2026-06-19 को बदल रहा है।** आज इस flag का default है `True` backward compatibility के लिए। 2026-06-19 को default बदलकर `False`हो जाएगा। यदि आपके Workflows custom Python blocks पर निर्भर हैं, तो सेट करें `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=true` इसे स्पष्ट रूप से ताकि उस तारीख के बाद भी वे काम करते रहें। अन्यथा इसे disabled ही रहने दें, और इसे केवल उन deployments पर सक्षम करना बेहतर है जहाँ ऊपर दिए गए नेटवर्क और authentication नियंत्रण पहले से मौजूद हों।
{% endhint %}

## 5. URLs से image fetching सीमित करें (SSRF)

Inference अनुरोध में दिए गए URL से सीधे images लोड कर सकता है (`{"image": {"type": "url", "value": "https://..."}}`)। जब भी कोई सर्वर किसी ऐसे URL को fetch करता है जिसे caller नियंत्रित करता है, तो caller उसे अपने behalf पर requests करने के लिए मोड़ने की कोशिश कर सकता है, जिसे **server-side request forgery (SSRF)**&#x915;हा जाता है। जो व्यक्ति आपके internal network तक सीधे नहीं पहुँच सकता, वह आपके सर्वर से उदाहरण के लिए यह fetch करने को कह सकता है:

* `http://169.254.169.254/latest/meta-data/`जो cloud metadata service (AWS, GCP, Azure) है, और instance credentials वापस दे सकती है।
* `http://127.0.0.1:9001/...` और अन्य localhost सेवाएँ: admin panels, databases, या Inference server के अपने अनप्रमाणित endpoints।
* `http://10.0.0.5/`, `http://192.168.1.1/` , और अन्य private (RFC1918), link-local, CGNAT, या IPv6 ULA hosts जो आपके perimeter के पीछे हैं।

Public जैसा दिखने वाला hostname public target का प्रमाण नहीं है: वह private IP पर resolve हो सकता है, उसी पर redirect हो सकता है, या **DNS rebinding** का उपयोग कर सकता है (validation check के लिए public IP पर resolve करें, फिर वास्तविक connection के लिए private IP पर)। Inference इनमें से सभी के लिए controls प्रदान करता है।

### यदि आपको इसकी आवश्यकता नहीं है, तो URL input बंद करें

सबसे मजबूत नियंत्रण है URL images को बिल्कुल स्वीकार ही न करना। यदि आपके clients हमेशा images को base64 या file uploads के रूप में भेजते हैं, तो URL fetching को पूरी तरह अक्षम कर दें:

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_INPUT=false \
  roboflow/roboflow-inference-server-cpu:latest
```

### जब आपको इसकी आवश्यकता हो तो URL input को मजबूत करें

जब URL images आवश्यक हों, तो ये flags server को क्या fetch करने की अनुमति है, इसे सीमित करते हैं। साथ मिलकर ये internal targets को अस्वीकृत करते हैं, **connection को validated IP पर pin करते हैं** (DNS rebinding को निष्प्रभावी करते हुए), और हर redirect hop को फिर से जाँचते हैं।

| चर                                       | डिफ़ॉल्ट | प्रभाव                                                                                                                                                                                                                                                            |
| ---------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ALLOW_URL_INPUT`                        | `True`   | URL image input के लिए master switch। `False` सभी URL images को अस्वीकृत करता है।                                                                                                                                                                                 |
| `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES`      | `True`   | जब `False`सक्रिय हो, तो ऐसा URL जिसका host non-global address पर resolve होता है (loopback, private, link-local/metadata, CGNAT, IPv6 ULA, आदि) अस्वीकृत हो जाता है, और connection को validated IP पर pin किया जाता है ताकि दूसरा DNS answer target को बदल न सके। |
| `VALIDATE_IMAGE_URL_REDIRECTS`           | `False`  | जब `True`सक्रिय होने पर, redirects को एक-एक hop करके follow किया जाता है और हर hop URL को फिर से validate किया जाता है, बजाय इसके कि उन्हें blindly follow किया जाए।                                                                                              |
| `MAX_IMAGE_URL_REDIRECTS`                | `30`     | redirect hops पर कठोर सीमा, ऊपर वाले flag की परवाह किए बिना लागू।                                                                                                                                                                                                 |
| `ALLOW_NON_HTTPS_URL_INPUT`              | `False`  | जब `False`, केवल `https://` URLs स्वीकार किए जाते हैं।                                                                                                                                                                                                            |
| `ALLOW_URL_INPUT_WITHOUT_FQDN`           | `False`  | जब `False`, ऐसे URLs जिनका host केवल एक bare IP है या जिनका कोई public suffix नहीं है, अस्वीकृत कर दिए जाते हैं, इसलिए callers को वास्तविक domain name का उपयोग करना होगा।                                                                                        |
| `WHITELISTED_DESTINATIONS_FOR_URL_INPUT` | unset    | Comma-separated allow-list of destinations (`subdomain.domain.suffix`)। जब सेट किया जाता है, तो केवल इन्हीं की अनुमति होती है।                                                                                                                                    |
| `BLACKLISTED_DESTINATIONS_FOR_URL_INPUT` | unset    | गंतव्यों की comma-separated block-list जिन्हें हमेशा अस्वीकृत किया जाता है।                                                                                                                                                                                       |

एक hardened configuration जो फिर भी public HTTPS image URLs की अनुमति देती है:

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false \
  -e VALIDATE_IMAGE_URL_REDIRECTS=true \
  roboflow/roboflow-inference-server-cpu:latest
```

सबसे कड़े नियंत्रण के लिए, एक allow-list जोड़ें ताकि server केवल उन exact hosts तक पहुँच सके जिनसे आप images serve करते हैं:

```bash
docker run --rm -p 9001:9001 \
  -e ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false \
  -e VALIDATE_IMAGE_URL_REDIRECTS=true \
  -e WHITELISTED_DESTINATIONS_FOR_URL_INPUT=images.example.com,cdn.example.com \
  roboflow/roboflow-inference-server-cpu:latest
```

{% hint style="warning" %}
**Q4 2026 में दो defaults बदल रहे हैं।** `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES` ( `False`को `VALIDATE_IMAGE_URL_REDIRECTS` ( `True`) और
{% endhint %}

{% hint style="info" %}
**Proxy इस सुरक्षा को बायपास कर देते हैं।** यदि server के लिए HTTP(S) proxy कॉन्फ़िगर किया गया है, तो proxy (Inference नहीं) destination resolve करता है, इसलिए non-global blocking और connection pinning लागू नहीं किए जा सकते। जब यह पता चलता है, तो server एक warning जारी करता है। यदि आप इन controls पर निर्भर हैं, तो proxy स्वयं क्या पहुँच सकता है, इसे सीमित करें।
{% endhint %}

{% hint style="info" %}
**Python SDK में वही controls।** The `inference-sdk` client URL से images लोड करते समय वही URL policy और SSRF protections लागू करता है, और वही environment variables पढ़ता है, इसलिए जो client भेजने से पहले URL images को hydrate करता है, वह भी कवर होता है।
{% endhint %}

## अनुशंसित आधाररेखा

किसी भी self-hosted server के लिए जो इससे आगे पहुँच योग्य हो `localhost`:

* नेटवर्क पहुँच को ज्ञात clients तक सीमित किया गया है (firewall, private network, या proxy)।
* `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` सेट किया गया, या सामने आपका अपना auth।
* TLS server या upstream proxy पर समाप्त किया गया है।
* `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=false` जब तक आपको वास्तव में इसकी आवश्यकता न हो।
* URL image input अक्षम (`ALLOW_URL_INPUT=false`) , या साथ में harden किया गया `ALLOW_URL_TO_NON_GLOBAL_ADDRESSES=false` और `VALIDATE_IMAGE_URL_REDIRECTS=true`, और जहाँ संभव हो एक allow-list।

यह भी देखें [Accepted Input Formats](/deployment/hi/self-hosted/inference-server/configuration/input-formats.md) pickled-numpy input control के लिए, और [Production Readiness Checklist](/deployment/hi/production-checklist.md) error handling और rate limits के लिए।
