Self-Hosting-Diagrammtools: draw.io, Excalidraw, Kroki

Welches Self-Hosting-Diagrammtool sollten Sie betreiben?

Self-Hosting-Diagrammtools gibt es in zwei Grundformen. Die Form ist wichtiger als die Liste der Funktionen. draw.io und Excalidraw sind Browseranwendungen: Der Container liefert JavaScript aus, Ihr Browser erstellt das Diagramm, und der Server sieht das Diagramm nie. Bei Kroki ist es umgekehrt. Sie senden Diagrammtext per 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. Betreiben Sie Excalidraw, wenn Sie eine schnelle Skizzenfläche möchten und akzeptieren, dass außerhalb des Browsers, in dem Sie die Zeichnung erstellt haben, nichts gespeichert wird. Betreiben Sie Kroki, wenn Ihre Diagramme als Text in git neben dem Code liegen, den sie beschreiben.

Was Self-Hosting eines Diagrammtools tatsächlich ändert

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

• draw.io rendert im Browser. Ihr Container stellt den Anwendungscode bereit. Die Datei wird dort gespeichert, wo Sie den Editor anweisen, sie zu speichern.
• 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 bietet Self-Hosting Kontrolle über die Assets und Verfügbarkeit: Das JavaScript wird von Ihrem Host geladen. Daher funktioniert der Editor weiter, wenn ein Drittanbieter einen Ausfall hat, seine Bedingungen ändert oder aus Ihrem Netzwerk nicht erreichbar ist. Für manche Teams ist das einen erheblichen finanziellen Wert. Das ist eine andere Aussage als: „Das Diagramm verlässt das Gebäude nie.“

draw.io: ein offizieller Container, der nichts speichert

Das Projekt veröffentlicht ein eigenes Image. Der Quick Start 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 auf einem VPS den veröffentlichten Port an die Loopback-Adresse. 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 „a security feature that disables support of cloud storage“ bezeichnet. Ohne diese Option bietet der Editor Google Drive, OneDrive und GitHub als Speicherziele an. Das sind Server anderer Betreiber.

Die Bindung 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 weltweit Verbindungen annimmt. Docker veröffentlicht direkt an ufw vorbei erklärt den Mechanismus und die Behebung.

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

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. Die README definiert DRAWIO_SERVER_URL als „Public deployment URL with a trailing slash“ und DRAWIO_BASE_URL als „Same URL without a trailing slash“. Diese Werte werden für den Viewer, die Lightbox und die Embed-Codepfade 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 enthalten, weil der Container keine Diagrammdaten speichert. Eine .drawio-Datei besteht aus 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, ist dieses Verzeichnis schützenswert, ebenso wie der Dateimanager, den Sie für den Zugriff darauf verwenden, da draw.io keine Kopie speichert.

Was Ihren Server weiterhin verlässt. Weniger als früher, weil der Export nicht mehr an einen externen Dienst gesendet wird. Die README führt EXPORT_URL und DRAWIO_SELF_CONTAINED inzwischen unter den entfernten Variablen auf, die keine Wirkung haben. Sie verwiesen auf das separate jgraph/export-server-Image, das „has reached end of life“. Der Entrypoint schreibt nun window.EXPORT_URL = null in PreConfig.js. Damit wird dem Editor mitgeteilt, dass kein Exportdienst vorhanden ist. In der Praxis öffnet „Export as > PDF“ den Druckdialog des Browsers. Daher wird für PDF keine Option angeboten, eine Kopie des Diagramms einzuschließen. Der serverseitig gerenderte PNG- und JPEG-Export ist ausgeblendet. Der im Browser gerenderte Export in PNG, JPEG und SVG funktioniert weiterhin. ENABLE_DRAWIO_PROXY ist standardmäßig deaktiviert und aktiviert einen /proxy-Endpunkt, der externe Bild-URLs stellvertretend für den Browser abruft. Lassen Sie die Option deaktiviert, sofern Sie sie nicht benötigen.

Excalidraw: ein statisches Bundle ohne Server dahinter

Auf der offiziellen Image-Seite wird dieser Befehl angegeben.

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

Veröffentlichen Sie den Port aus demselben Grund wie zuvor nur auf dem Loopback-Interface.

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, Oktober 2026). Daran erkennen Sie, wie wenig darin enthalten ist. Es gibt keine Datenbank, keinen Session-Speicher und kein Upload-Verzeichnis, weil auf dem Server nichts gespeichert wird.

Auf der Image-Seite wird die Einschränkung ausdrücklich genannt: „At the moment, self-hosting your own instance doesn't support sharing or collaboration features.“ Die Schaltflächen sind weiterhin in der Benutzeroberfläche vorhanden. Deshalb ist es wichtig, den Grund zu kennen. Für die Live-Zusammenarbeit ist ein WebSocket-Server erforderlich, der separat als excalidraw/excalidraw-room veröffentlicht wird. Ein Freigabelink benötigt einen Speicherdienst, der die verschlüsselte Szene speichert. 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 gehosteten Dienste von Excalidraw. Vite ersetzt diese Werte während des Builds. Dadurch liegen sie als Literalstrings im JavaScript vor. Wenn Sie sie als Container-Umgebungsvariablen setzen, ändert sich nichts, weil sie zur Laufzeit von keinem Code gelesen werden. Wenn Sie die Zusammenarbeit auf Ihren eigenen Room-Server ausrichten möchten, 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 ausrichten: Im Oktober 2026 lag der neueste Push des excalidraw/excalidraw-room-Images auf Docker Hub im Dezember 2023.

Wo eine Zeichnung tatsächlich gespeichert wird. Die Szene liegt im lokalen Speicher des Browsers auf diesem Gerät und für diesen 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 Kopie auf dem Server, aus der sie wiederhergestellt werden könnte. Weisen Sie Benutzer daher an, „Save to...“ zu verwenden und die .excalidraw-Datei, die im JSON-Format vorliegt, an einem Ort zu speichern, der gesichert wird. Eine gemeinsam genutzte Instanz stellt jeder Person eine eigene private Zeichenfläche bereit. Betrachten Sie sie als persönliches Skizzenpad, das zufällig gehostet wird.

Kroki: Diagramme als Code, auf Ihrem Server gerendert

Kroki ist ein HTTP-Gateway vor vielen 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. Für Mermaid, BPMN und Excalidraw werden zusätzliche Container verwendet. Deshalb ist Compose die sinnvolle 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 Compose-Netzwerk vom Gateway aus erreichbar. Das ist beabsichtigt. Ä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 Aufbau der Datei und den docker compose up -d-Zyklus.

Führen Sie zwei Smoke-Tests in dieser Reihenfolge aus. Sie schlagen aus unterschiedlichen Gründen fehl.

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 an dieser Stelle bestätigt daher, dass das Gateway selbst funktioniert. Testen Sie jetzt 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

SVG aus dem zweiten Befehl bestätigt, 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 codiert das Diagramm in der URL. So kann ein Wiki ein Bild ganz ohne Plugin einbinden. Die Dokumentation stellt diesen Encoder bereit.

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 und kein nicht versioniertes python bereitstellt. Verwenden Sie python3. Die Ausgabe wird an das Ende einer URL im Format /{diagram-type}/{output-format}/{encoded-diagram} angefügt. Jedes <img>-Tag kann auf diese URL verweisen. Es gibt eine Begrenzung: KROKI_MAX_URI_LENGTH ist standardmäßig auf 4096 Bytes gesetzt. Ein langes Diagramm muss daher per POST übertragen werden.

Kroki verarbeitet den von Ihnen gesendeten Text. Daher sind seine Sicherheitseinstellungen 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 Standardwerte sind erforderlich, weil die PlantUML-Direktive !include Dateien und URLs aus Sicht des Renderers liest. Wenn Sie diese Einstellungen an einem für beliebige Clients erreichbaren Endpunkt lockern, stellen Sie dem Internet einen Dateileser bereit, der in Ihrem Container läuft. Belassen Sie die Einstellungen unverändert, sofern Sie nicht genau wissen, welchen Include-Pfad Sie benötigen. Geben Sie ihn dann mit KROKI_PLANTUML_INCLUDE_PATH an.

Speicher: Was belastet einen kleinen VPS?

Die Reihenfolge ist vorhersehbar, sobald Sie wissen, was jeder Container ausführt.

• 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 führt Tomcat als Java-Anwendungsserver aus. Deshalb benötigt es eine JVM (Java Virtual Machine), unabhängig davon, ob gerade jemand zeichnet.
• Das Kroki-Gateway ist ebenfalls ein Java-Dienst. Bei manuellen Installationen wird es als jar-Datei bereitgestellt.
• Der Mermaid-Begleitdienst 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 daher nur wenig aus. Entscheidend ist der Spitzenwert, während ein Diagramm gerendert wird. KROKI_MERMAID_MAX_CONCURRENCY ist standardmäßig auf 6 gesetzt, sodass gleichzeitig bis zu sechs Browser-Renderings ausgeführt werden können. Messen Sie dies 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 alles im Leerlauf ist, und anschließend erneut, während Sie in einer Schleife ein großes Mermaid-Diagramm rendern. Wenn der Spitzenwert bei einem kleinen Tarif problematisch ist, begrenzen Sie ihn, statt zu raten: Speicherlimits für einen Compose-Dienst festlegen zeigt die Syntax und was geschieht, wenn ein Container sein Limit erreicht. Sie können den Mermaid-Begleitdienst auch weglassen. Das Gateway stellt weiterhin jeden darin enthaltenen Renderer bereit.

Keine dieser Anwendungen stellt ein Benutzermodell bereit. Setzen Sie daher einen Proxy davor.

draw.io hat keine Benutzerkonten. Excalidraw hat keine Benutzerkonten. Kroki beantwortet jede Anfrage, die es erreicht. Die Anmeldung muss daher vom Proxy übernommen 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 entscheidend: Wenn die Konfiguration fehlerhaft ist, lässt ein Reload die alte Konfiguration weiterlaufen. Die Website bleibt dann erreichbar, aber Ihre Änderung ist nicht aktiv. Die Reverse-Proxy-Konfiguration 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 ist wichtig. Eine Wiki-Seite bindet ein Kroki-Bild mit einem <img>-Tag ein. Der Browser des Lesers ruft diese URL als Cross-Origin-Subressource ab. Er übermittelt die Basic-Anmeldedaten, die er bereits für den Kroki-Host gespeichert hat. Aktuelle Browser zeigen jedoch für ein Cross-Origin-Bild keinen Anmeldedialog an. Leser, die sich nicht direkt am Kroki-Host angemeldet haben, erhalten daher einen 401-Fehler. Jedes Diagramm auf der Seite wird als fehlerhaftes Bild angezeigt. Halten Sie Kroki stattdessen vom öffentlichen Internet fern. Verbinden Sie es mit demselben Docker-Netzwerk wie den Wiki-Container. Das Wiki kann Kroki dann über den Servicenamen erreichen, ohne dass ein Port auf dem Host veröffentlicht wird. So lösen Compose-Netzwerke Servicenamen auf beschreibt den dafür erforderlichen Mechanismus.

Diagramme neben einem selbst gehosteten Wiki

Das ist der übliche Grund, warum sich jemand für diese Lösung interessiert. 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 native 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 verschiebt sie in Ihren Container.

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

Übernehmen Sie die Query-Zeichenfolge exakt. In der BookStack-Dokumentation heißt es, embed=1&proto=json&spin=1 „are required for the integration with BookStack to function“. Diese Parameter wählen das JSON-Nachrichtenprotokoll aus, über das die beiden Seiten miteinander kommunizieren. Auf derselben Seite wird auf stealth=1 „if you don't want other external services to be used“ verwiesen. Diese Option ergänzen Sie, wenn das Unterbinden ausgehender Verbindungen ein Grund für das Self-Hosting war. Nach dieser Konfiguration speichert BookStack die Zeichnung neben der Seite im eigenen Bildspeicher. Damit ist auch die Diagrammsicherung durch das vorhandene Wiki-Backup abgedeckt.

Wenn das Wiki selbst noch nicht feststeht, sollten Sie diese Entscheidung zuerst treffen. Auswahl zwischen BookStack, Wiki.js und Outline beschreibt die vorherige Entscheidung. Das Wiki bestimmt, wie ein Diagramm an eine Seite angehängt wird und welches dieser Tools Sie deshalb zusätzlich einbinden.

Fehlerbilder und die angezeigten Zeichenfolgen

Der Zeicheneditor wird in BookStack geöffnet und lädt endlos. Der Ladeindikator wartet auf Diagrammdaten in spin=1. Mit proto=json sendet der Editor ein init-Ereignis, sobald er bereit ist, und erwartet als Antwort eine load-Aktion mit dem Diagramm. Der Ladeindikator bleibt daher aktiv, wenn dieser Austausch nicht abgeschlossen wird. Prüfen Sie, ob embed=1&proto=json&spin=1 im Wert von DRAWIO vorhanden ist und ob der Hostteil keinen Tippfehler enthält.

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

Kroki gibt 413 Request Entity Too Large zurück. Diese genaue Formulierung verwendet nginx für den Fehler. Der Proxy ist daher der erste Prüfpunkt. Kroki kann jedoch auch selbst einen 413-Fehler senden. In der Dokumentation wird dieser als Content Too Large bezeichnet. Der nginx-Standardwert für client_max_body_size beträgt 1 MB. Das ist die Grenze, die eine große PlantUML-Quelle erreicht, weil PlantUML innerhalb des Gateways gerendert wird. Auch Kroki's eigenes KROKI_MAX_BODY_SIZE hat standardmäßig den Wert 1mb. Diese Einstellung gilt jedoch nur für die Companion-Container von diagrams.net, Excalidraw und Mermaid. Eine große Mermaid-Quelle kann daher eine der beiden Grenzen erreichen. Erhöhen Sie zuerst client_max_body_size. Erhöhen Sie außerdem KROKI_MAX_BODY_SIZE im Companion-Container, wenn das Diagramm diesen durchläuft.

Mermaid schlägt fehl, während graphviz funktioniert. Das Gateway ist funktionsfähig, aber der Companion-Container 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 wie eine normale HTTP-Anfrage beantwortet, und die Sitzung startet nicht.

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

FAQ

Bewahrt Self-Hosting von draw.io meine Diagramme privat auf?

Der Anwendungscode liegt auf Ihrem Server. Das ist etwas anderes, als die Daten privat zu halten. draw.io rendert im Browser. Der Container enthält daher überhaupt kein 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, und lassen Sie ENABLE_DRAWIO_PROXY deaktiviert. Auch beim Export werden keine Daten nach außen übertragen: Die Anwendung konfiguriert keinen Exportdienst. PDF wird daher über den Druckdialog des Browsers erzeugt, und DRAWIO_SELF_CONTAINED hat keine Wirkung mehr.

Warum funktioniert die Zusammenarbeit mit meinem selbst gehosteten Excalidraw nicht?

Auf der Seite des offiziellen Images 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 außerdem einen Speicherdienst. Die Adressen beider Dienste werden beim Erstellen des Builds als Vite-Variablen wie VITE_APP_WS_SERVER_URL in das JavaScript-Bundle kompiliert. Das Setzen einer Umgebungsvariablen im laufenden Container hat daher keine Wirkung. Wenn Sie Ihren eigenen Room-Server verwenden möchten, 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 dem zugehörigen Mermaid-Container, 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 kodieren und ein <img>-Tag darauf verweisen lassen. Der Companion-Container steuert Chromium über Puppeteer, weil Mermaid eine Browser-Engine benötigt. Planen Sie daher den Speicherbedarf ein: KROKI_MERMAID_MAX_CONCURRENCY ist standardmäßig auf sechs gleichzeitige Renderings eingestellt.

Benötige ich vor diesen Tools eine Passwortabfrage?

Ja, denn keines dieser Tools verfügt über Benutzerkonten. draw.io und Excalidraw stellen jedem, der die URL kennt, den vollständigen Editor bereit. Kroki rendert jeden Text, der an den Dienst gesendet wird. Für die beiden Editoren reicht die HTTP-Basisauthentifizierung am Reverse Proxy aus. Kroki sollte in einem Docker-Netzwerk veröffentlicht werden, das auch vom Wiki verwendet wird, und nicht öffentlich erreichbar sein. Der Browser eines Lesers zeigt für ein <img> auf einer anderen Origin keine Anmeldeaufforderung an. Daher würde jedes eingebettete Diagramm für Benutzer ohne direkte Anmeldung bei Kroki nicht funktionieren.