बेहतरीन self-hosted diagram tools की तुलना

आपको कौन सा self-hosted diagram tool चलाना चाहिए?

Self-hosted diagram tools दो प्रकार के होते हैं, और उनका प्रकार उनकी feature list से अधिक महत्वपूर्ण है। draw.io और Excalidraw ब्राउज़र आधारित applications हैं: container केवल JavaScript प्रदान करता है, आपका ब्राउज़र ड्राइंग का काम करता है, और सर्वर कभी भी diagram को नहीं देखता है। Kroki इसके विपरीत काम करता है। आप HTTP के माध्यम से इसे diagram का text भेजते हैं और यह वापस एक image भेजता है, इसलिए हर diagram आपके अपने सर्वर से होकर गुजरता है।

यदि आप wiki के साथ एक पूर्ण editor चाहते हैं, तो draw.io चलाएं। यदि आप एक त्वरित sketch pad चाहते हैं और आप यह स्वीकार करते हैं कि यह उस ब्राउज़र के बाहर कुछ भी save नहीं करता जिसमें आपने ड्राइंग की है, तो Excalidraw चलाएं। यदि आपके diagrams ऐसा text हैं जो git में उस code के साथ रहता है जिसका वे वर्णन करते हैं, तो Kroki चलाएं।

डायग्राम टूल को self-host करने से वास्तव में क्या बदलता है

इस बारे में सटीक रहें कि कौन से हिस्से आपके सर्वर को प्रभावित करते हैं, क्योंकि यही एक तथ्य यह तय करता है कि self-hosting से आपको गोपनीयता (privacy) मिलती है या केवल उपलब्धता (availability)।

• draw.io ब्राउज़र में रेंडर होता है। आपका कंटेनर केवल एप्लिकेशन कोड सर्व करता है। फाइल वहां जाती है जहां आप एडिटर को उसे सेव करने के लिए कहते हैं।
• Excalidraw ब्राउज़र में रेंडर होता है और वर्तमान सीन को उस ब्राउज़र के local storage में रखता है। सर्वर साइड पर कुछ भी नहीं लिखा जाता है।
• Kroki सर्वर पर रेंडर होता है। डायग्राम का सोर्स और तैयार इमेज, दोनों आपके कंटेनर के अंदर मौजूद रहते हैं।

केवल तीसरा मामला डेटा को आपके नियंत्रण वाले हार्डवेयर पर ले जाता है। पहले दो मामलों में, self-hosting से आपको एसेट पर नियंत्रण और उपलब्धता मिलती है: JavaScript आपके होस्ट से आती है, इसलिए जब कोई थर्ड पार्टी आउटेज का सामना करती है, अपनी शर्तें बदलती है, या आपके नेटवर्क से पहुंच से बाहर हो जाती है, तब भी एडिटर काम करता रहता है। कुछ टीमों के लिए इसका वास्तविक मूल्य है। यह "डायग्राम कभी भी बिल्डिंग से बाहर नहीं जाता" वाले दावे से अलग है।

draw.io: एक आधिकारिक container जो कुछ भी स्टोर नहीं करता

यह प्रोजेक्ट अपनी खुद की image प्रकाशित करता है, और इसके README में दी गई quick start केवल एक लाइन की है।

docker run -it --rm --name="draw" -p 8080:8080 -p 8443:8443 jgraph/drawio

यह editor को उस बॉक्स के हर address पर प्रकाशित कर देता है। VPS पर, प्रकाशित port को loopback पर bind करें और इसे reverse proxy या SSH tunnel के माध्यम से एक्सेस करें।

docker run -d --name drawio --restart unless-stopped -p 127.0.0.1:8080:8080 jgraph/drawio

Tunnel के माध्यम से http://127.0.0.1:8080/?offline=1&https=0 खोलें। README में ?offline=1 को "एक सुरक्षा फीचर जो cloud storage के सपोर्ट को डिसेबल करता है" कहा गया है। इसके बिना, editor save target के रूप में Google Drive, OneDrive और GitHub का विकल्प देता है, जो दूसरों के सर्वर हैं।

127.0.0.1 पर bind करना ही उस port को public internet से दूर रखता है। एक साधारण -p 8080:8080 को ufw द्वारा filter नहीं किया जाता है, क्योंकि Docker अपने स्वयं के iptables rules को ufw द्वारा प्रबंधित chains से पहले डाल देता है। इस कारण firewall सही दिखता है, जबकि port दुनिया के लिए खुला रहता है। Docker publishing straight past ufw इस प्रक्रिया और इसके समाधान को कवर करता है।

जैसे ही editor localhost पर नहीं होता, दो environment variables महत्वपूर्ण हो जाते हैं।

services:
  drawio:
    image: jgraph/drawio
    container_name: drawio
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      DRAWIO_SERVER_URL: "https://drawio.example.com/"
      DRAWIO_BASE_URL: "https://drawio.example.com"

अंत में लगा slash (/) कोई टाइपिंग की गलती नहीं है। README में DRAWIO_SERVER_URL को "Public deployment URL जिसके अंत में slash हो" और DRAWIO_BASE_URL को "वही URL बिना trailing slash के" के रूप में परिभाषित किया गया है, जिसका उपयोग viewer, lightbox और embed code paths द्वारा किया जाता है। यदि आप editor को https://www.example.com/drawio/ जैसे subpath के तहत serve करते हैं, तो दोनों values में वह subpath होना चाहिए, क्योंकि app उनसे ही अपने viewer और embed URLs बनाता है।

Persistence: यहाँ कोई persistence नहीं है, और यही इसका डिज़ाइन है। उस Compose file में कोई volume नहीं है क्योंकि container में कोई diagram data नहीं होता है। एक .drawio फाइल XML होती है जिसे editor आपके browser को सौंप देता है, और आपके द्वारा चुना गया save target यह तय करता है कि वह कहाँ जाएगी: आपकी अपनी मशीन पर download, या वह application जिसने editor को embed किया है। उस destination का बैकअप लें। यदि उत्तर VPS पर कोई फोल्डर है, तो सुरक्षित रखने वाली चीज़ वह फोल्डर और the file manager you use to reach it है, क्योंकि draw.io किसी भी चीज़ की कॉपी नहीं रखता है।

क्या अभी भी आपके सर्वर से बाहर जाता है। PDF में export करना इसका सबसे स्पष्ट उदाहरण है। README में DRAWIO_SELF_CONTAINED को इस प्रकार वर्णित किया गया है: "export requests को सीधे export server पर भेजने के बजाय Tomcat के ExportProxyServlet (/service/0) के माध्यम से रूट करने के लिए 1 पर सेट करें"। इसे उल्टा पढ़ें: डिफ़ॉल्ट रूप से, एक export call आपके deployment के अंदर नहीं रहती है। यह प्रोजेक्ट jgraph/export-server भी प्रकाशित करता है, जो "draw.io का एक standalone image-export-server" है, उन लोगों के लिए जो अपने हार्डवेयर पर वह rendering चाहते हैं। ENABLE_DRAWIO_PROXY डिफ़ॉल्ट रूप से बंद रहता है और एक /proxy endpoint को सक्षम करता है जो browser की ओर से external image URLs को fetch करता है, इसलिए जब तक आपको इसकी आवश्यकता न हो, इसे बंद ही रखें।

Excalidraw: एक static bundle जिसके पीछे कोई सर्वर नहीं है

आधिकारिक image पेज यह command देता है।

docker run --rm -dit --name excalidraw -p 5000:80 excalidraw/excalidraw:latest

पिछले कारणों से ही published port को loopback पर ले जाएँ।

docker run -d --name excalidraw --restart unless-stopped -p 127.0.0.1:5000:80 excalidraw/excalidraw:latest

कंटेनर के अंदर, Nginx पोर्ट 80 पर एक compiled JavaScript bundle serve करता है। प्रकाशित image का आकार compressed होने पर लगभग 41 MB है (Docker Hub, अगस्त 2026), जो यह दर्शाता है कि इसमें कितना कम डेटा है। इसमें न कोई database है, न session store, और न ही कोई upload directory, क्योंकि सर्वर पर स्टोर करने के लिए कुछ भी नहीं है।

Image पेज पर इसकी सीमा स्पष्ट रूप से बताई गई है: "फिलहाल, अपना खुद का instance self-host करने पर sharing या collaboration फीचर्स सपोर्ट नहीं किए जाते हैं।" इंटरफ़ेस में बटन अभी भी दिखाई देते हैं, इसलिए इसका कारण जानना महत्वपूर्ण है। Live collaboration के लिए एक websocket सर्वर की आवश्यकता होती है, जिसे अलग से excalidraw/excalidraw-room के रूप में प्रकाशित किया गया है। Share लिंक के लिए encrypted scene को रखने हेतु एक storage सर्विस चाहिए। इन दोनों के पते build के समय Vite variables (VITE_APP_WS_SERVER_URL, VITE_APP_BACKEND_V2_GET_URL, VITE_APP_BACKEND_V2_POST_URL) के रूप में bundle में compile कर दिए जाते हैं, और रिपॉजिटरी में production values Excalidraw की अपनी hosted सेवाओं की ओर इशारा करती हैं। Vite build के दौरान उन values को बदल देता है, इसलिए वे JavaScript के अंदर literal strings के रूप में रह जाती हैं। उन्हें container environment variables के रूप में सेट करने से कुछ नहीं बदलता, क्योंकि runtime पर कोई भी कोड उन्हें नहीं पढ़ता है। Collaboration को अपने खुद के room सर्वर पर पॉइंट करने का मतलब है कि आपको अपनी values के साथ source से frontend को build करना होगा। उस सर्वर की स्थिति की जाँच करें इससे पहले कि आप उसके आधार पर कोई योजना बनाएँ: अगस्त 2026 तक Docker Hub पर मौजूद excalidraw/excalidraw-room image को दो साल से अधिक समय से rebuild नहीं किया गया था।

ड्राइंग वास्तव में कहाँ रहती है। Scene ब्राउज़र के local storage में, उस डिवाइस पर, उस origin के लिए रहती है। उसी URL को एक private window में खोलें और canvas खाली मिलेगा, जो इसे खुद साबित करने का सबसे तेज़ तरीका है। Site data को clear करने से ड्राइंग डिलीट हो जाती है, और restore करने के लिए सर्वर पर कोई कॉपी नहीं होती है। इसलिए लोगों को "Save to..." का उपयोग करना सिखाएं और .excalidraw फाइल को, जो कि JSON है, ऐसी जगह रखें जिसका backup लिया जाता हो। एक shared instance हर व्यक्ति को उनका अपना private canvas देता है। इसे एक personal sketch pad की तरह समझें जो संयोग से host किया गया है।

Kroki: diagrams as code, जिसे आपके सर्वर पर रेंडर किया जाता है

Kroki कई renderers के सामने एक HTTP gateway है। आप text को POST करते हैं और बदले में SVG या PNG प्राप्त करते हैं। Graphviz, PlantUML, D2 और कई अन्य gateway image में ही शामिल हैं। Mermaid, BPMN और Excalidraw की रेंडरिंग companion containers में होती है, इसलिए इसे चलाने के लिए Compose सबसे उचित तरीका है। यह Kroki documentation का एक उदाहरण है।

services:
  kroki:
    image: yuzutech/kroki
    depends_on:
      - mermaid
      - bpmn
      - excalidraw
    environment:
      - KROKI_MERMAID_HOST=mermaid
      - KROKI_BPMN_HOST=bpmn
      - KROKI_EXCALIDRAW_HOST=excalidraw
    ports:
      - "8000:8000"
    tmpfs:
      - /tmp:exec
  mermaid:
    image: yuzutech/kroki-mermaid
    expose:
      - "8002"
  bpmn:
    image: yuzutech/kroki-bpmn
    expose:
      - "8003"
  excalidraw:
    image: yuzutech/kroki-excalidraw
    expose:
      - "8004"

expose host पर कुछ भी publish नहीं करता है, इसलिए companions केवल Compose network पर gateway से ही reachable हैं। यही आप चाहते हैं। gateway line को "127.0.0.1:8000:8000" में बदलें, जब तक कि इसे कॉल करने वाली wiki किसी अलग host पर न चल रही हो। यदि आपने पहले कभी सर्वर पर Compose file नहीं लिखी है, तो running Docker Compose on a VPS में file layout और docker compose up -d cycle के बारे में जानकारी दी गई है।

दो smoke tests चलाएं, इसी क्रम में, क्योंकि वे अलग-अलग कारणों से विफल होते हैं।

curl -s -X POST http://127.0.0.1:8000/graphviz/svg \
  -H 'Content-Type: text/plain' \
  --data-binary 'digraph G {Hello->World}' | head -c 60

Graphviz gateway के अंदर चलता है, इसलिए यहाँ एक SVG document यह साबित करता है कि gateway स्वयं ठीक से काम कर रहा है। अब उस path का परीक्षण करें जो containers के बीच से गुजरता है।

curl -s -X POST http://127.0.0.1:8000/mermaid/svg \
  -H 'Content-Type: text/plain' \
  --data-binary 'graph TD; A-->B;' | head -c 60

दूसरे command से प्राप्त SVG यह साबित करता है कि KROKI_MERMAID_HOST resolve हो गया है और companion ने उत्तर दिया है। यदि पहला test काम करता है और दूसरा नहीं, तो खराबी दोनों containers के बीच है, इसलिए diagram syntax को बदलने से पहले docker compose logs kroki पढ़ें।

GET form diagram को URL में encode करता है, जिससे wiki बिना किसी plugin के image को embed कर सकती है। documentation में यह encoder दिया गया है।

cat hello.dot | python -c "import sys; import base64; import zlib; print(base64.urlsafe_b64encode(zlib.compress(sys.stdin.read().encode('utf-8'), 9)).decode('ascii'))"

Ubuntu पर यह python: command not found print करता है, क्योंकि system में python3 होता है और कोई unversioned python नहीं होता। python3 का उपयोग करें। output /{diagram-type}/{output-format}/{encoded-diagram} आकार के URL के अंत में जाता है, और कोई भी <img> tag इसकी ओर संकेत कर सकता है। इसकी एक सीमा है: KROKI_MAX_URI_LENGTH default रूप से 4096 bytes पर सेट होता है, इसलिए एक लंबे diagram को POST के माध्यम से भेजा जाना चाहिए।

Kroki आपके द्वारा भेजे गए text को पढ़ता है, इसलिए इसकी security settings ही मायने रखती हैं। KROKI_SAFE_MODE default रूप से SECURE पर सेट होता है, जो तीन स्तरों में सबसे अधिक restrictive है, और KROKI_PLANTUML_ALLOW_INCLUDE default रूप से false पर सेट होता है। ये defaults इसलिए मौजूद हैं क्योंकि PlantUML का !include directive renderer के दृष्टिकोण से files और URLs को पढ़ता है। यदि आप इसे ऐसे endpoint पर ढीला करते हैं जिसे कोई भी access कर सकता है, तो आप internet को अपने container के अंदर चलने वाला एक file reader सौंप देंगे। इन्हें तब तक न बदलें जब तक आप यह न जान लें कि आपको किस include path की आवश्यकता है, और फिर उसे KROKI_PLANTUML_INCLUDE_PATH के साथ नाम दें।

Memory: छोटे VPS पर क्या समस्या पैदा करता है

एक बार जब आप यह जान लेते हैं कि प्रत्येक container क्या चलाता है, तो क्रम का अनुमान लगाना आसान हो जाता है।

• Excalidraw image, static files serve करने वाला nginx है। यह तीनों में सबसे सस्ता है।
• draw.io, Tomcat (एक Java application server) चलाता है, इसलिए इसमें एक JVM (Java virtual machine) हमेशा सक्रिय रहता है, चाहे कोई drawing कर रहा हो या नहीं।
• Kroki gateway भी एक Java service है, जिसे manual install के लिए jar के रूप में दिया जाता है।
• Mermaid companion सबसे महंगा है। इसका Dockerfile, Chromium install करता है और PUPPETEER_EXECUTABLE_PATH=/usr/lib/chromium/chrome सेट करता है, क्योंकि Mermaid एक वास्तविक browser engine में रेंडर होता है।

इसलिए, idle numbers आपको बहुत कम जानकारी देते हैं। जो संख्या मायने रखती है वह diagram रेंडर होते समय आने वाला spike है, और KROKI_MERMAID_MAX_CONCURRENCY का default मान 6 है, जिसका अर्थ है कि एक साथ छह browser renders चल सकते हैं। किसी प्रकाशित आंकड़े पर भरोसा करने के बजाय इसे अपने सर्वर पर मापें।

docker stats --no-stream
docker system df

जब सब कुछ idle हो, तब पहली बार चलाएं, और फिर दोबारा तब चलाएं जब आप loop में एक बड़ा mermaid diagram रेंडर कर रहे हों। यदि यह spike छोटे plan पर असहज है, तो अनुमान लगाने के बजाय limit सेट करें: Compose service पर memory limits सेट करना syntax दिखाता है और यह भी बताता है कि container के अपनी सीमा तक पहुँचने पर क्या होता है। Mermaid companion को हटाना भी एक वैध विकल्प है, क्योंकि gateway अपने अंदर बने हर renderer को serve करना जारी रखता है।

इनमें से कोई भी user model के साथ नहीं आता है, इसलिए एक proxy का उपयोग करें

draw.io में कोई account नहीं होता है। Excalidraw में कोई account नहीं होता है। Kroki को जो भी request मिलती है, वह उसका उत्तर देता है। कोई भी login proxy के माध्यम से ही होना चाहिए।

sudo apt update && sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice

htpasswd -c फाइल बनाता है और मौजूदा फाइल को overwrite कर देता है, इसलिए पहली बार -c का उपयोग करें और उसके बाद कभी नहीं।

server {
    listen 443 ssl;
    server_name drawio.example.com;

    location / {
        auth_basic "diagrams";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

इसे sudo nginx -t && sudo systemctl reload nginx के साथ लागू करें। nginx -t वाला हिस्सा महत्वपूर्ण है: यदि configuration खराब है, तो reload करने पर पुरानी configuration ही चलती रहती है, जिससे साइट काम करती रहती है और आपका बदलाव live नहीं होता है। The reverse proxy config, explained line by line में header block और certificate paths के बारे में बताया गया है जिन्हें इस snippet में छोड़ दिया गया है।

Kroki के लिए Basic authentication सही tool नहीं है, और इसका कारण समझना जरूरी है। एक wiki page, Kroki image को <img> tag के साथ embed करता है। reader का browser उस URL को subresource के रूप में fetch करता है, और वह अलग origin पर आपके credentials नहीं भेजता है, इसलिए request 401 error के साथ वापस आती है और page पर हर diagram एक broken image के रूप में दिखाई देता है। Kroki को public internet से दूर रखें। इसे wiki container के समान Docker network पर रखें और wiki को service name के जरिए उस तक पहुँचने दें, बिना host पर कुछ भी publish किए। How Compose networks resolve service names वह जानकारी है जो इसे संभव बनाती है।

सेल्फ-होस्टेड विकी के साथ डायग्राम्स का उपयोग

अक्सर लोग इसी कारण से इन टूल्स का उपयोग करना चाहते हैं। विकी पेज पर एक चित्र की आवश्यकता होती है, और कोई भी यह नहीं चाहता कि वह चित्र किसी के लैपटॉप का स्क्रीनशॉट हो।

BookStack में सेल्फ-होस्टेड एडिटर के लिए एक बेहतरीन हुक मौजूद है। इसका डिफ़ॉल्ट एम्बेड URL https://embed.diagrams.net/?embed=1&proto=json&spin=1&configure=1 है, और .env में एक लाइन जोड़ने से यह आपके कंटेनर पर शिफ्ट हो जाता है।

DRAWIO=https://drawio.example.com/?embed=1&proto=json&spin=1&configure=1

क्वेरी स्ट्रिंग को बिल्कुल वैसे ही कॉपी करें। BookStack का डॉक्यूमेंटेशन कहता है कि embed=1&proto=json&spin=1 "BookStack के साथ इंटीग्रेशन के काम करने के लिए आवश्यक हैं", क्योंकि ये उस JSON मैसेज प्रोटोकॉल का चयन करते हैं जिसका उपयोग दोनों पेज एक-दूसरे से बात करने के लिए करते हैं। वही पेज stealth=1 की ओर इशारा करता है "यदि आप नहीं चाहते कि अन्य बाहरी सेवाओं का उपयोग किया जाए", जो कि वह विकल्प है जिसे आप तब जोड़ते हैं जब सेल्फ-होस्टिंग का मुख्य उद्देश्य ही आउटबाउंड कॉल्स को रोकना हो। एक बार यह सेटअप हो जाने पर, BookStack ड्राइंग को पेज के साथ ही अपने इमेज स्टोरेज में सेव कर लेता है, इसलिए जो विकी बैकअप आप पहले से ले रहे हैं, वही डायग्राम का भी बैकअप बन जाता है।

यदि विकी का चयन अभी तक नहीं हुआ है, तो पहले उसे तय करें। BookStack, Wiki.js और Outline के बीच चयन एक प्रारंभिक निर्णय है, क्योंकि विकी ही यह निर्धारित करता है कि डायग्राम पेज से कैसे जुड़ेगा और इसलिए आपको इनमें से कौन सा टूल उपयोग करना चाहिए।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

BookStack में ड्राइंग एडिटर खुलता है और हमेशा घूमता रहता है। स्पिनर spin=1 एक ऐसे हैंडशेक की प्रतीक्षा कर रहा है जो कभी नहीं आता। जांचें कि embed=1&proto=json&spin=1 आपके DRAWIO मान में मौजूद है और होस्ट भाग में कोई टाइपो नहीं है।

HTTPS विकी पर एडिटर फ्रेम खाली रहता है। ब्राउज़र कंसोल मिक्स्ड कंटेंट की रिपोर्ट करता है, जो https:// के अंदर http:// लोड कर रहा है। ब्राउज़र फ्रेम को ब्लॉक कर देता है, और draw.io कभी नहीं चलता। एडिटर को HTTPS के माध्यम से सर्व करें।

Kroki 413 Request Entity Too Large लौटाता है। वह स्ट्रिंग nginx से आती है, Kroki से नहीं। nginx client_max_body_size डिफ़ॉल्ट 1 MB है और Kroki का अपना KROKI_MAX_BODY_SIZE डिफ़ॉल्ट 1mb है, इसलिए एक बड़ा PlantUML सोर्स जो भी सीमा कम हो, उसे हिट करता है। दोनों को बढ़ाएं।

Graphviz काम करता है जबकि Mermaid विफल हो जाता है। गेटवे स्वस्थ है और साथी (companion) तक नहीं पहुँचा जा रहा है। जांचें कि सर्विस docker compose ps के साथ चल रही है, फिर जांचें कि KROKI_MERMAID_HOST सर्विस नाम से मेल खाता है, क्योंकि यह डिफ़ॉल्ट रूप से 127.0.0.1 होता है, जिसका अर्थ गेटवे कंटेनर के अंदर स्वयं गेटवे होता है।

Excalidraw सहयोग कभी कनेक्ट नहीं होता। यदि आपने अपने स्वयं के रूम सर्वर के लिए फ्रंटएंड बनाया है और उसे nginx के पीछे रखा है, तो प्रॉक्सी को proxy_set_header Upgrade $http_upgrade; और proxy_set_header Connection "upgrade"; के साथ कनेक्शन को अपग्रेड करना होगा। उनके बिना, वेबसॉकेट हैंडशेक का उत्तर एक सामान्य HTTP अनुरोध के रूप में दिया जाता है और सत्र कभी शुरू नहीं होता है।

ब्राउज़र क्लीनअप के बाद कैनवास खाली है। दृश्य उस डिवाइस पर लोकल स्टोरेज में था और सर्वर पर कोई कॉपी नहीं है। इसका समाधान सेटिंग के बजाय एक आदत है: जो कुछ भी रखने योग्य है उसके लिए .excalidraw फ़ाइल को एक्सपोर्ट करें।

FAQ

क्या draw.io को self-host करने से मेरे diagrams निजी रहते हैं?

यह आपके सर्वर पर application code को रखता है, जो डेटा को निजी रखने से अलग बात है। draw.io आपके browser में रेंडर होता है, इसलिए container में कभी भी कोई diagram स्टोर नहीं होता। गोपनीयता इस बात पर निर्भर करती है कि आप फाइल कहाँ सेव करते हैं और कौन से outbound calls को enable रखते हैं। cloud storage targets को disable करने के लिए ?offline=1 का उपयोग करें, और ध्यान रखें कि export requests एक export server पर जाती हैं, जब तक कि आप DRAWIO_SELF_CONTAINED=1 सेट न करें और स्वयं jgraph/export-server न चलाएं।

मेरे self-hosted Excalidraw पर collaboration काम क्यों नहीं करता?

आधिकारिक image पेज बताता है कि self-hosting "sharing या collaboration फीचर्स को सपोर्ट नहीं करता है"। Live collaboration के लिए अलग से excalidraw/excalidraw-room websocket server की आवश्यकता होती है, और share links के लिए storage service चाहिए। दोनों के पते build समय पर JavaScript bundle में Vite variables जैसे VITE_APP_WS_SERVER_URL के रूप में compile किए जाते हैं, इसलिए चल रहे container पर environment variable सेट करने का कोई प्रभाव नहीं पड़ता। अपने स्वयं के room server का उपयोग करने का अर्थ है अपने मानों (values) के साथ source से frontend को build करना।

मैं अपने सर्वर पर Mermaid diagrams को कैसे रेंडर करूँ?

Kroki को उसके mermaid companion container के साथ चलाएं और KROKI_MERMAID_HOST को उस service नाम पर सेट करें। फिर diagram टेक्स्ट को /mermaid/svg पर POST करें और response से SVG पढ़ें, या diagram को GET URL में encode करें और एक <img> टैग को उसकी ओर इंगित करें। companion, Puppeteer के माध्यम से Chromium को चलाता है क्योंकि Mermaid को एक browser engine की आवश्यकता होती है, इसलिए मेमोरी की योजना बनाएं: KROKI_MERMAID_MAX_CONCURRENCY डिफ़ॉल्ट रूप से एक बार में छह रेंडर करता है।

क्या मुझे इन टूल्स के आगे पासवर्ड लगाने की आवश्यकता है?

हाँ, क्योंकि इनमें से किसी में भी accounts नहीं होते हैं। draw.io और Excalidraw URL खोजने वाले किसी भी व्यक्ति को पूर्ण editor दे देते हैं, और Kroki उसे भेजे गए किसी भी टेक्स्ट को रेंडर कर देता है। दोनों editors के लिए reverse proxy पर Basic authentication पर्याप्त है। Kroki के लिए, इसे wiki के साथ साझा किए गए Docker network पर unpublished रखें, क्योंकि reader के browser से आने वाली <img> request दूसरे origin तक credentials नहीं ले जाएगी और हर embedded diagram काम करना बंद कर देगा।