Narzędzia do diagramów self-hosted: porównanie

Które narzędzie do tworzenia diagramów typu self-hosted wybrać?

Narzędzia do tworzenia diagramów typu self-hosted występują w dwóch wariantach, a ich architektura jest ważniejsza niż lista funkcji. draw.io oraz Excalidraw to aplikacje przeglądarkowe: kontener dostarcza kod JavaScript, przeglądarka wykonuje rysowanie, a serwer nigdy nie przetwarza treści diagramu. Kroki działa odwrotnie. Użytkownik przesyła tekst diagramu przez HTTP, a serwer odsyła gotowy obraz, co oznacza, że każdy diagram przechodzi przez własną infrastrukturę.

Wybierz draw.io, jeśli potrzebujesz pełnego edytora zintegrowanego z wiki. Wybierz Excalidraw, jeśli potrzebujesz szybkiego szkicownika i akceptujesz fakt, że dane nie są zapisywane poza przeglądarką, w której powstał rysunek. Wybierz Kroki, jeśli diagramy są zapisane w formie tekstowej i przechowywane w repozytorium git obok opisywanego kodu.

Co faktycznie zmienia samodzielne hostowanie narzędzia do tworzenia diagramów

Należy precyzyjnie określić, które elementy mają styczność z serwerem, ponieważ ten fakt decyduje o tym, czy samodzielne hostowanie zapewnia prywatność, czy jedynie dostępność.

• draw.io renderuje w przeglądarce. Kontener serwuje kod aplikacji. Plik trafia tam, gdzie użytkownik wskaże edytorowi miejsce zapisu.
• Excalidraw renderuje w przeglądarce i przechowuje bieżącą scenę w pamięci lokalnej przeglądarki. Po stronie serwera nie są zapisywane żadne dane.
• Kroki renderuje po stronie serwera. Zarówno źródło diagramu, jak i gotowy obraz znajdują się wewnątrz kontenera.

Tylko w trzecim przypadku dane trafiają na sprzęt, nad którym sprawowana jest kontrola. W dwóch pierwszych przypadkach samodzielne hostowanie zapewnia kontrolę nad zasobami i dostępność: kod JavaScript pochodzi z własnego hosta, więc edytor działa nawet wtedy, gdy zewnętrzny dostawca ma awarię, zmienia regulamin lub staje się niedostępny z danej sieci. Dla niektórych zespołów ma to wymierną wartość. Jest to jednak inne założenie niż stwierdzenie, że "diagram nigdy nie opuszcza budynku".

draw.io: oficjalny kontener, który niczego nie przechowuje

Projekt publikuje własny obraz, a szybki start opisany w pliku README sprowadza się do jednej linii.

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

To polecenie publikuje edytor na każdym adresie IP dostępnym dla serwera. Na serwerze VPS należy powiązać opublikowany port z interfejsem loopback i uzyskać do niego dostęp przez reverse proxy lub tunel SSH.

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

Otwórz http://127.0.0.1:8080/?offline=1&https=0 przez tunel. W pliku README ?offline=1 określono jako „funkcję bezpieczeństwa, która wyłącza obsługę pamięci masowej w chmurze”. Bez niej edytor oferuje Google Drive, OneDrive oraz GitHub jako miejsca zapisu, co oznacza serwery podmiotów zewnętrznych.

Powiązanie z 127.0.0.1 sprawia, że port nie jest dostępny z publicznego Internetu. Zwykłe -p 8080:8080 nie jest filtrowane przez ufw, ponieważ Docker wstawia własne reguły iptables przed łańcuchy zarządzane przez ufw. W rezultacie firewall wydaje się poprawnie skonfigurowany, podczas gdy port odpowiada na zapytania z zewnątrz. Publikowanie w Dockerze z pominięciem ufw opisuje ten mechanizm oraz sposób jego naprawy.

Dwie zmienne środowiskowe mają znaczenie, gdy edytor nie działa na 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"

Końcowy ukośnik nie jest błędem. W pliku README DRAWIO_SERVER_URL zdefiniowano jako „Publiczny adres URL wdrożenia z końcowym ukośnikiem”, a DRAWIO_BASE_URL jako „Ten sam adres URL bez końcowego ukośnika”, używany przez przeglądarkę, lightbox oraz ścieżki kodu osadzonego. Jeśli edytor jest udostępniany w podkatalogu, takim jak https://www.example.com/drawio/, obie wartości muszą zawierać tę ścieżkę, ponieważ aplikacja buduje na ich podstawie adresy URL przeglądarki i osadzania.

Trwałość danych: brak, zgodnie z założeniami projektowymi. W pliku Compose nie zdefiniowano żadnego wolumenu, ponieważ kontener nie przechowuje danych diagramów. Plik .drawio to kod XML, który edytor przekazuje do przeglądarki, a wybrany cel zapisu decyduje o jego lokalizacji: pobranie na własny komputer lub aplikacja, w której osadzono edytor. Należy tworzyć kopie zapasowe tego miejsca docelowego. Jeśli jest to folder na serwerze VPS, ochronie podlega ten folder oraz menedżer plików używany do uzyskania do niego dostępu, ponieważ draw.io nie przechowuje żadnych kopii.

Co nadal opuszcza serwer. Mniej niż wcześniej, ponieważ eksport nie jest już nigdzie przesyłany. Plik README wymienia teraz EXPORT_URL oraz DRAWIO_SELF_CONTAINED jako usunięte zmienne, które nie mają żadnego wpływu. Wskazywały one edytorowi oddzielny obraz jgraph/export-server, którego cykl życia dobiegł końca. Punkt wejścia (entrypoint) zapisuje teraz window.EXPORT_URL = null w PreConfig.js, co informuje edytor, że usługa eksportu nie istnieje. W praktyce opcja Export as > PDF otwiera okno dialogowe drukowania przeglądarki, więc opcja dołączenia kopii diagramu nie jest oferowana dla formatu PDF, a eksport do PNG i JPEG renderowany po stronie serwera jest ukryty. Eksport do PNG, JPEG i SVG renderowany w przeglądarce nadal działa. ENABLE_DRAWIO_PROXY jest domyślnie wyłączone i aktywuje punkt końcowy /proxy, który pobiera zewnętrzne adresy URL obrazów w imieniu przeglądarki, więc należy pozostawić tę opcję wyłączoną, chyba że jest wymagana.

Excalidraw: statyczny pakiet bez zaplecza serwerowego

Oficjalna strona obrazu podaje następujące polecenie.

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

Przenieś opublikowany port na interfejs loopback z tego samego powodu, co poprzednio.

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

Wewnątrz kontenera nginx serwuje skompilowany pakiet JavaScript na porcie 80. Opublikowany obraz zajmuje około 41 MB po kompresji (Docker Hub, październik 2026), co wskazuje na minimalną zawartość. Brak bazy danych, magazynu sesji czy katalogu przesyłania plików, ponieważ na serwerze nie ma nic do przechowywania.

Strona obrazu jasno określa ograniczenie: "W tej chwili samodzielne hostowanie własnej instancji nie wspiera funkcji udostępniania ani współpracy". Przyciski nadal znajdują się w interfejsie, dlatego warto znać przyczynę. Współpraca w czasie rzeczywistym wymaga serwera websocket, publikowanego oddzielnie jako excalidraw/excalidraw-room. Link do udostępniania wymaga usługi przechowywania, która przetrzyma zaszyfrowaną scenę. Adresy obu usług są kompilowane do pakietu w czasie budowania jako zmienne Vite (VITE_APP_WS_SERVER_URL, VITE_APP_BACKEND_V2_GET_URL, VITE_APP_BACKEND_V2_POST_URL), a wartości produkcyjne w repozytorium wskazują na własne usługi hostowane przez Excalidraw. Vite podstawia te wartości podczas budowania, więc stają się one dosłownymi ciągami znaków wewnątrz JavaScriptu. Ustawienie ich jako zmiennych środowiskowych kontenera nic nie zmienia, ponieważ żaden kod nie odczytuje ich w czasie wykonywania. Skierowanie współpracy na własny serwer pokoi wymaga zbudowania frontendu ze źródeł z własnymi wartościami. Sprawdź stan tego serwera przed planowaniem pracy: według stanu na październik 2026, najnowsze wypchnięcie obrazu excalidraw/excalidraw-room na Docker Hub miało miejsce w grudniu 2023.

Gdzie faktycznie znajduje się rysunek. Scena znajduje się w pamięci lokalnej przeglądarki, na danym urządzeniu, dla danego źródła (origin). Otwórz ten sam adres URL w oknie prywatnym, a płótno będzie puste; to najszybszy sposób, aby się o tym przekonać. Wyczyść dane witryny, a rysunek zostanie usunięty; nie ma kopii serwerowej, z której można by go przywrócić. Dlatego należy uczyć użytkowników korzystania z opcji "Save to..." i przechowywania pliku .excalidraw, który jest formatem JSON, w miejscu podlegającym kopiom zapasowym. Współdzielona instancja zapewnia każdej osobie własne, prywatne płótno. Traktuj to jako osobisty szkicownik, który jest jedynie hostowany na serwerze.

Kroki: diagramy jako kod, renderowane na własnym serwerze

Kroki to bramka HTTP obsługująca wiele silników renderujących. Wysyłasz tekst metodą POST i otrzymujesz w odpowiedzi plik SVG lub PNG. Graphviz, PlantUML, D2 oraz kilka innych narzędzi są wbudowane w obraz bramki. Renderowanie Mermaid, BPMN i Excalidraw odbywa się w osobnych kontenerach, dlatego użycie Compose jest najbardziej uzasadnionym sposobem uruchomienia tego rozwiązania. Poniżej znajduje się przykład z dokumentacji 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 nie publikuje żadnych portów na hoście, dzięki czemu kontenery towarzyszące są dostępne wyłącznie dla bramki wewnątrz sieci Compose. Jest to pożądane zachowanie. Zmień linię bramki na "127.0.0.1:8000:8000", chyba że wiki korzystająca z usługi działa na innym hoście. Jeśli nie tworzyłeś wcześniej pliku Compose na serwerze, uruchamianie Docker Compose na VPS opisuje strukturę plików oraz cykl docker compose up -d.

Wykonaj dwa testy poprawności w podanej kolejności, ponieważ ich ewentualne niepowodzenia wynikają z różnych przyczyn.

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 działa wewnątrz bramki, więc wygenerowanie dokumentu SVG potwierdza poprawność działania samej bramki. Następnie przetestuj ścieżkę komunikacji między kontenerami.

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

Plik SVG uzyskany z drugiego polecenia potwierdza, że KROKI_MERMAID_HOST zostało poprawnie rozwiązane, a kontener towarzyszący odpowiedział. Jeśli pierwszy test kończy się powodzeniem, a drugi nie, problem leży w komunikacji między kontenerami; przed modyfikacją składni diagramu zapoznaj się z docker compose logs kroki.

Formularz GET koduje diagram bezpośrednio w adresie URL, co pozwala na osadzanie obrazów w wiki bez użycia wtyczek. Dokumentacja zawiera odpowiedni enkoder.

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'))"

W systemie Ubuntu polecenie to zwraca python: command not found, ponieważ system dostarcza python3 i nie zawiera niewersjonowanego python. Użyj python3. Wynik należy dodać na końcu adresu URL w formacie /{diagram-type}/{output-format}/{encoded-diagram}, co pozwala na użycie dowolnego znacznika <img>. Istnieje ograniczenie: KROKI_MAX_URI_LENGTH domyślnie wynosi 4096 bajtów, więc długie diagramy muszą być przesyłane metodą POST.

Kroki przetwarza przesłany tekst, dlatego kluczowe są ustawienia bezpieczeństwa. KROKI_SAFE_MODE domyślnie przyjmuje wartość SECURE, co jest najbardziej restrykcyjnym z trzech poziomów, a KROKI_PLANTUML_ALLOW_INCLUDE domyślnie ustawiono na false. Te wartości domyślne wynikają z faktu, że dyrektywa !include w PlantUML odczytuje pliki i adresy URL z perspektywy silnika renderującego. Złagodzenie tych ustawień w publicznie dostępnym punkcie końcowym umożliwia użytkownikom zewnętrznym odczyt plików z wnętrza kontenera. Nie zmieniaj tych ustawień, chyba że znasz konkretną ścieżkę dostępu, którą należy uwzględnić, a następnie wskaż ją za pomocą KROKI_PLANTUML_INCLUDE_PATH.

Pamięć: co najbardziej obciąża mały VPS

Kolejność jest przewidywalna, gdy wiadomo, co uruchamia każdy kontener.

• Obraz Excalidraw to nginx serwujący pliki statyczne. Jest to zdecydowanie najtańszy z tych trzech komponentów.
• draw.io uruchamia Tomcat, serwer aplikacji Java, więc zawiera JVM (Java virtual machine), niezależnie od tego, czy ktoś aktualnie rysuje.
• Bramka Kroki to również usługa Java, dostarczana jako plik jar w przypadku instalacji ręcznych.
• Komponent mermaid jest najbardziej kosztowny. Jego Dockerfile instaluje Chromium i ustawia PUPPETEER_EXECUTABLE_PATH=/usr/lib/chromium/chrome, ponieważ Mermaid renderuje diagramy w rzeczywistym silniku przeglądarki.

Wartości w stanie spoczynku mówią zatem niewiele. Kluczową liczbą jest skok zużycia podczas renderowania diagramu, a KROKI_MERMAID_MAX_CONCURRENCY domyślnie wynosi 6, co oznacza, że jednocześnie może być przetwarzanych sześć procesów renderowania w przeglądarce. Należy dokonać pomiaru na własnym serwerze, zamiast polegać na publikowanych danych.

docker stats --no-stream
docker system df

Uruchom pierwsze polecenie, gdy system jest w stanie spoczynku, a następnie ponownie podczas renderowania dużego diagramu mermaid w pętli. Jeśli skok zużycia jest zbyt duży dla małego planu, należy nałożyć limity, zamiast zgadywać: ustawianie limitów pamięci dla usługi Compose pokazuje składnię oraz zachowanie kontenera po osiągnięciu limitu. Rezygnacja z komponentu mermaid jest również poprawnym rozwiązaniem, ponieważ bramka nadal obsługuje wszystkie wbudowane w nią mechanizmy renderowania.

Żaden z tych programów nie zawiera modelu użytkownika, więc należy go dodać przed nimi

draw.io nie posiada kont. Excalidraw nie posiada kont. Kroki odpowiada na każde żądanie, które do niego dotrze. Każde logowanie musi odbywać się na poziomie proxy.

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

htpasswd -c tworzy plik i nadpisuje istniejący, dlatego przy pierwszym uruchomieniu należy przekazać -c, a później już nigdy więcej.

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

Zastosuj zmiany za pomocą sudo nginx -t && sudo systemctl reload nginx. Część nginx -t jest kluczowa: przeładowanie przy błędnej konfiguracji pozostawia aktywną starą konfigurację, dzięki czemu serwis nadal działa, a wprowadzone zmiany nie wchodzą w życie. Konfiguracja reverse proxy, wyjaśnienie linia po linii omawia blok nagłówków oraz ścieżki certyfikatów, które pominięto w tym fragmencie.

Uwierzytelnianie podstawowe (Basic authentication) nie jest odpowiednim narzędziem dla Kroki i warto zrozumieć dlaczego. Strona wiki osadza obraz Kroki za pomocą znacznika <img>. Przeglądarka czytelnika pobiera ten adres URL jako zasób podrzędny typu cross-origin. Dołączy ona poświadczenia Basic, jeśli już posiada je dla hosta Kroki, jednak współczesne przeglądarki nie wyświetlają monitu o logowanie dla obrazów cross-origin. W rezultacie każdy czytelnik, który nie zalogował się bezpośrednio do hosta Kroki, otrzyma błąd 401 i zobaczy każdy diagram na stronie jako uszkodzony obraz. Zamiast tego należy odizolować Kroki od publicznego Internetu. Należy umieścić je w tej samej sieci Docker, co kontener wiki, i pozwolić wiki łączyć się z nim poprzez nazwę usługi, bez publikowania jakichkolwiek portów na hoście. Jak sieci Compose rozwiązują nazwy usług to element, który umożliwia takie działanie.

Diagramy przechowywane obok wiki hostowanego samodzielnie

Jest to najczęstszy powód, dla którego użytkownicy decydują się na takie rozwiązanie. Strona wiki wymaga ilustracji, a nikt nie chce, aby była ona zrzutem ekranu z czyjegoś laptopa.

BookStack posiada wbudowany mechanizm integracji z edytorem hostowanym samodzielnie. Domyślny adres URL osadzania to https://embed.diagrams.net/?embed=1&proto=json&spin=1&configure=1, a jedna linia w .env pozwala na przekierowanie go do własnego kontenera.

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

Należy dokładnie skopiować ciąg zapytania. Dokumentacja BookStack podaje, że embed=1&proto=json&spin=1 „są wymagane do poprawnego działania integracji z BookStack”, ponieważ określają protokół komunikatów JSON, za pomocą którego obie strony wymieniają dane. Ta sama strona wskazuje na stealth=1 „jeśli nie chcesz korzystać z zewnętrznych usług”, co jest opcją wybieraną w przypadku, gdy celem hostowania samodzielnego było zablokowanie połączeń wychodzących. Po skonfigurowaniu tego połączenia, BookStack zapisuje rysunek w swoim własnym magazynie obrazów obok strony, dzięki czemu kopia zapasowa wiki zawiera również kopie diagramów.

Jeśli wybór oprogramowania wiki nie został jeszcze dokonany, należy zacząć od tego kroku. Wybór między BookStack, Wiki.js a Outline to wcześniejsza decyzja, ponieważ to wiki determinuje sposób dołączania diagramu do strony, a tym samym wskazuje, które z tych narzędzi należy zintegrować.

Tryby awarii i komunikaty, które zobaczysz

Edytor diagramów w BookStack otwiera się i wyświetla ciągłe ładowanie. Wskaźnik ładowania to spin=1 oczekiwanie na dane diagramu. W ramach proto=json edytor wysyła zdarzenie init, gdy jest gotowy, i oczekuje w odpowiedzi akcji load zawierającej diagram. Jeśli ta wymiana nie zostanie ukończona, wskaźnik ładowania pozostaje widoczny. Sprawdź, czy embed=1&proto=json&spin=1 znajduje się w Twojej wartości DRAWIO oraz czy część określająca hosta nie zawiera literówek.

Ramka edytora pozostaje pusta w wiki działającym przez HTTPS. Konsola przeglądarki zgłasza błąd mixed content, próbując załadować http:// wewnątrz https://. Przeglądarka blokuje ramkę i draw.io nie uruchamia się. Udostępnij edytor przez HTTPS.

Kroki zwraca 413 Request Entity Too Large. To dokładne sformułowanie, którego nginx używa do nazwania błędu, więc proxy jest pierwszym podejrzanym. Kroki może jednak samodzielnie wysłać kod 413, co w dokumentacji określane jest jako Content Too Large. Domyślna wartość client_max_body_size w nginx wynosi 1 MB i jest to limit, który osiąga duże źródło PlantUML, ponieważ PlantUML renderuje się wewnątrz gatewaya. Własny parametr KROKI_MAX_BODY_SIZE w Kroki również domyślnie wynosi 1mb, ale dotyczy on tylko kontenerów towarzyszących dla diagrams.net, Excalidraw i Mermaid. Duże źródło Mermaid może więc osiągnąć którykolwiek z tych limitów. Najpierw zwiększ client_max_body_size, a jeśli diagram przechodzi przez kontener towarzyszący, zwiększ również KROKI_MAX_BODY_SIZE.

Mermaid nie działa, podczas gdy graphviz działa poprawnie. Gateway jest sprawny, ale kontener towarzyszący nie jest osiągalny. Sprawdź, czy usługa działa za pomocą docker compose ps, a następnie sprawdź, czy KROKI_MERMAID_HOST zgadza się z nazwą usługi. Domyślnie przyjmuje ona wartość 127.0.0.1, co wewnątrz kontenera gatewaya oznacza sam gateway.

Współpraca w Excalidraw nie nawiązuje połączenia. Jeśli zbudowałeś frontend korzystający z własnego serwera pokoi i umieściłeś go za nginx, proxy musi dokonać aktualizacji połączenia za pomocą proxy_set_header Upgrade $http_upgrade; oraz proxy_set_header Connection "upgrade";. Bez nich uzgadnianie websocket jest traktowane jako zwykłe żądanie HTTP i sesja nigdy się nie rozpoczyna.

Płótno jest puste po wyczyszczeniu przeglądarki. Scena znajdowała się w pamięci lokalnej urządzenia i nie posiada kopii na serwerze. Rozwiązaniem jest wyrobienie nawyku, a nie zmiana ustawień: eksportuj plik .excalidraw dla każdego diagramu, który chcesz zachować.

FAQ

Czy self-hosting draw.io zapewnia prywatność diagramów?

Kod aplikacji znajduje się na serwerze, co nie jest tożsame z zapewnieniem prywatności danych. draw.io renderuje się w przeglądarce, więc kontener nigdy nie przechowuje diagramu. Prywatność zależy zatem od miejsca zapisu pliku oraz od tego, które połączenia wychodzące pozostawiono aktywne. Należy użyć ?offline=1, aby wyłączyć cele przechowywania w chmurze i pozostawić ENABLE_DRAWIO_PROXY wyłączone. Eksport również nie wysyła danych na zewnątrz: obraz nie konfiguruje żadnej usługi eksportu, więc plik PDF przechodzi przez okno dialogowe drukowania przeglądarki, a DRAWIO_SELF_CONTAINED nie ma już żadnego wpływu.

Dlaczego współpraca nie działa w self-hosted Excalidraw?

Oficjalna strona obrazu informuje, że self-hosting „nie wspiera funkcji udostępniania ani współpracy”. Współpraca na żywo wymaga oddzielnego serwera websocket excalidraw/excalidraw-room, a linki do udostępniania wymagają usługi przechowywania danych. Adresy obu tych elementów są kompilowane do pakietu JavaScript w czasie budowania jako zmienne Vite, takie jak VITE_APP_WS_SERVER_URL, więc ustawienie zmiennej środowiskowej w uruchomionym kontenerze nie przynosi efektu. Użycie własnego serwera pokoi wymaga zbudowania frontendu ze źródeł z własnymi wartościami.

Jak renderować diagramy Mermaid na własnym serwerze?

Należy uruchomić Kroki wraz z towarzyszącym mu kontenerem mermaid i ustawić KROKI_MERMAID_HOST na nazwę tej usługi. Następnie należy wysłać tekst diagramu metodą POST do /mermaid/svg i odczytać SVG z odpowiedzi lub zakodować diagram w adresie URL GET i wskazać na niego tagiem <img>. Kontener towarzyszący obsługuje Chromium przez Puppeteer, ponieważ Mermaid wymaga silnika przeglądarki, więc należy zaplanować odpowiednią ilość pamięci: KROKI_MERMAID_MAX_CONCURRENCY domyślnie obsługuje sześć renderowań jednocześnie.

Czy potrzebuję hasła przed tymi narzędziami?

Tak, ponieważ żadne z nich nie posiada systemu kont. draw.io i Excalidraw udostępniają pełny edytor każdemu, kto zna adres URL, a Kroki renderuje każdy przesłany do niego tekst. Uwierzytelnianie podstawowe (Basic Auth) na reverse proxy jest wystarczające dla obu edytorów. W przypadku Kroki należy zachować usługę nieopublikowaną w sieci Docker współdzielonej z wiki, ponieważ przeglądarka czytelnika nie wyświetli monitu o logowanie dla <img> z innego źródła, co spowodowałoby niedziałanie każdego osadzonego diagramu dla użytkownika, który nie zalogował się bezpośrednio do Kroki.