Self-Hosting: draw.io, Excalidraw oder Kroki?

Welches selbst gehostete Diagrammwerkzeug sollten Sie betreiben?

Selbst gehostete Diagrammwerkzeuge gibt es in zwei Varianten. Diese Unterscheidung ist wichtiger als die Liste der Funktionen. draw.io und Excalidraw sind Browseranwendungen: Der Container liefert JavaScript aus, Ihr Browser erstellt die Zeichnung, und der Server sieht das Diagramm nie. Kroki funktioniert umgekehrt. Sie senden Diagrammtext über HTTP, und Kroki sendet ein Bild zurück. Dadurch läuft jedes Diagramm über Ihren eigenen Rechner.

Betreiben Sie draw.io, wenn Sie neben einem Wiki einen vollständigen Editor benötigen. Verwenden Sie Excalidraw, wenn Sie eine schnelle Zeichenfläche möchten und akzeptieren, dass die Anwendung nichts außerhalb des Browsers speichert, in dem Sie gezeichnet haben. Verwenden Sie Kroki, wenn Ihre Diagramme als Textdateien in git neben dem Code liegen, den sie beschreiben.

Was Self-Hosting eines Diagrammtools tatsächlich ändert

Prüfen Sie genau, welche Teile Ihren Server berühren. Davon hängt ab, ob Self-Hosting Datenschutz oder nur Verfügbarkeit bringt.

• draw.io rendert im Browser. Ihr Container stellt den Anwendungscode bereit. Die Datei wird dort gespeichert, wo Sie es im Editor festlegen.
• Excalidraw rendert im Browser und speichert die aktuelle Szene im lokalen Speicher dieses Browsers. Auf der Serverseite wird nichts geschrieben.
• Kroki rendert auf dem Server. Sowohl die Diagrammquelle als auch das fertige Bild befinden sich in Ihrem Container.

Nur im dritten Fall werden Daten auf Hardware verschoben, die Sie kontrollieren. In den ersten beiden Fällen bringt Self-Hosting Kontrolle über die Assets und Verfügbarkeit: Das JavaScript kommt von Ihrem Host. Daher funktioniert der Editor weiter, wenn ein Drittanbieter ausfällt, seine Bedingungen ändert oder aus Ihrem Netzwerk nicht erreichbar ist. Für einige Teams ist das einen konkreten finanziellen Vorteil wert. Das ist eine andere Aussage als: „Das Diagramm verlässt niemals das Gebäude.“

draw.io: ein offizieller Container, der nichts speichert

Das Projekt veröffentlicht ein eigenes Image. Die Schnellstartanleitung in der README besteht aus einer Zeile.

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

Damit wird der Editor auf jeder Adresse veröffentlicht, die der Server besitzt. Binden Sie den veröffentlichten Port auf einem VPS an loopback. Greifen Sie dann über einen Reverse Proxy oder einen SSH-Tunnel darauf zu.

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

Öffnen Sie http://127.0.0.1:8080/?offline=1&https=0 über den Tunnel. In der README wird ?offline=1 als „ein Sicherheitsfeature, das die Unterstützung von Cloud-Speicher deaktiviert“ bezeichnet. Ohne diese Option bietet der Editor Google Drive, OneDrive und GitHub als Speicherziele an. Dabei handelt es sich um Server anderer Betreiber.

Das Binden an 127.0.0.1 verhindert, dass dieser Port aus dem öffentlichen Internet erreichbar ist. Ein einfaches -p 8080:8080 wird von ufw nicht gefiltert, weil Docker eigene iptables-Regeln vor den von ufw verwalteten Chains einfügt. Die Firewall-Konfiguration sieht dadurch korrekt aus, während der Port aus dem gesamten Internet antwortet. Docker veröffentlicht direkt an ufw vorbei erklärt den Mechanismus und die Lösung.

Sobald der Editor nicht auf localhost läuft, sind zwei Umgebungsvariablen relevant.

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"

Der abschließende Schrägstrich ist kein Tippfehler. In der README ist DRAWIO_SERVER_URL als „öffentliche Deployment-URL mit abschließendem Schrägstrich“ und DRAWIO_BASE_URL als „dieselbe URL ohne abschließenden Schrägstrich“ definiert. Diese Werte werden vom Viewer, von der Lightbox und von den Embed-Codepfaden verwendet. Wenn Sie den Editor unter einem Unterpfad wie https://www.example.com/drawio/ bereitstellen, müssen beide Werte diesen Unterpfad enthalten. Die Anwendung erstellt daraus ihre Viewer- und Embed-URLs.

Persistenz: Es gibt keine, und das ist beabsichtigt. In dieser Compose-Datei ist kein Volume angegeben, weil der Container keine Diagrammdaten enthält. Eine .drawio-Datei ist XML, das der Editor an Ihren Browser übergibt. Das ausgewählte Speicherziel bestimmt, wo die Datei landet: als Download auf Ihrem eigenen Rechner oder in der Anwendung, die den Editor eingebettet hat. Sichern Sie dieses Ziel. Wenn es sich um ein Verzeichnis auf dem VPS handelt, müssen Sie dieses Verzeichnis schützen sowie den Dateimanager, mit dem Sie darauf zugreifen, da draw.io keine Kopie von irgendetwas speichert.

Was Ihren Server weiterhin verlässt. Der PDF-Export ist das deutlichste Beispiel. In der README wird DRAWIO_SELF_CONTAINED als „auf 1 setzen, um Exportanfragen über ExportProxyServlet von Tomcat (/service/0) zu leiten, statt den Exportserver direkt aufzurufen“ beschrieben. Umgekehrt gelesen bedeutet das: Standardmäßig bleibt ein Exportaufruf nicht innerhalb Ihrer Bereitstellung. Das Projekt veröffentlicht außerdem jgraph/export-server, einen „eigenständigen Image-Export-Server von draw.io“, für Nutzer, die diese Verarbeitung auf eigener Hardware ausführen möchten. ENABLE_DRAWIO_PROXY ist standardmäßig deaktiviert. Die Option aktiviert einen /proxy-Endpunkt, der externe Bild-URLs stellvertretend für den Browser abruft. Lassen Sie sie daher deaktiviert, sofern Sie sie nicht benötigen.

Excalidraw: ein statisches Bundle ohne Server im Hintergrund

Die offizielle Image-Seite enthält diesen Befehl.

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

Verschieben Sie den veröffentlichten Port aus demselben Grund wie zuvor auf Loopback.

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

Im Container stellt nginx ein kompiliertes JavaScript-Bundle auf Port 80 bereit. Das veröffentlichte Image ist komprimiert etwa 41 MB groß (Docker Hub, August 2026). Daran erkennen Sie, wie wenig darin enthalten ist. Es gibt keine Datenbank, keinen Session-Store und kein Upload-Verzeichnis, weil auf dem Server nichts gespeichert wird.

Auf der Image-Seite wird die Einschränkung klar benannt: „Derzeit unterstützt das Self-Hosting einer eigenen Instanz keine Funktionen zum Teilen oder zur Zusammenarbeit.“ Die Schaltflächen sind weiterhin in der Oberfläche vorhanden. Deshalb ist der Grund wichtig. Live-Zusammenarbeit benötigt einen WebSocket-Server, der separat als excalidraw/excalidraw-room veröffentlicht wird. Ein Freigabelink benötigt einen Speicherdienst für die verschlüsselte Szene. Die Adressen beider Dienste werden beim Build als Vite-Variablen (VITE_APP_WS_SERVER_URL, VITE_APP_BACKEND_V2_GET_URL, VITE_APP_BACKEND_V2_POST_URL) in das Bundle kompiliert. Die Produktionswerte im Repository verweisen auf die von Excalidraw selbst gehosteten Dienste. Vite ersetzt diese Werte während des Builds. Dadurch stehen sie als Literale im JavaScript. Wenn Sie sie als Container-Umgebungsvariablen setzen, ändert sich nichts, weil sie zur Laufzeit von keinem Code gelesen werden. Wenn die Zusammenarbeit auf Ihren eigenen Room-Server verweisen soll, müssen Sie das Frontend mit Ihren eigenen Werten aus dem Quellcode bauen. Prüfen Sie den Zustand dieses Servers, bevor Sie Ihre Planung darauf stützen: Das excalidraw/excalidraw-room-Image auf Docker Hub war im August 2026 seit mehr als zwei Jahren nicht neu gebaut worden.

Wo eine Zeichnung tatsächlich gespeichert ist. Die Szene liegt im lokalen Speicher des Browsers auf dem jeweiligen Gerät und für den jeweiligen Origin. Öffnen Sie dieselbe URL in einem privaten Fenster. Die Zeichenfläche ist dann leer. Das ist der schnellste Weg, dies selbst zu überprüfen. Wenn Sie die Websitedaten löschen, wird die Zeichnung gelöscht. Es gibt keine Serverkopie, aus der sie wiederhergestellt werden kann. Weisen Sie Benutzer daher an, „Speichern unter ...“ zu verwenden und die .excalidraw-Datei, die im JSON-Format vorliegt, an einem Ort aufzubewahren, der gesichert wird. Eine gemeinsam genutzte Instanz stellt jeder Person eine eigene private Zeichenfläche bereit. Behandeln Sie sie als persönliches Skizzenbuch, das lediglich gehostet wird.

Kroki: Diagramme als Code auf Ihrem Server rendern

Kroki ist ein HTTP-Gateway vor mehreren Renderern. Sie senden Text per POST und erhalten SVG oder PNG zurück. Graphviz, PlantUML, D2 und mehrere weitere Renderer sind bereits im Gateway-Image enthalten. Mermaid, BPMN und Excalidraw werden in zusätzlichen Containern gerendert. Deshalb ist Compose die sinnvollste Betriebsart. Dies ist das Beispiel aus der Kroki-Dokumentation.

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 veröffentlicht nichts auf dem Host. Die zusätzlichen Container sind daher nur über das Gateway im Compose-Netzwerk erreichbar. Das ist in diesem Fall gewünscht. Ändern Sie die Gateway-Zeile in "127.0.0.1:8000:8000", sofern die aufrufende Wiki-Anwendung nicht auf einem anderen Host läuft. Wenn Sie auf einem Server noch keine Compose-Datei erstellt haben, beschreibt Docker Compose auf einem VPS ausführen den Dateiaufbau und den docker compose up -d-Zyklus.

Führen Sie zwei Smoke-Tests in dieser Reihenfolge aus, weil sie aus unterschiedlichen Gründen fehlschlagen.

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 läuft im Gateway. Ein SVG-Dokument zeigt daher, dass das Gateway selbst funktioniert. Testen Sie nun den Pfad, der Containergrenzen überschreitet.

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

Das SVG aus dem zweiten Befehl zeigt, dass KROKI_MERMAID_HOST aufgelöst wurde und der zusätzliche Container geantwortet hat. Wenn der erste Test funktioniert und der zweite nicht, liegt der Fehler zwischen den beiden Containern. Lesen Sie daher docker compose logs kroki, bevor Sie die Diagrammsyntax prüfen.

Die GET-Variante kodiert das Diagramm in der URL. Dadurch kann eine Wiki-Anwendung ein Bild ohne Plugin einbinden. Die Dokumentation enthält diesen 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'))"

Unter Ubuntu gibt dieser Befehl python: command not found aus, weil das System python3 bereitstellt, aber kein unversioniertes python. Verwenden Sie python3. Die Ausgabe wird an das Ende einer URL in der Form /{diagram-type}/{output-format}/{encoded-diagram} gesetzt. Jedes <img>-Tag kann auf diese URL verweisen. Es gibt eine Obergrenze: KROKI_MAX_URI_LENGTH ist standardmäßig auf 4096 Bytes gesetzt. Ein langes Diagramm muss daher per POST übertragen werden.

Kroki liest den gesendeten Text. Daher sind die Sicherheitseinstellungen von Kroki entscheidend. KROKI_SAFE_MODE ist standardmäßig auf SECURE gesetzt, die restriktivste der drei Stufen. KROKI_PLANTUML_ALLOW_INCLUDE ist standardmäßig auf false gesetzt. Diese Standardeinstellungen existieren, weil die PlantUML-Direktive !include aus Sicht des Renderers Dateien und URLs liest. Wenn Sie diese Einstellungen an einem öffentlich erreichbaren Endpunkt lockern, stellen Sie dem Internet einen Dateileser innerhalb Ihres Containers zur Verfügung. Lassen Sie die Einstellungen unverändert, sofern Sie nicht genau wissen, welchen Include-Pfad Sie benötigen. Geben Sie diesen Pfad dann mit KROKI_PLANTUML_INCLUDE_PATH an.

Speicher: Was auf einem kleinen VPS Probleme verursacht

Die Reihenfolge ist vorhersehbar, sobald Sie wissen, was in den einzelnen Containern läuft.

• Das Excalidraw-Image verwendet nginx zum Ausliefern statischer Dateien. Es benötigt mit großem Abstand am wenigsten Speicher von den drei Images.
• draw.io verwendet Tomcat, einen Java-Anwendungsserver. Deshalb läuft darin eine JVM (Java Virtual Machine), unabhängig davon, ob gerade jemand zeichnet.
• Das Kroki-Gateway ist ebenfalls ein Java-Dienst und wird bei manuellen Installationen als JAR-Datei bereitgestellt.
• Das mermaid-Begleitmodul ist am teuersten. Sein Dockerfile installiert Chromium und setzt PUPPETEER_EXECUTABLE_PATH=/usr/lib/chromium/chrome, weil Mermaid Diagramme in einer echten Browser-Engine rendert.

Leerlaufwerte sagen deshalb nur wenig aus. Entscheidend ist der Spitzenwert, während ein Diagramm gerendert wird. KROKI_MERMAID_MAX_CONCURRENCY ist standardmäßig auf 6 gesetzt. Dadurch können gleichzeitig sechs Browser-Renderings laufen. Messen Sie den Wert auf Ihrem eigenen System, statt einer veröffentlichten Zahl zu vertrauen.

docker stats --no-stream
docker system df

Führen Sie den ersten Befehl aus, während alle Container im Leerlauf sind. Wiederholen Sie ihn anschließend, während Sie in einer Schleife ein großes mermaid-Diagramm rendern. Wenn der Spitzenwert bei einem kleinen Tarif zu hoch ist, begrenzen Sie ihn, statt zu raten: Speicherlimits für einen Compose-Dienst festlegen zeigt die Syntax und was passiert, wenn ein Container seine Obergrenze erreicht. Das mermaid-Begleitmodul zu entfernen, ist ebenfalls eine gültige Lösung, da das Gateway weiterhin alle darin integrierten Renderer bereitstellt.

Keines dieser Programme bietet ein Benutzermodell. Schalten Sie daher einen Proxy davor.

draw.io hat keine Benutzerkonten. Excalidraw hat keine Benutzerkonten. Kroki beantwortet jede Anfrage, die es erreicht. Eine Anmeldung muss vom Proxy bereitgestellt werden.

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

htpasswd -c erstellt die Datei und überschreibt eine vorhandene Datei. Übergeben Sie daher beim ersten Mal -c und danach nie wieder.

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;
    }
}

Wenden Sie die Konfiguration mit sudo nginx -t && sudo systemctl reload nginx an. Der Teil nginx -t ist dabei entscheidend: Ein Reload mit einer fehlerhaften Konfiguration lässt die alte Konfiguration weiterlaufen. Die Website funktioniert dann weiterhin, aber Ihre Änderung ist nicht aktiv. Die Konfiguration des Reverse Proxy, Zeile für Zeile erklärt behandelt den Header-Block und die Zertifikatspfade, die dieses Snippet auslässt.

Basic Authentication ist für Kroki das falsche Werkzeug. Der Grund dafür ist wichtig. Eine Wiki-Seite bindet ein Kroki-Bild mit einem <img>-Tag ein. Der Browser des Lesers ruft diese URL als Subressource ab. Er sendet Ihre Zugangsdaten nicht an eine andere Origin. Deshalb kommt die Anfrage mit 401 zurück, und jedes Diagramm auf der Seite wird als defektes Bild dargestellt. Halten Sie Kroki stattdessen vom öffentlichen Internet fern. Binden Sie es in dasselbe Docker-Netzwerk wie den Wiki-Container ein. Das Wiki erreicht Kroki dann über den Servicenamen, ohne dass am Host ein Port veröffentlicht wird. Wie Compose-Netzwerke Servicenamen auflösen erklärt die dafür erforderliche Grundlage.

Diagramme neben einem selbst gehosteten Wiki

Das ist der häufigste Grund, warum man eine solche Lösung einsetzen möchte. Eine Wiki-Seite benötigt ein Bild, und niemand möchte, dass dieses Bild ein Screenshot vom Laptop einer anderen Person ist.

BookStack bietet eine direkte Anbindung für einen selbst gehosteten Editor. Die standardmäßige Embed-URL lautet https://embed.diagrams.net/?embed=1&proto=json&spin=1&configure=1. Eine Zeile in .env leitet sie an Ihren Container weiter.

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

Kopieren Sie die Query-Zeichenfolge exakt. In der BookStack-Dokumentation steht, dass embed=1&proto=json&spin=1 „are required for the integration with BookStack to function“ sind. Sie wählen das JSON-Nachrichtenprotokoll aus, über das die beiden Seiten miteinander kommunizieren. Auf derselben Seite wird stealth=1 genannt, „if you don't want other external services to be used“. Diese Option fügen Sie hinzu, wenn das Unterbinden ausgehender Verbindungen ein Grund für das Self-Hosting war. Nach dieser Konfiguration speichert BookStack die Zeichnung im eigenen Bildspeicher neben der Seite. Damit ist das vorhandene Wiki-Backup zugleich auch das Backup der Diagramme.

Wenn noch nicht feststeht, welches Wiki Sie verwenden, klären Sie diese Entscheidung zuerst. Auswahl zwischen BookStack, Wiki.js und Outline ist die frühere Entscheidung, weil das Wiki bestimmt, wie ein Diagramm an eine Seite angehängt wird und welches dieser Tools Sie anschließend ergänzen.

Fehlerfälle und die angezeigten Meldungen

Der Zeicheneditor öffnet sich in BookStack und lädt endlos. Der Ladeindikator wartet auf einen Handshake, der nie eintrifft: spin=1. Prüfen Sie, ob embed=1&proto=json&spin=1 im Wert von DRAWIO enthalten ist und der Hostanteil keinen Tippfehler enthält.

Der Editor-Frame bleibt in einem Wiki über HTTPS leer. Die Browserkonsole meldet gemischte Inhalte, weil http:// innerhalb von https:// geladen wird. Der Browser blockiert den Frame, und draw.io wird nie ausgeführt. Stellen Sie den Editor über HTTPS bereit.

Kroki gibt 413 Request Entity Too Large zurück. Diese Meldung stammt von nginx, nicht von Kroki. Der nginx-Standardwert für client_max_body_size ist 1 MB, der Standardwert von Kroki für KROKI_MAX_BODY_SIZE ist 1mb. Eine große PlantUML-Quelle erreicht daher das jeweils niedrigere Limit. Erhöhen Sie beide Werte.

Mermaid schlägt fehl, während graphviz funktioniert. Das Gateway ist betriebsbereit, aber der Companion wird nicht erreicht. Prüfen Sie mit docker compose ps, ob der Dienst läuft. Prüfen Sie anschließend, ob KROKI_MERMAID_HOST mit dem Dienstnamen übereinstimmt. Der Standardwert ist 127.0.0.1. Innerhalb des Gateway-Containers bezeichnet dieser Wert das Gateway selbst.

Die Zusammenarbeit in Excalidraw wird nie hergestellt. Wenn Sie ein Frontend für Ihren eigenen Room-Server erstellt und es hinter nginx platziert haben, muss der Proxy die Verbindung mit proxy_set_header Upgrade $http_upgrade; und proxy_set_header Connection "upgrade"; aufrüsten. Ohne diese Einstellungen wird der WebSocket-Handshake als normale HTTP-Anfrage beantwortet, und die Sitzung startet nie.

Die Zeichenfläche ist nach einer Browserbereinigung leer. Die Szene lag im lokalen Speicher dieses Geräts. Es gibt keine Kopie auf dem Server. Die Lösung ist eine Gewohnheit und keine Einstellung: Exportieren Sie die .excalidraw-Datei für alle Inhalte, die Sie behalten möchten.

FAQ

Bleiben meine Diagramme beim Self-Hosting von draw.io privat?

Der Anwendungscode liegt auf Ihrem Server. Das bedeutet nicht automatisch, dass die Daten privat bleiben. draw.io rendert im Browser, daher enthält der Container zu keinem Zeitpunkt ein Diagramm. Der Datenschutz hängt davon ab, wo Sie die Datei speichern und welche ausgehenden Verbindungen Sie aktiviert lassen. Verwenden Sie ?offline=1, um die Cloud-Speicherziele zu deaktivieren. Beachten Sie außerdem, dass Exportanfragen an einen Exportserver gesendet werden, sofern Sie nicht DRAWIO_SELF_CONTAINED=1 setzen und jgraph/export-server selbst betreiben.

Warum funktioniert die Zusammenarbeit bei meinem selbst gehosteten Excalidraw nicht?

Auf der offiziellen Image-Seite steht, dass Self-Hosting „Sharing- oder Collaboration-Funktionen nicht unterstützt“. Die Live-Zusammenarbeit benötigt den separaten excalidraw/excalidraw-room-Websocket-Server. Freigabelinks benötigen einen Speicherdienst. Die Adressen beider Dienste werden beim Erstellen des JavaScript-Bundles als Vite-Variablen wie VITE_APP_WS_SERVER_URL fest eingebunden. Eine Umgebungsvariable im laufenden Container hat daher keine Wirkung. Wenn Sie Ihren eigenen Room-Server verwenden, müssen Sie das Frontend mit Ihren Werten aus dem Quellcode erstellen.

Wie rendere ich Mermaid-Diagramme auf meinem eigenen Server?

Starten Sie Kroki mit seinem Mermaid-Begleitcontainer und setzen Sie KROKI_MERMAID_HOST auf den Namen dieses Dienstes. Senden Sie den Diagrammtext anschließend per POST an /mermaid/svg und lesen Sie das SVG aus der Antwort. Alternativ können Sie das Diagramm in eine GET-URL codieren und ein <img>-Tag darauf verweisen lassen. Der Begleitcontainer steuert Chromium über Puppeteer, weil Mermaid eine Browser-Engine benötigt. Planen Sie daher ausreichend Arbeitsspeicher ein: KROKI_MERMAID_MAX_CONCURRENCY ist standardmäßig auf sechs gleichzeitige Render-Vorgänge eingestellt.

Benötige ich ein Passwort vor diesen Tools?

Ja, denn keines dieser Tools verfügt über Benutzerkonten. draw.io und Excalidraw stellen jedem, der die URL kennt, den vollständigen Editor zur Verfügung. Kroki rendert jeden Text, der an den Dienst gesendet wird. Für die beiden Editoren genügt eine Basisauthentifizierung am Reverse Proxy. Lassen Sie Kroki in einem Docker-Netzwerk unveröffentlicht, das gemeinsam mit dem Wiki genutzt wird. Eine <img>-Anfrage aus dem Browser eines Lesers überträgt keine Anmeldedaten an einen anderen Ursprung. Andernfalls würde jedes eingebettete Diagramm nicht mehr funktionieren.