مقارنة أدوات المخططات ذاتية الاستضافة: draw.io وKroki

ما أداة المخططات ذاتية الاستضافة التي ينبغي أن تشغّلها؟

تأتي أدوات المخططات ذاتية الاستضافة في شكلين، والشكل أهم من قائمة الميزات. يُعد draw.io وExcalidraw تطبيقين للمتصفح: تحتوي الحاوية على JavaScript، وينفّذ متصفحك عملية الرسم، ولا يرى الخادم المخطط مطلقاً. أما Kroki فيعمل بالطريقة المعاكسة. ترسل إليه نص المخطط عبر HTTP، ويرسل إليك صورة، ولذلك يمر كل مخطط عبر جهازك.

شغّل draw.io إذا كنت تريد محرراً كاملاً بجانب wiki. شغّل Excalidraw إذا كنت تريد مساحة سريعة للرسم، وتقبل أن الأداة لا تحفظ شيئاً خارج المتصفح الذي رسمت فيه. شغّل Kroki إذا كانت مخططاتك نصوصاً محفوظة في git بجانب الشفرة التي تصفها.

ما الذي يتغير فعلياً عند الاستضافة الذاتية لأداة رسم المخططات

حدّد بدقة الأجزاء التي تتصل بخادمك، لأن هذه الحقيقة وحدها تحدد ما إذا كانت الاستضافة الذاتية تمنحك الخصوصية أم التوافر فقط.

• يعرض draw.io المحتوى في المتصفح. وتقدّم حاويتك شيفرة التطبيق. ويُحفظ الملف في المكان الذي تحدده للمحرر.
• يعرض Excalidraw المحتوى في المتصفح، ويحتفظ بالمشهد الحالي في التخزين المحلي لذلك المتصفح. ولا تُكتب أي بيانات على جانب الخادم.
• يعرض Kroki المحتوى على الخادم. ويوجد مصدر المخطط والصورة النهائية داخل حاويتك.

تنقل الحالة الثالثة فقط البيانات إلى عتاد تتحكم فيه. أما في الحالتين الأوليين، فتمنحك الاستضافة الذاتية التحكم في الأصول والتوافر: تأتي JavaScript من مضيفك، لذلك يواصل المحرر العمل عندما يتعرض طرف ثالث لانقطاع، أو يغيّر شروطه، أو يتعذر الوصول إليه من شبكتك. وقد تكون هذه فائدة ذات قيمة مالية حقيقية لبعض الفرق. لكنها تختلف عن القول إن «المخطط لا يغادر المبنى أبداً».

draw.io: حاوية رسمية لا تخزّن شيئاً

ينشر المشروع صورته الخاصة، ويتكوّن التشغيل السريع في README من سطر واحد.

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

ينشر ذلك المحرر على كل عنوان تملكه الخادوم. على VPS، اربط المنفذ المنشور بواجهة loopback، ثم اتصل به عبر reverse proxy أو نفق SSH.

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

افتح http://127.0.0.1:8080/?offline=1&https=0 عبر النفق. يصف README الخيار ?offline=1 بأنه «ميزة أمان تعطل دعم التخزين السحابي». من دونه، يوفّر المحرر Google Drive وOneDrive وGitHub كوجهات للحفظ، وهي خوادم تابعة لجهات أخرى.

ربط المنفذ بواجهة 127.0.0.1 هو ما يمنع إتاحته على الإنترنت العام. لا يخضع -p 8080:8080 العادي للتصفية بواسطة ufw، لأن Docker يضيف قواعد iptables الخاصة به قبل السلاسل التي يديرها ufw. لذلك يبدو إعداد الجدار الناري صحيحاً، بينما يستجيب المنفذ للعالم كله. يشرح نشر Docker مباشرةً متجاوزاً ufw الآلية وطريقة الإصلاح.

تظهر أهمية متغيري البيئة هذين بمجرد ألا يكون المحرر على localhost.

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"

الشرطة المائلة الختامية ليست خطأ مطبعياً. يعرّف README الخيار DRAWIO_SERVER_URL بأنه «عنوان النشر العام مع شرطة مائلة ختامية»، والخيار DRAWIO_BASE_URL بأنه «العنوان نفسه من دون شرطة مائلة ختامية»، ويستخدمهما مسارا viewer وlightbox وembed. إذا شغّلت المحرر ضمن مسار فرعي مثل https://www.example.com/drawio/، فيجب أن تتضمن القيمتان ذلك المسار، لأن التطبيق ينشئ عناوين viewer وembed منهما.

لا توجد استمرارية للبيانات، وهذا مقصود في التصميم. لا يظهر أي volume في ملف Compose ذلك، لأن الحاوية لا تحتوي على بيانات المخططات. ملف .drawio هو XML يسلّمه المحرر إلى متصفحك، وتحدد وجهة الحفظ التي تختارها مكان تخزينه: تنزيل على جهازك، أو التطبيق الذي يضمّن المحرر. أنشئ نسخة احتياطية من تلك الوجهة. إذا كانت الوجهة مجلداً على VPS، فهذا المجلد هو الشيء الذي يستحق الحماية، وكذلك مدير الملفات الذي تستخدمه للوصول إليه، لأن draw.io لا يحتفظ بأي نسخة من أي شيء.

ما يزال يغادر خادومك. التصدير إلى PDF هو أوضح مثال. يصف README الخيار DRAWIO_SELF_CONTAINED بأنه «اضبطه على 1 لتوجيه طلبات التصدير عبر ExportProxyServlet الخاص بـTomcat (/service/0) بدلاً من استدعاء خادم التصدير مباشرةً». اقرأ ذلك بعكس الاتجاه: افتراضياً، لا يبقى طلب التصدير داخل عملية النشر الخاصة بك. ينشر المشروع أيضاً jgraph/export-server، وهو «standalone image-export-server لـdraw.io»، لمن يريد تنفيذ عملية التصيير على أجهزته الخاصة. يكون ENABLE_DRAWIO_PROXY معطلاً افتراضياً، وتفعيله يتيح endpoint من نوع /proxy يجلب عناوين صور خارجية بالنيابة عن المتصفح، لذا اتركه معطلاً ما لم تكن تحتاج إليه.

Excalidraw: حزمة ثابتة دون خادم خلفها

تعرض صفحة الصورة الرسمية هذا الأمر.

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

انقل المنفذ المنشور إلى loopback للسبب نفسه المذكور سابقاً.

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

داخل الحاوية، يقدّم nginx حزمة JavaScript مترجمة على المنفذ 80. يبلغ حجم الصورة المنشورة نحو 41 MB بعد الضغط (Docker Hub، أغسطس 2026)، وهذا يوضح قلة مكوناتها. لا توجد قاعدة بيانات، ولا مخزن جلسات، ولا مجلد تحميلات، لأنه لا يوجد شيء لتخزينه على الخادم.

تذكر صفحة الصورة القيد بوضوح: "في الوقت الحالي، لا يدعم الاستضافة الذاتية لمثيلك ميزات المشاركة أو التعاون." وما زالت الأزرار تظهر في الواجهة، لذلك من المفيد معرفة السبب. يحتاج التعاون المباشر إلى خادم websocket، يُنشر بشكل منفصل باسم excalidraw/excalidraw-room. ويحتاج رابط المشاركة إلى خدمة تخزين لحفظ المشهد المشفّر. تُضمَّن عناوين الخدمتين في الحزمة أثناء البناء كمتغيرات Vite (VITE_APP_WS_SERVER_URL وVITE_APP_BACKEND_V2_GET_URL وVITE_APP_BACKEND_V2_POST_URL)، وتشير قيم الإنتاج في المستودع إلى خدمات Excalidraw المستضافة نفسها. يستبدل Vite هذه القيم أثناء البناء، فتظهر في JavaScript كسلاسل نصية حرفية. لا يغيّر ضبطها كمتغيرات بيئة للحاوية شيئاً، لأن الشيفرة لا تقرؤها أثناء التشغيل. توجيه التعاون إلى خادم الغرف الخاص بك يعني بناء الواجهة الأمامية من المصدر باستخدام قيمك الخاصة. تحقّق من حالة ذلك الخادم قبل أن تبني خطتك عليه: فلم تكن صورة excalidraw/excalidraw-room على Docker Hub قد أُعيد بناؤها منذ أكثر من عامين حتى أغسطس 2026.

أين يوجد الرسم فعلياً. يوجد المشهد في local storage للمتصفح، على ذلك الجهاز، لذلك النطاق. افتح عنوان URL نفسه في نافذة خاصة، وستكون اللوحة فارغة؛ وهذه أسرع طريقة لإثبات ذلك بنفسك. يؤدي مسح بيانات الموقع إلى حذف الرسم، ولا توجد نسخة على الخادم يمكن استعادتها. لذلك علّم المستخدمين استخدام "Save to..." والاحتفاظ بملف .excalidraw، وهو ملف JSON، في مكان تُجرى له نسخ احتياطية. يمنح المثيل المشترك كل شخص لوحة خاصة به. تعامل معه كلوح رسم شخصي مستضاف على خادم.

Kroki: مخططات بوصفها شيفرة، مع عرضها على خادمك

Kroki هي بوابة HTTP واحدة أمام عدة محركات عرض. ترسل إليها نصاً عبر POST، فتحصل على SVG أو PNG. تتضمن صورة البوابة Graphviz وPlantUML وD2 وعدة محركات أخرى. أما عرض Mermaid وBPMN وExcalidraw فيتم داخل حاويات مرافقة، لذلك يُعد Compose الطريقة المناسبة لتشغيلها. هذا هو المثال الوارد في وثائق Kroki.

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 أي شيء على المضيف، لذلك لا يمكن الوصول إلى الحاويات المرافقة إلا من البوابة عبر شبكة Compose. وهذا هو المطلوب. غيّر سطر البوابة إلى "127.0.0.1:8000:8000"، إلا إذا كانت الويكي التي تستدعيها تعمل على مضيف مختلف. إذا لم تكتب ملف Compose على خادم من قبل، فسيشرح لك تشغيل Docker Compose على VPS بنية الملفات ودورة docker compose up -d.

شغّل اختباري smoke بالترتيب التالي، لأن كل واحد منهما يفشل لأسباب مختلفة.

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 داخل البوابة، لذلك يثبت مستند SVG هنا أن البوابة نفسها تعمل بصورة سليمة. اختبر الآن المسار الذي يعبر بين الحاويات.

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

يثبت SVG الناتج عن الأمر الثاني أن KROKI_MERMAID_HOST حُلَّ وأن الحاوية المرافقة استجابت. إذا نجح الاختبار الأول وفشل الثاني، فالعطل يقع بين الحاويتين، لذلك اقرأ docker compose logs kroki قبل تعديل صياغة المخطط.

يحوّل نموذج GET المخطط إلى قيمة مشفّرة داخل URL، وهذه هي الطريقة التي تدمج بها الويكي صورة من دون أي plugin. توفّر الوثائق أداة الترميز التالية.

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، لأن النظام يوفّر python3 ولا يوفّر python من دون رقم إصدار. استخدم python3. يُضاف الناتج إلى نهاية URL على الشكل /{diagram-type}/{output-format}/{encoded-diagram}، ويمكن لأي وسم <img> الإشارة إليه. توجد حدود للطول: القيمة الافتراضية لـKROKI_MAX_URI_LENGTH هي 4096 بايت، لذلك يجب إرسال المخطط الطويل عبر POST.

يقرأ Kroki النص الذي ترسله إليه، ولذلك فإن إعدادات الأمان الخاصة به هي التي تهم. تكون القيمة الافتراضية لـKROKI_SAFE_MODE هي SECURE، وهو المستوى الأكثر تقييداً من المستويات الثلاثة، وتكون القيمة الافتراضية لـKROKI_PLANTUML_ALLOW_INCLUDE هي false. وُضعت هذه القيم الافتراضية لأن توجيه !include في PlantUML يقرأ الملفات وعناوين URL من منظور محرك العرض. إذا خففت هذه القيود على endpoint يمكن لأي شخص الوصول إليه، فأنت تمنح الإنترنت قارئ ملفات يعمل داخل حاويتك. اتركها كما هي ما لم تعرف مسار include الذي تحتاج إليه، ثم حدده باستخدام KROKI_PLANTUML_INCLUDE_PATH.

الذاكرة: أيّها يسبب المشكلة على VPS صغير

يصبح الترتيب متوقعاً عندما تعرف وظيفة كل حاوية.

• صورة Excalidraw هي nginx الذي يقدّم ملفات ثابتة. وهي الأرخص بين الثلاث بفارق كبير.
• يشغّل draw.io خادم Tomcat، وهو خادم تطبيقات Java، لذلك يستهلك JVM (الآلة الافتراضية لـJava) سواء كان أحد يرسم أم لا.
• بوابة Kroki هي أيضاً خدمة Java، وتُوزَّع في صورة jar عند التثبيت اليدوي.
• المكوّن المرافق لـmermaid هو الأغلى. يثبّت Dockerfile الخاص به Chromium ويضبط PUPPETEER_EXECUTABLE_PATH=/usr/lib/chromium/chrome، لأن Mermaid يعرض الرسومات في محرك متصفح فعلي.

لذلك لا تخبرك أرقام الخمول بالكثير. الرقم المهم هو الارتفاع المفاجئ أثناء عرض الرسم التخطيطي، وتكون القيمة الافتراضية لـKROKI_MERMAID_MAX_CONCURRENCY هي 6، ما يعني إمكانية تنفيذ 6 عمليات عرض في المتصفح في الوقت نفسه. قِس ذلك على خادمك بدلاً من الاعتماد على رقم منشور.

docker stats --no-stream
docker system df

نفّذ الأمر الأول بينما كل شيء في حالة خمول، ثم نفّذه مرة أخرى أثناء عرض رسم mermaid كبير في حلقة. إذا كان الارتفاع غير مريح على خطة صغيرة، فضع له حداً بدلاً من التخمين: يوضح ضبط حدود الذاكرة على خدمة Compose الصيغة وما يحدث عندما تصل حاوية إلى حدها الأقصى. ويُعد حذف المكوّن المرافق لـmermaid إجابة صحيحة أيضاً، لأن البوابة تواصل تقديم كل أدوات العرض المضمّنة فيها.

لا توفّر أيٌّ من هذه الخدمات نموذج مستخدمين، لذا ضع طبقة مصادقة أمامها

لا يوفّر draw.io حسابات. ولا يوفّر Excalidraw حسابات. ويستجيب Kroki لأي طلب يصل إليه. لذلك يجب أن تأتي أي عملية تسجيل دخول من الـproxy.

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

ينشئ htpasswd -c الملف ويستبدل الملف الموجود، لذا مرّر -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 هو الأهم: إذا نفّذت reload على إعداد معطّل، فسيستمر الإعداد القديم في العمل، ولذلك سيظل الموقع يعمل ولن يصبح التغيير فعالاً. يشرح إعداد الـreverse proxy سطراً بسطر كتلة الرؤوس ومسارات الشهادات التي لا يتضمنها هذا المقطع.

المصادقة الأساسية ليست الأداة المناسبة لـKroki، ومن المهم فهم السبب. تدرج صفحة wiki صورة Kroki باستخدام وسم <img>. يجلب متصفح القارئ عنوان URL هذا كمورد فرعي، ولا يرسل بيانات اعتمادك إلى origin مختلف، لذلك يعود الطلب بالرمز 401 وتظهر كل مخططات الصفحة كصور معطّلة. بدلاً من ذلك، امنع Kroki من الوصول إلى الإنترنت العام. ضعه على شبكة Docker نفسها التي تستخدمها حاوية wiki، ودع wiki يصل إليه باسم الخدمة، من دون نشر أي منفذ على المضيف. يوضح كيفية حل شبكات Compose لأسماء الخدمات الجزء الذي يجعل ذلك ممكناً.

المخططات التي تعمل بجوار ويكي مستضاف ذاتياً

هذا هو السبب المعتاد الذي يدفع الناس إلى استخدام أي من هذه الأدوات. تحتاج صفحة الويكي إلى صورة، ولا يريد أحد أن تكون هذه الصورة لقطة شاشة من حاسوب محمول لأحد الأشخاص.

يوفّر BookStack تكاملاً مدمجاً مع محرر مستضاف ذاتياً. عنوان التضمين الافتراضي هو 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. تعرض وحدة تحكم المتصفح خطأ في المحتوى المختلط، لأنّها تحمّل http:// داخل https://. يحظر المتصفح الإطار، ولا يعمل 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 الكبيرة بالحد الأقل بينهما. ارفع القيمتين.

يفشل Mermaid بينما يعمل graphviz. البوابة سليمة، لكن لا يجري الوصول إلى الخدمة المرافقة. تحقق من أن الخدمة قيد التشغيل باستخدام docker compose ps، ثم تحقق من تطابق KROKI_MERMAID_HOST مع اسم الخدمة، لأنّ قيمته الافتراضية هي 127.0.0.1، وهذا يعني البوابة نفسها من داخل حاوية البوابة.

لا يتصل Excalidraw بوضع التعاون مطلقاً. إذا أنشأت واجهة أمامية تعتمد على خادم الغرف الخاص بك ووضعتها خلف nginx، فيجب على الوكيل ترقية الاتصال باستخدام proxy_set_header Upgrade $http_upgrade; وproxy_set_header Connection "upgrade";. من دونهما، تُجاب مصافحة websocket باعتبارها طلب HTTP عادياً، ولا تبدأ الجلسة.

تبقى اللوحة فارغة بعد تنظيف المتصفح. كان المشهد محفوظاً في التخزين المحلي على ذلك الجهاز، ولا توجد نسخة على الخادم. الحل عادة وليس إعداداً: صدّر ملف .excalidraw لأي محتوى يستحق الاحتفاظ به.

FAQ

هل يحافظ استضافة draw.io ذاتياً على خصوصية مخططاتي؟

إنها تُبقي شيفرة التطبيق على خادمك، وهذا يختلف عن إبقاء البيانات خاصة. يعرض draw.io المخططات في متصفحك، لذلك لا تحتوي الحاوية على أي مخطط على الإطلاق. تعتمد الخصوصية بعد ذلك على مكان حفظ الملف، وعلى الاتصالات الصادرة التي تتركها مفعّلة. استخدم ?offline=1 لتعطيل أهداف التخزين السحابي، وتذكّر أن طلبات التصدير تُرسل إلى خادم تصدير ما لم تضبط DRAWIO_SELF_CONTAINED=1 وتشغّل jgraph/export-server بنفسك.

لماذا لا يعمل التعاون في Excalidraw المستضاف ذاتياً؟

تذكر صفحة الصورة الرسمية أن الاستضافة الذاتية «لا تدعم ميزات المشاركة أو التعاون». يحتاج التعاون المباشر إلى خادم websocket منفصل هو excalidraw/excalidraw-room، كما تحتاج روابط المشاركة إلى خدمة تخزين. تُضمَّن عناوين الخدمتين في حزمة JavaScript وقت البناء باعتبارها متغيرات Vite مثل VITE_APP_WS_SERVER_URL، لذلك لا يؤثر ضبط متغير بيئة في الحاوية قيد التشغيل. لاستخدام خادم الغرف الخاص بك، يجب بناء الواجهة الأمامية من المصدر باستخدام قيمك.

كيف أعرض مخططات Mermaid على خادمي؟

شغّل Kroki مع حاوية Mermaid المصاحبة له، واضبط KROKI_MERMAID_HOST على اسم تلك الخدمة. ثم أرسل نص المخطط باستخدام POST إلى /mermaid/svg واقرأ SVG من الاستجابة، أو شفّر المخطط في عنوان URL باستخدام GET ووجّه وسم <img> إليه. تتحكم الحاوية المصاحبة في Chromium عبر Puppeteer لأن Mermaid يحتاج إلى محرك متصفح، لذلك خطّط لاستهلاك الذاكرة: القيمة الافتراضية لـKROKI_MERMAID_MAX_CONCURRENCY هي ست عمليات عرض في الوقت نفسه.

هل أحتاج إلى وضع كلمة مرور أمام هذه الأدوات؟

نعم، لأن أياً منها لا يوفّر حسابات. يمنح draw.io وExcalidraw محرراً كاملاً لأي شخص يعثر على عنوان URL، بينما يعرض Kroki أي نص يُرسل إليه. تكفي المصادقة الأساسية في Reverse Proxy للمحررين. أما Kroki، فأبقِه غير منشور على شبكة Docker مشتركة مع الويكي، لأن طلب <img> من متصفح القارئ لن ينقل بيانات الاعتماد إلى مصدر آخر، وسيتعطل كل مخطط مضمّن.