Self-Hosted Server को सुरक्षित करना
self-hosted Inference को डिफ़ॉल्ट रूप से स्थानीय रखें, चुनें कि कौन Workflows चला सकता है, और model, media, तथा transport controls कॉन्फ़िगर करें।
Self-hosted Inference स्थानीय विकास को खुला रखता है: कस्टम Python डिफ़ॉल्ट रूप से स्थानीय रूप से चलता है, और जब तक आप प्रमाणीकरण कॉन्फ़िगर नहीं करते, सर्वर को API key की आवश्यकता नहीं होती। CLI सर्वर को पर प्रकाशित करता है 127.0.0.1 डिफ़ॉल्ट रूप से, नीचे दिए गए अपवादों के साथ, इसलिए अन्य मशीनें उस प्रकाशित पोर्ट तक नहीं पहुँच सकतीं।
अपग्रेड व्यवहार और संस्करण-सीमा के लिए, देखें Security Configuration Migration.
नेटवर्क पहुँच सीमित करें
Workflow की कौन-सी सुविधाएँ वे उपयोग कर सकते हैं, यह बदलने से पहले तय करें कि क्लाइंट आपके सर्वर तक कैसे पहुँचेंगे।
CPU या GPU होस्ट पर Inference CLI
होस्ट लूपबैक, 127.0.0.1:9001
कोई दूसरा होस्ट पता चुनने के लिए --bind-address या -b का उपयोग करें।
Jetson इमेज के साथ Inference CLI
सभी होस्ट इंटरफ़ेस, 0.0.0.0:9001
केवल स्थानीय पहुँच के लिए --bind-address 127.0.0.1 का उपयोग करें।
macOS और Windows डेस्कटॉप बंडल
127.0.0.1
कोई दूसरा इंटरफ़ेस चुनने के लिए HOST को स्पष्ट रूप से सेट करें।
मैनुअल Docker या Compose
पोर्ट मैपिंग द्वारा निर्धारित
केवल स्थानीय पहुँच के लिए 127.0.0.1:9001:9001 का उपयोग करें।
--tunnel के साथ Inference CLI
CLI 0.0.0.0 पर प्रकाशित करता है ताकि टनल कनेक्ट हो सके।
LAN और टनल दोनों की पहुँच की समीक्षा करें।
CLI के साथ सर्वर शुरू करना
inference server start पर पोर्ट 9001 प्रकाशित करता है 127.0.0.1, इसलिए इस तरह शुरू किया गया सर्वर केवल उसे शुरू करने वाली मशीन के प्रक्रियाओं को जवाब देता है। यह स्थानीय विकास के लिए सही डिफ़ॉल्ट है, और यही एकमात्र कॉन्फ़िगरेशन है जिसमें इस पेज के permissive डिफ़ॉल्ट सुरक्षित हैं। गैर-लूपबैक पते पर प्रकाशित करते समय CLI चेतावनी देता है।
# डिफ़ॉल्ट: केवल इस मशीन से पहुँचा जा सकता है
inference server start
# जानबूझकर LAN पहुँच: इस होस्ट तक रूट कर सकने वाली हर मशीन से पहुँचा जा सकता है - पहले इसे सुरक्षित करें
inference server start --bind-address 0.0.0.0 --env-file inference.envNVIDIA Jetson अपवाद है। Jetson इमेजेज़ headless edge devices हैं जिन्हें लगभग हमेशा किसी दूसरी मशीन से नियंत्रित किया जाता है, इसलिए inference server start उन्हें पर प्रकाशित करता है 0.0.0.0 - डिवाइस तक रूट कर सकने वाली किसी भी चीज़ से पहुँच योग्य, जिसमें वह पूरी Wi‑Fi नेटवर्क भी शामिल है जिससे यह जुड़ा है। नीचे दिए गए नियंत्रण लागू करें, या इसे इसके साथ सीमित करें inference server start --bind-address 127.0.0.1.
के साथ सर्वर शुरू करना docker run
इमेज आपके लिए यह चयन नहीं कर सकती, इसलिए आपको इसे कमांड लाइन पर करना होगा. HOST इंटरफ़ेस चुनता है के अंदर कंटेनर, और कंटेनर का अपना network namespace होता है: एक इमेज जो शिप की गई थी HOST=127.0.0.1 कंटेनर के अपने लूपबैक से bind होती, जिसे प्रकाशित पोर्ट पहुँच नहीं सकते, और सर्वर host से भी unreachable हो जाता। यही कारण है कि हर इमेज शिप होती है HOST=0.0.0.0. Bridge-networked कंटेनर के अंदर इसे वैसे ही रखें और प्रतिबंध को इसके बजाय पोर्ट मैपिंग के host पक्ष पर लगाएँ:
दो मामलों का व्यवहार अलग होता है:
--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 नियंत्रित करें।
-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.
लूपबैक के अलावा किसी और चीज़ पर bind करने का मतलब है कि अविश्वसनीय क्लाइंट सर्वर तक पहुँच सकते हैं, और इस पेज पर बताए गए डिफ़ॉल्ट इसके लिए नहीं लिखे गए हैं। इसके साथ काम करें दूरस्थ क्लाइंट्स को अनुमति देने से पहले पहले।
प्रमाणीकरण लागू करें
सेट करें 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 को पास की जाती है:
यदि आप कोई अलग 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बने रहते हैं; यदि उनका 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 और offline migration guidance.
मॉडल पहुँच की सुरक्षा करें
Model Package Security Workspace प्रमाणीकरण, प्रति-मॉडल authorization, और executable packages लोड करने की अनुमति के बीच अंतर करता है। विशेष रूप से, ऑनलाइन per-model authorization को सीधे स्थानीय package loading के साथ जोड़ा नहीं जा सकता क्योंकि filesystem path के पास authorize करने के लिए कोई Roboflow model identity नहीं होती।
वीडियो workloads कॉन्फ़िगर करें
Video Configuration managed pipeline process limit, warm workers, और server-side media references को कवर करता है। Process cap resource use को सीमित करता है; यह callers को authenticate नहीं करता या उनके code को isolate नहीं करता।
नेटवर्क परिवहन की सुरक्षा करें
उपयोग करें HTTPS server पर या host से आगे जाने वाले traffic के लिए authenticated TLS proxy का। Outbound Secure Gateway connections की अपनी TLS configuration होती है, जो server के listening address से अलग है।
इमेज फ़ेचिंग सीमित करें
कॉलर द्वारा दिया गया image URL सर्वर को internal services या metadata endpoints से संपर्क करने के लिए मजबूर कर सकता है। स्वीकृत इनपुट फ़ॉर्मैट समझाता है कि 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 करें, जैसा कि में वर्णित है स्वीकृत इनपुट फ़ॉर्मैट.
सेट करें
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 retries, capacity, और monitoring के लिए।
अंतिम अपडेट
क्या यह उपयोगी था?