निजी दूरस्थ परिनियोजन

इस व्यवस्था में Libre WebUI, Ollama और Cloudflare Tunnel एक ही Docker होस्ट पर चलते हैं और अनुप्रयोग या Ollama के पोर्ट सार्वजनिक नहीं किए जाते। Cloudflare Access बाहरी पहचान-सीमा है, जबकि Libre WebUI का प्रमाणीकरण आंतरिक सीमा बना रहता है। Work और Watchtower अलग-अलग, वैकल्पिक सुविधाएँ हैं जिन्हें सक्षम करने पर root के बराबर अधिकार मिलते हैं।

यह साँचा एकल-प्रतिकृति solo टोपोलॉजी के लिए है: SQLite, स्थानीय रूप से कूटबद्ध बाइनरी ऑब्जेक्ट, अंतर्निहित वेक्टर, स्थानीय समन्वय और अंतर्निहित कार्य-प्रक्रमक, सभी अनुप्रयोग के डेटा वॉल्यूम का साझा उपयोग करते हैं। .env में बैकएंड चयनकर्ता बदलकर इसे team परिनियोजन में न बदलें। team परिनियोजन के लिए रिपॉज़िटरी की docker-compose.team.yml फ़ाइल (और Work सक्षम होने पर docker-compose.team.work.yml) का उपयोग करना अनिवार्य है। ये फ़ाइलें PostgreSQL/PGVector, संस्करणयुक्त S3 भंडारण, Redis, बाहरी वर्कर और गेटवे को एक समन्वित टोपोलॉजी के रूप में उपलब्ध कराती हैं।

आरंभिक आधार के रूप में deploy/private/docker-compose.yml का उपयोग करें। इसकी डिफ़ॉल्ट इमेज main है:

LIBRE_WEBUI_IMAGE=ghcr.io/libre-webui/libre-webui:main

dev टैग केवल उस इंस्टेंस के लिए उपयुक्त है जिसे स्पष्ट रूप से विकास हेतु चुना गया हो; यह सामान्य क्लाइंट परिनियोजन के लिए नहीं है।

सुरक्षा मॉडल

• Cloudflare Access /api/* और WebSocket अपग्रेड सहित पूरे होस्टनाम की सुरक्षा करता है। कोई सार्वजनिक बाइपास पथ न जोड़ें।
• अनुप्रयोग के API का उपयोग करने के लिए मान्य Libre WebUI खाता आवश्यक है। मॉडल जीवनचक्र और Work संचालन के लिए डेटाबेस में वर्तमान भूमिका का व्यवस्थापक होना आवश्यक है।
• अनुप्रयोग, Ollama, SearXNG और cloudflared केवल निजी Compose नेटवर्क का उपयोग करते हैं। होस्ट अनुप्रयोग का कोई पोर्ट सार्वजनिक नहीं करता।
• साथ दी गई SearXNG सेवा वैकल्पिक वेब खोज उपलब्ध कराती है। यह केवल आंतरिक नेटवर्क से उपलब्ध रहती है और जब तक कोई व्यवस्थापक Settings > Search में खोज सक्षम नहीं करता, निष्क्रिय रहती है; स्टैक शुरू करने से पहले .env में SEARXNG_SECRET निर्धारित करें।
• अनुप्रयोग गैर-root उपयोगकर्ता के रूप में, केवल-पढ़ने योग्य मूल फ़ाइल सिस्टम, बिना किसी Linux क्षमता, no-new-privileges तथा CPU, मेमोरी और PID सीमाओं के साथ चलता है।
• Work तब तक अक्षम रहता है जब तक उसकी किसी ओवरराइड फ़ाइल को शामिल न किया जाए। सक्षम होने पर उसके कंटेनरों को अपना केवल-पढ़ने योग्य मूल फ़ाइल सिस्टम, हटाई गई Linux क्षमताएँ, संसाधन सीमाएँ, कार्यक्षेत्र वॉल्यूम और डिफ़ॉल्ट रूप से अस्वीकार करने वाली नेटवर्क नीति मिलती है।

मूल स्टैक किसी Docker सॉकेट को माउंट नहीं करता। docker-compose.work-proxy.yml के साथ Work सक्षम करने पर भी यही व्यवस्था बनी रहती है: आंतरिक नेटवर्क पर एक सॉकेट प्रॉक्सी सॉकेट को माउंट करती है और केवल उन्हीं API अनुभागों (containers, images, volumes, networks, exec, info) को आगे भेजती है जिनका Work उपयोग करता है। swarm, secrets, build और system एंडपॉइंट प्रॉक्सी पर अस्वीकार किए जाते हैं, इसलिए अनुप्रयोग को न तो सॉकेट माउंट करना पड़ता है, न उसके समूह का सदस्य बनना पड़ता है। प्रॉक्सी Docker API की उपलब्ध सतह को सीमित करती है, लेकिन आगे भेजे गए संचालन से होने वाली क्षति का दायरा नहीं घटाती—कंटेनर बना सकने वाली प्रक्रिया अब भी होस्ट के पथों को माउंट कर सकती है। इसलिए इसे वास्तविक सुरक्षा-सुदृढ़ीकरण परत समझें, बहु-किरायेदार पृथक्करण नहीं।

सीधे सॉकेट वाले विकल्प सबसे बड़ी विश्वास-सीमा बने रहते हैं: docker-compose.work.yml और Watchtower ओवरराइड कंटेनर को ऐसी प्रक्रिया देते हैं जो मनचाहे Docker API अनुरोध भेज सकती है और होस्ट को नियंत्रित कर सकती है। सॉकेट को केवल-पढ़ने योग्य रूप में माउंट करने से Docker API की पहुँच केवल-पढ़ने योग्य नहीं हो जाती। एकीकृत बैकअप सहायक सीधे Docker सॉकेट को प्राप्त करने से इनकार करता है; निर्धारित एकीकृत बैकअप पर भरोसा करने से पहले Work को फ़िल्टर की गई प्रॉक्सी पर स्थानांतरित करें।

प्रारंभिक सेटअप

1. sudo अधिकार वाला गैर-root संचालक बनाएँ और root के SSH प्रवेश को अक्षम करने से पहले कुंजी-आधारित SSH प्रवेश की पुष्टि करें।
2. deploy/private/.env.example को /opt/libre-webui/.env पर कॉपी करें, मोड 0600 निर्धारित करें, अद्वितीय रहस्य बनाएँ और होस्ट के लिए BLOB_QUOTA_BYTES_PER_USER का उचित आकार चुनें। BLOB_QUOTA_RESERVATION_TTL_MS छोड़े गए अपलोड आरक्षणों को समाप्त करता है; इसका डिफ़ॉल्ट एक घंटा है।
3. यदि Work सक्षम किया जाएगा, तो DOCKER_GID को उस समूह की संख्यात्मक ID पर निर्धारित करें जिसके स्वामित्व में /var/run/docker.sock है।
4. Cloudflare Tunnel टोकन को /opt/libre-webui/secrets/tunnel-token में मोड 0640 या उससे अधिक प्रतिबंधित मोड के साथ रखें।
5. पूरे होस्टनाम के लिए Cloudflare Access में स्वयं-होस्ट किया गया अनुप्रयोग बनाएँ, 24 घंटे का सत्र रखें और केवल अपेक्षित पहचानों को अनुमति दें। Tunnel रूट पर Protect with Access सक्षम करें। यदि निगरानी के लिए सार्वजनिक स्वास्थ्य-जाँच आवश्यक हो, तो केवल /health/live के लिए पथ-सीमित अलग अनुप्रयोग या नीति बनाएँ। मुख्य अनुप्रयोग में कभी भी व्यापक Bypass नीति न जोड़ें: मेल खाने वाली Bypass नीति उसकी Allow नीति को निष्प्रभावी कर देती है।
6. ENABLE_SIGNUP=false रहने दें। Access की अनुमति-सूची होस्टनाम की सुरक्षा करने लगे, उसके बाद पहला स्थानीय व्यवस्थापक बनाएँ; खाली डेटाबेस उस एक प्रारंभिक खाते को स्वतः स्वीकार करता है। बाद में पंजीकरण केवल जानबूझकर निर्धारित की गई छोटी अवधि के लिए सक्षम करें।
7. Turnstile के होस्टनाम प्रतिबंधों को विन्यस्त करें और TURNSTILE_EXPECTED_HOSTNAME को ठीक उसी सार्वजनिक होस्टनाम पर निर्धारित करें।

स्टैक शुरू करें और उसकी पुष्टि करें:

cd /opt/libre-webui
docker compose config --quiet
docker compose up -d
docker compose ps

Work सक्षम करने के लिए सॉकेट-प्रॉक्सी ओवरराइड को स्पष्ट रूप से शामिल करें:

docker compose -f docker-compose.yml -f docker-compose.work-proxy.yml up -d

सीधे सॉकेट वाला विकल्प (docker-compose.work.yml) इसकी आवश्यकता वाले परिनियोजनों के लिए उपलब्ध है; उस पर ऊपर बताए गए विश्वास-संबंधी परिणाम लागू होते हैं।

Access सक्रिय होने के बाद, यदि ठीक उसी पथ पर सीमित बाइपास न हो तो कमांड-पंक्ति की प्रारंभिक जाँचों के लिए Cloudflare Access सेवा टोकन आवश्यक है। क्रेडेंशियल को शेल इतिहास से बाहर रखें और दोनों हेडर भेजें:

curl --fail --silent --show-error \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
  https://your-hostname.example/api/auth/system-info

सुरक्षित अनुप्रयोग API को भेजे गए अप्रमाणित अनुरोध का उत्तर 401 होना चाहिए:

curl --output /dev/null --write-out '%{http_code}\n' \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
  https://your-hostname.example/api/work/tasks

होस्ट की सुरक्षा सुदृढ़ करना

इस निर्देशिका में sshd का एक अतिरिक्त विन्यास और fail2ban जेल शामिल है। इसे लागू करने से पहले किसी दूसरे टर्मिनल में sudo अधिकार वाले गैर-root संचालक का अलग सत्र जाँचें। SSH को पुनः लोड करने से पहले sshd -t से विन्यास की पुष्टि करें।

UFW या समकक्ष फ़ायरवॉल को इस तरह विन्यस्त करें कि वह आने वाला ट्रैफ़िक डिफ़ॉल्ट रूप से अस्वीकार करे और केवल दर-सीमित SSH की अनुमति दे। इस साँचे में Docker किसी सेवा पोर्ट को सार्वजनिक नहीं करता:

ufw default deny incoming
ufw default allow outgoing
ufw limit OpenSSH
ufw enable

स्वचालित सुरक्षा अपडेट सक्षम रखें। जब तक परिनियोजन के लिए कोई प्रलेखित आवश्यकता न हो, X11, agent और TCP अग्रेषण अक्षम रखें।

बैकअप और पुनर्प्राप्ति

बैकअप लेने से पहले चल रहे परिनियोजन कंटेनर के भीतर केवल-पढ़ने योग्य पुनर्प्राप्ति सूची चलाएँ। इससे ठीक उसी परिनियोजित अनुप्रयोग संस्करण, परिवेश और माउंट किए गए डेटा वॉल्यूम की जाँच होती है। होस्ट की कार्यशील प्रति से चलाया गया आदेश गलत डेटाबेस की जाँच कर सकता है या परिनियोजित इमेज से भिन्न स्रोत चला सकता है।

docker exec libre-webui \
  libre-webui recovery-check --json --data-dir /app/backend/data

निकास स्थिति 0 का अर्थ है कि पुनर्प्राप्ति-तत्परता रोकने वाली कोई समस्या नहीं मिली, 1 का अर्थ है कि JSON रिपोर्ट में अवरोधक हैं और 2 का अर्थ है कि आदेश चल नहीं सका। रिपोर्ट में केवल कूटलेखन-कुंजी का फ़िंगरप्रिंट और रहस्यों की उपलब्धता के संकेत होते हैं; यह कभी भी कुंजी या किसी अन्य रहस्य का मान नहीं दिखाती। पुनर्स्थापना से पहले अनुप्रयोग संस्करण, स्कीमा फ़िंगरप्रिंट, अपेक्षित Work संसाधन और बहिष्करणों की तुलना की जा सके, इसके लिए सूची को संबंधित बैकअप के साथ रखें।

ठीक उसी परिनियोजित इमेज से बैकअप के लिए अलग कूटलेखन और हस्ताक्षर कुंजियाँ बनाएँ। इस निर्देशिका को अनुप्रयोग वॉल्यूम से बाहर रखें और कूटलेखन कुंजी तथा निजी हस्ताक्षर कुंजी को किसी अलग, सुरक्षित पुनर्प्राप्ति स्थान पर कॉपी करें:

install -d -m 0700 /etc/libre-webui/backup-keys
image_ref=$(docker inspect libre-webui --format '{{.Image}}')
docker run --rm --user 0:0 --read-only --network none --cap-drop ALL \
  --security-opt no-new-privileges \
  --mount type=bind,src=/etc/libre-webui/backup-keys,dst=/backup-keys \
  --entrypoint /usr/local/bin/libre-webui "$image_ref" \
  backup keygen \
  --directory /backup-keys

कुंजी निर्माण पहले से मौजूद आउटपुट फ़ाइलों के ऊपर लिखने से इनकार करता है। किसी मौजूदा बैकअप समूह के लिए कभी नई कुंजियाँ न बनाएँ: संग्रह की कूटलेखन कुंजी या हस्ताक्षर पहचान खोने पर उससे संबंधित पुनर्प्राप्ति प्रमाण अनुपयोगी हो जाता है।

साथ दी गई बैकअप और पुनर्स्थापना स्क्रिप्ट तथा systemd इकाइयाँ स्थापित करें, फिर टाइमर सक्षम करें:

install -d -m 0700 /var/backups/libre-webui
install -m 0750 deploy/private/libre-webui-backup \
  /usr/local/sbin/libre-webui-backup
install -m 0750 deploy/private/libre-webui-restore \
  /usr/local/sbin/libre-webui-restore
install -m 0644 deploy/private/libre-webui-backup.{service,timer} \
  /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now libre-webui-backup.timer

इकाई वैकल्पिक रूप से केवल रखरखाव के लिए /etc/libre-webui/backup.env से ओवरराइड पढ़ती है; वह अनुप्रयोग की .env फ़ाइल लोड नहीं करती। इस फ़ाइल को root के रूप में केवल तभी बनाएँ जब किसी ओवरराइड की आवश्यकता हो:

install -d -m 0750 /etc/libre-webui
install -m 0600 /dev/null /etc/libre-webui/backup.env

यहाँ LIBRE_WEBUI_STACK_DIR, LIBRE_WEBUI_BACKUP_RETENTION_DAYS, LIBRE_WEBUI_CONTAINER_NAME और LIBRE_WEBUI_BACKUP_KEY_DIR को सीधे निर्धारित किया जा सकता है। फ़ाइल का स्वामी root और मोड 0600 ही रखें। कस्टम कुंजी निर्देशिका systemd के सुरक्षित परिवेश के भीतर root द्वारा पढ़ी जा सकनी चाहिए।

LIBRE_WEBUI_BACKUP_DIR बदलने से systemd की लिखने योग्य सीमा भी बदलती है। सेवा शुरू होने से पहले निर्देशिका मौजूद होनी चाहिए और इकाई में उससे मेल खाने वाला अतिरिक्त नियम होना चाहिए। उदाहरण के लिए, backup.env में LIBRE_WEBUI_BACKUP_DIR=/srv/backups/libre-webui निर्धारित करने के बाद:

install -d -m 0700 /srv/backups/libre-webui
systemctl edit libre-webui-backup.service

संपादक में यही सटीक पथ जोड़ें, फिर इकाई पुनः लोड करें:

[Service]
ReadWritePaths=/srv/backups/libre-webui

systemctl daemon-reload
systemctl start libre-webui-backup.service

मेल खाती ReadWritePaths= प्रविष्टि के बिना ProtectSystem=strict टाइमर को कस्टम स्थान पर लिखने से उचित रूप से रोकता है।

बड़ी संग्रह फ़ाइलों के लिए बैकअप सेवा अधिकतम छह घंटे देती है। सहायक होस्ट लॉक प्राप्त करता है, अनुप्रयोग को केवल तभी रोकता है जब वह पहले से चल रहा हो, और निष्क्रिय वॉल्यूम का संग्रह ठीक उसी परिनियोजित इमेज से बनाता है। संग्रह में हस्ताक्षरित घोषणापत्र और संचालक द्वारा कूटबद्ध पेलोड होता है; इसमें डेटा निर्देशिका के साथ वह रनटाइम और रहस्य-विन्यास शामिल होता है जो उस अवस्था को खोलने के लिए आवश्यक है। इसके बाद सहायक पूरे संग्रह का स्वतंत्र सत्यापन करता है और उसकी मेटाडेटा रिपोर्ट को परमाणु रूप से प्रकाशित करता है। उसके केवल-पढ़ने योग्य फ़ाइल सिस्टम वाले रखरखाव कंटेनरों को SQLite निरीक्षण और प्रमाणीकृत संग्रह सत्यापन के लिए निजी, लिखने योग्य /tmp tmpfs मिलता है; कंटेनर परत में कोई अस्थायी सादा पाठ स्थायी नहीं किया जाता। दोनों फ़ाइलों और अलग से सुरक्षित पुनर्प्राप्ति कुंजियों को होस्ट से बाहर कॉपी करें।

जब Work docker-compose.work-proxy.yml का उपयोग करता है, तब पुनर्प्राप्ति में डेटाबेस द्वारा संदर्भित हर Work वॉल्यूम के अब भी मौजूद होने का प्रमाण भी देना होता है। सहायक परिनियोजित अनुप्रयोग का DOCKER_HOST पढ़ता है, उसी चल रहे Compose प्रोजेक्ट में socket-proxy सेवा ढूँढ़ता है और वास्तविक Docker नेटवर्क संलग्नकों से उनका एक साझा आंतरिक नेटवर्क पहचानता है। Compose उस नेटवर्क के नाम के आगे प्रोजेक्ट का नाम लगाता है, इसलिए किसी अनुमानित नेटवर्क नाम को विन्यस्त या स्थायी रूप से निर्धारित न करें। केवल संग्रह बनाने वाला कंटेनर उस आंतरिक नेटवर्क में जुड़ता है और फ़िल्टर की गई प्रॉक्सी तक पहुँच सकता है; उसे सीधे सॉकेट की पहुँच नहीं मिलती। संग्रह का स्वतंत्र सत्यापन --network none के साथ जारी रहता है। प्रॉक्सी न मिलना, अनपेक्षित एंडपॉइंट, बाहरी या अस्पष्ट साझा नेटवर्क अथवा सीधा सॉकेट माउंट—इनमें से कोई भी स्थिति अनुप्रयोग को रोकने और संग्रह प्रकाशित करने से पहले ही प्रक्रिया को विफल कर देती है।

चालू वॉल्यूम को बदले बिना किसी नए वॉल्यूम में पुनर्प्राप्ति का अभ्यास करें:

LIBRE_WEBUI_RESTORE_IMAGE="$image_ref" \
  libre-webui-restore \
  /var/backups/libre-webui/libre-webui-integrated-YYYYMMDDTHHMMSSZ.lwb \
  libre-webui-restore-drill

पुनर्स्थापना सहायक किसी मौजूदा वॉल्यूम या विन्यास लक्ष्य का उपयोग करने से इनकार करता है। वह अस्थायी भंडारण में संग्रह और उसकी आंतरिक पुनर्प्राप्ति सूची की पुष्टि करता है, फिर डेटा को नए वॉल्यूम में कॉपी करता है और पुनर्प्राप्त runtime.json तथा secrets.json को निजी अनुमतियों के साथ लिखता है। वह चालू स्टैक की वायरिंग कभी नहीं बदलता और न उसे शुरू करता है। पुनर्प्राप्त विन्यास की समीक्षा करें, परिनियोजन-विशिष्ट मान सोच-समझकर बदलें और पुनर्स्थापित वॉल्यूम को पृथक स्टैक में जाँचें।

Ollama मॉडल दोबारा डाउनलोड किए जा सकते हैं। Docker Work वॉल्यूम, Kubernetes Work PVC और होस्ट से बँधी Work निर्देशिकाएँ अनुप्रयोग की डेटा निर्देशिका के बाहर होती हैं; इनके लिए अपने समन्वित स्नैपशॉट और प्रतिधारण नीति आवश्यक हैं।

अपडेट

इमेज टैग बदल सकने वाला हो, तब भी Libre WebUI अवस्थापूर्ण रहता है। मूल Compose फ़ाइल अनुप्रयोग को Watchtower से स्थायी रूप से बाहर चिह्नित करती है। इसे केवल संचालक की समन्वित कार्रवाई के रूप में अपडेट करें:

1. चल रही इमेज की ID दर्ज करें और समीक्षित प्रतिस्थापन का अपरिवर्तनीय डाइजेस्ट प्राप्त करें।
2. libre-webui recovery-check चलाएँ, बैकअप सेवा शुरू करें और आगे बढ़ने से पहले नया संग्रह तथा सत्यापन रिपोर्ट बनना अनिवार्य करें।
3. LIBRE_WEBUI_IMAGE को समीक्षित डाइजेस्ट पर निर्धारित करें, इमेज डाउनलोड करें और Docker Compose से केवल libre-webui सेवा को फिर बनाएँ। उसका डेटा वॉल्यूम न हटाएँ और न दोबारा बनाएँ।
4. /health/ready, प्रवेश, सत्र/इतिहास, दस्तावेज़ प्राप्ति और Work की प्रारंभिक जाँचों का सफल होना अनिवार्य करें। वे विफल हों तो दर्ज किए गए इमेज डाइजेस्ट पर वापस जाएँ; निदान के लिए विफल अवस्था और सत्यापित बैकअप, दोनों सुरक्षित रखें।

होस्ट पर यह क्रम जानबूझकर हाथ से चलाया जाता है। डाइजेस्ट को समीक्षा के बाद ही बदलें और इमेज डाउनलोड करने से पहले नवीनतम .lwb तथा .json जोड़ी की जाँच करें:

docker inspect libre-webui --format '{{.Config.Image}} {{.Image}}'
docker exec libre-webui \
  libre-webui recovery-check --json --data-dir /app/backend/data
systemctl start libre-webui-backup.service
systemctl --no-pager --full status libre-webui-backup.service
ls -lt /var/backups/libre-webui/libre-webui-integrated-* | head

# Set LIBRE_WEBUI_IMAGE=ghcr.io/libre-webui/libre-webui@sha256:REVIEWED_DIGEST
# in the root-owned .env, then recreate only the application.
docker compose pull libre-webui
docker compose up -d --no-deps libre-webui
docker inspect libre-webui --format '{{.State.Health.Status}} {{.Image}}'

सॉकेट वाला वैकल्पिक Watchtower ओवरराइड केवल उन सहायक कंटेनरों के लिए उपलब्ध है जिन्हें मूल फ़ाइल में स्पष्ट रूप से चिह्नित किया गया है:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.watchtower.yml \
  up -d

Watchtower हर 30 मिनट में Ollama और SearXNG की जाँच करता है। Ollama का मॉडल डेटा उसके नामित वॉल्यूम में और SearXNG का विन्यास होस्ट से बँधे माउंट में बना रहता है। Watchtower Libre WebUI, cloudflared, Work सॉकेट प्रॉक्सी या Work सुरक्षित परिवेशों को अपडेट नहीं करता। क्लाइंट परिनियोजन main का अनुसरण करता है; कोई प्रयोगात्मक इंस्टेंस :dev चुन सकता है, लेकिन अनुप्रयोग को फिर भी बैकअप द्वारा नियंत्रित वही मैन्युअल अपडेट चाहिए। इस निजी solo स्टैक को कभी भी team की स्थायी सेवाओं से न जोड़ें; इसके बजाय पूरी team टोपोलॉजी परिनियोजित करें।