가이드

작성자 Matt Connor 2026-08-18 · 업데이트됨 2026-08-21

셀프 호스팅 다이어그램 도구 비교: draw.io, Excalidraw, Kroki

Q: 자체 서버에서 Mermaid 다이어그램을 렌더링하려면 어떻게 해야 합니까?

Kroki를 해당 mermaid 컴패니언 컨테이너와 함께 실행하고 KROKI_MERMAID_HOST을 해당 서비스 이름으로 설정하십시오. 그런 다음 다이어그램 텍스트를 /mermaid/svg로 POST하여 응답에서 SVG를 읽거나, 다이어그램을 GET URL로 인코딩한 뒤 태그가 이를 가리키도록 하십시오. Mermaid는 브라우저 엔진이 필요하므로 컴패니언 컨테이너는 Puppeteer를 통해 Chromium을 구동합니다. 따라서 메모리 사용량을 고려하십시오. KROKI_MERMAID_MAX_CONCURRENCY은 기본적으로 6개의 렌더링을 동시에 처리하도록 설정되어 있습니다.

draw.io, Excalidraw, Kroki를 직접 호스팅할 때 데이터가 서버를 거치는지 확인하십시오. 브라우저 렌더링 방식과 서버 렌더링 방식의 차이를 비교하여 개인정보 보호와 가용성 측면에서 어떤 도구가 적합한지 결정하는 방법을 안내합니다.

어떤 셀프 호스팅 다이어그램 도구를 실행해야 합니까?

셀프 호스팅 다이어그램 도구는 두 가지 형태로 나뉘며, 기능 목록보다 이 형태가 더 중요합니다. draw.io와 Excalidraw는 브라우저 애플리케이션입니다. 컨테이너는 JavaScript를 제공하고, 사용자의 브라우저가 직접 그리기를 수행하며, 서버는 다이어그램 내용을 전혀 볼 수 없습니다. 반면 Kroki는 정반대입니다. HTTP를 통해 다이어그램 텍스트를 전송하면 서버가 이미지를 반환하므로, 모든 다이어그램 데이터가 사용자의 서버를 거쳐 가게 됩니다.

위키와 함께 완전한 편집기를 사용하고 싶다면 draw.io를 실행하십시오. 빠른 스케치 패드가 필요하고 브라우저 외부에는 아무것도 저장되지 않아도 괜찮다면 Excalidraw를 실행하십시오. 다이어그램이 코드와 함께 git에 저장되는 텍스트 형태라면 Kroki를 실행하십시오.

다이어그램 도구를 직접 호스팅할 때 실제로 바뀌는 점

어떤 부분이 서버와 상호작용하는지 정확히 파악해야 합니다. 이 사실 하나가 직접 호스팅을 통해 개인정보 보호를 얻는지, 아니면 단순히 가용성만 확보하는지를 결정하기 때문입니다.

draw.io는 브라우저에서 렌더링됩니다. 컨테이너는 애플리케이션 코드만 제공합니다. 파일은 편집기에서 저장하도록 지정한 위치에 저장됩니다.
Excalidraw는 브라우저에서 렌더링되며 현재 장면을 해당 브라우저의 로컬 스토리지에 유지합니다. 서버 측에는 아무것도 기록되지 않습니다.
Kroki는 서버에서 렌더링됩니다. 다이어그램 소스와 완성된 이미지 모두 컨테이너 내부에 존재합니다.

세 번째 경우에만 데이터가 사용자가 제어하는 하드웨어로 이동합니다. 앞의 두 경우에는 직접 호스팅을 통해 자산 제어권과 가용성을 얻게 됩니다. JavaScript가 호스트에서 제공되므로, 제3자 서비스에 장애가 발생하거나 약관이 변경되거나 네트워크에서 접근할 수 없게 되어도 편집기는 계속 작동합니다. 이는 일부 팀에게는 실질적인 가치가 있습니다. 하지만 이는 "다이어그램이 건물 밖으로 절대 나가지 않는다"는 주장과는 다른 의미입니다.

draw.io: 데이터를 저장하지 않는 공식 컨테이너

이 프로젝트는 자체 이미지를 배포하며, README에 기재된 퀵 스타트 명령은 단 한 줄입니다.

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

이 명령은 서버의 모든 주소에서 에디터를 실행합니다. VPS 환경이라면 게시된 포트를 루프백(loopback) 주소에 바인딩하고, 리버스 프록시나 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가 ufw가 관리하는 체인보다 앞서 자체 iptables 규칙을 삽입하기 때문입니다. 따라서 방화벽 설정은 올바르게 보이지만 실제로는 포트가 외부의 모든 요청에 응답하게 됩니다. 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을 "뒤에 슬래시가 포함된 공개 배포 URL"로, DRAWIO_BASE_URL을 "뒤에 슬래시가 없는 동일한 URL"로 정의합니다. 후자는 뷰어, 라이트박스, 임베드 코드 경로에서 사용됩니다. 만약 https://www.example.com/drawio/와 같은 하위 경로에서 에디터를 서비스한다면, 애플리케이션이 뷰어 및 임베드 URL을 이 변수들로부터 생성하므로 두 값 모두 해당 하위 경로를 포함해야 합니다.

데이터 영속성: 데이터는 저장되지 않으며, 이는 설계 의도입니다. 컨테이너가 다이어그램 데이터를 보관하지 않으므로 해당 Compose 파일에는 볼륨 설정이 없습니다. .drawio 파일은 에디터가 브라우저로 전달하는 XML일 뿐이며, 저장 위치는 사용자가 선택합니다. 사용자의 로컬 컴퓨터로 다운로드하거나 에디터를 임베드한 애플리케이션으로 전달됩니다. 해당 저장 대상을 백업하십시오. 만약 VPS의 특정 폴더를 저장 대상으로 사용한다면, draw.io는 어떠한 데이터도 복사본을 남기지 않으므로 해당 폴더와 해당 폴더에 접근하기 위해 사용하는 파일 관리자를 보호해야 합니다.

서버 외부로 데이터가 나가는 경우. PDF 내보내기가 가장 대표적인 사례입니다. README는 DRAWIO_SELF_CONTAINED을 "내보내기 서버를 직접 호출하는 대신 Tomcat의 ExportProxyServlet(/service/0)을 통해 내보내기 요청을 라우팅하려면 1로 설정"하라고 설명합니다. 이를 반대로 해석하면, 기본 설정에서는 내보내기 호출이 배포 환경 내부에서만 처리되지 않는다는 뜻입니다. 또한 이 프로젝트는 자체 하드웨어에서 렌더링을 수행하려는 사용자를 위해 draw.io의 "독립형 이미지 내보내기 서버"인 jgraph/export-server를 제공합니다. ENABLE_DRAWIO_PROXY은 기본적으로 비활성화되어 있으며, 이를 활성화하면 브라우저를 대신하여 외부 이미지 URL을 가져오는 /proxy 엔드포인트가 열립니다. 반드시 필요한 경우가 아니라면 비활성화 상태로 두십시오.

Excalidraw: 서버가 없는 정적 번들

공식 이미지 페이지는 다음 명령어를 제공합니다.

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

이전과 같은 이유로 게시된 포트를 루프백으로 이동합니다.

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

컨테이너 내부에서 nginx는 포트 80에서 컴파일된 JavaScript 번들을 서비스합니다. 게시된 이미지의 크기는 압축 상태에서 약 41 MB(Docker Hub, 2026년 8월 기준)이며, 이는 포함된 내용이 매우 적음을 의미합니다. 서버에 저장할 데이터가 없으므로 데이터베이스, 세션 저장소, 업로드 디렉터리도 없습니다.

이미지 페이지는 제한 사항을 명확히 밝히고 있습니다. "현재, 자체 인스턴스를 호스팅하는 경우 공유 또는 협업 기능은 지원하지 않습니다." 인터페이스에는 여전히 버튼이 존재하므로 그 이유를 알아둘 필요가 있습니다. 실시간 협업에는 웹소켓 서버가 필요하며, 이는 excalidraw/excalidraw-room로 별도 게시됩니다. 공유 링크에는 암호화된 장면을 보관할 저장소 서비스가 필요합니다. 두 주소 모두 빌드 시점에 Vite 변수(VITE_APP_WS_SERVER_URL, VITE_APP_BACKEND_V2_GET_URL, VITE_APP_BACKEND_V2_POST_URL)로 번들에 컴파일되며, 저장소의 프로덕션 값은 Excalidraw가 직접 호스팅하는 서비스를 가리킵니다. Vite는 빌드 중에 해당 값을 대체하므로, 결과적으로 JavaScript 내부에 리터럴 문자열로 남게 됩니다. 런타임에 이를 읽는 코드가 없으므로 컨테이너 환경 변수로 설정해도 아무런 변화가 없습니다. 협업 기능을 자체 룸 서버로 연결하려면 고유한 값을 사용하여 소스에서 프론트엔드를 직접 빌드해야 합니다. 계획을 세우기 전에 해당 서버의 상태를 확인하십시오. Docker Hub의 excalidraw/excalidraw-room 이미지는 2026년 8월 기준으로 2년 넘게 재빌드되지 않았습니다.

그림이 실제로 저장되는 위치. 장면은 해당 기기의 브라우저 로컬 스토리지에, 해당 오리진(origin) 단위로 저장됩니다. 시크릿 창에서 동일한 URL을 열면 캔버스가 비어 있는 것을 볼 수 있으며, 이것이 이를 확인하는 가장 빠른 방법입니다. 사이트 데이터를 삭제하면 그림도 삭제되며, 복구할 서버 복사본도 존재하지 않습니다. 따라서 사용자들에게 "Save to..." 기능을 사용하여 JSON 형식인 .excalidraw 파일을 백업이 이루어지는 곳에 보관하도록 교육하십시오. 공유 인스턴스는 모든 사람에게 각자의 개인 캔버스를 제공합니다. 이를 호스팅된 개인용 스케치 패드로 간주하십시오.

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 파일을 작성해 본 적이 없다면 VPS에서 Docker Compose 실행하기에서 파일 구조와 docker compose up -d 주기를 확인하십시오.

두 가지 스모크 테스트를 순서대로 실행하십시오. 실패 원인이 서로 다르기 때문입니다.

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로 인코딩하며, 이를 통해 위키는 별도의 플러그인 없이 이미지를 삽입할 수 있습니다. 문서에서 제공하는 인코더는 다음과 같습니다.

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를 사용하십시오. 출력값은 /{diagram-type}/{output-format}/{encoded-diagram} 형태의 URL 끝에 붙이며, 모든 <img> 태그에서 이를 가리킬 수 있습니다. 한계점도 존재합니다. KROKI_MAX_URI_LENGTH의 기본값은 4096 바이트이므로, 긴 다이어그램은 반드시 POST로 보내야 합니다.

Kroki는 사용자가 보낸 텍스트를 읽으므로 보안 설정이 매우 중요합니다. KROKI_SAFE_MODE의 기본값은 세 단계 중 가장 제한적인 SECURE이며, KROKI_PLANTUML_ALLOW_INCLUDE의 기본값은 false입니다. 이러한 기본값은 PlantUML의 !include 지시어가 렌더러의 관점에서 파일과 URL을 읽기 때문에 존재합니다. 누구나 접근할 수 있는 엔드포인트에서 이 설정을 완화하면, 컨테이너 내부에서 실행되는 파일 읽기 도구를 인터넷에 공개하는 꼴이 됩니다. 필요한 include 경로를 정확히 알고 KROKI_PLANTUML_INCLUDE_PATH로 지정하는 경우가 아니라면 기본값을 변경하지 마십시오.

메모리: 소규모 VPS에서 부담이 되는 요소

각 컨테이너가 무엇을 실행하는지 알면 순서는 예측 가능합니다.

Excalidraw 이미지는 정적 파일을 제공하는 nginx입니다. 셋 중 가장 적은 리소스를 사용합니다.
draw.io는 Java 애플리케이션 서버인 Tomcat을 실행하므로, 사용자가 그림을 그리지 않아도 JVM(Java virtual machine)을 구동합니다.
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는 도달하는 모든 요청에 응답합니다. 따라서 모든 로그인 처리는 프록시에서 수행해야 합니다.

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)를 수행하면 이전 설정이 그대로 유지되므로, 사이트는 정상 작동하지만 변경 사항은 적용되지 않습니다. 리버스 프록시 설정, 한 줄씩 상세 설명에서 이 코드 조각에 생략된 헤더 블록과 인증서 경로를 다룹니다.

Kroki에 기본 인증(Basic authentication)을 사용하는 것은 적절하지 않으며, 그 이유는 이해할 필요가 있습니다. 위키 페이지는 <img> 태그를 사용하여 Kroki 이미지를 삽입합니다. 독자의 브라우저는 해당 URL을 하위 리소스로 가져오는데, 이때 다른 오리진(origin)으로 자격 증명을 전송하지 않습니다. 따라서 요청은 401 오류를 반환하며 페이지의 모든 다이어그램이 깨진 이미지로 표시됩니다. Kroki를 공용 인터넷에 노출하지 마십시오. 위키 컨테이너와 동일한 Docker 네트워크에 배치하고, 호스트에 포트를 전혀 공개하지 않은 상태에서 위키가 서비스 이름으로 접근하도록 설정하십시오. Compose 네트워크에서 서비스 이름을 확인하는 방법이 이 구성을 가능하게 하는 핵심입니다.

자체 호스팅 위키와 함께 사용하는 다이어그램

이것이 사람들이 이러한 구성을 원하는 일반적인 이유입니다. 위키 페이지에는 그림이 필요하며, 누구나 그 그림이 누군가의 노트북에서 찍은 스크린샷이기를 원하지는 않습니다.

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 핸드셰이크를 기다리지만 응답이 오지 않는 상태입니다. DRAWIO 값에 embed=1&proto=json&spin=1가 포함되어 있는지, 호스트 부분에 오타가 없는지 확인하십시오.

HTTPS 위키에서 편집기 프레임이 빈 화면으로 유지됩니다. 브라우저 콘솔에 https:// 내부에서 http://를 불러오려다 혼합 콘텐츠(mixed content) 오류가 발생했다고 기록됩니다. 브라우저가 프레임을 차단하여 draw.io가 실행되지 않는 것입니다. 편집기를 HTTPS로 제공하십시오.

Kroki가 413 Request Entity Too Large을 반환합니다. 이 메시지는 Kroki가 아니라 nginx에서 보낸 것입니다. nginx의 client_max_body_size 기본값은 1 MB이고 Kroki 자체의 KROKI_MAX_BODY_SIZE 기본값은 1mb이므로, 큰 PlantUML 소스 파일은 둘 중 더 낮은 제한에 걸리게 됩니다. 두 값을 모두 높이십시오.

Graphviz는 작동하는데 Mermaid는 실패합니다. 게이트웨이는 정상이나 컴패니언 서비스에 도달하지 못하는 상태입니다. 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를 직접 호스팅하면 다이어그램이 비공개로 유지됩니까?

애플리케이션 코드를 서버에 두는 것과 데이터를 비공개로 유지하는 것은 별개의 문제입니다. draw.io는 브라우저에서 렌더링되므로 컨테이너는 다이어그램을 전혀 저장하지 않습니다. 따라서 개인정보 보호는 파일을 어디에 저장하는지, 그리고 어떤 아웃바운드 호출을 활성화해 두었는지에 따라 달라집니다. ?offline=1을 사용하여 클라우드 저장소 대상을 비활성화하십시오. 또한 DRAWIO_SELF_CONTAINED=1를 설정하고 직접 jgraph/export-server을 실행하지 않는 한, 내보내기 요청은 내보내기 서버로 전송된다는 점을 기억하십시오.

직접 호스팅하는 Excalidraw에서 협업 기능이 작동하지 않는 이유는 무엇입니까?

공식 이미지 페이지에 따르면 직접 호스팅은 "공유 또는 협업 기능을 지원하지 않습니다". 실시간 협업을 위해서는 별도의 excalidraw/excalidraw-room 웹소켓 서버가 필요하며, 공유 링크를 사용하려면 저장소 서비스가 필요합니다. 두 주소 모두 빌드 시점에 VITE_APP_WS_SERVER_URL와 같은 Vite 변수로 JavaScript 번들에 컴파일되므로, 실행 중인 컨테이너에 환경 변수를 설정해도 아무런 효과가 없습니다. 자체 룸 서버를 사용하려면 해당 값을 포함하여 소스 코드로부터 프론트엔드를 직접 빌드해야 합니다.

자체 서버에서 Mermaid 다이어그램을 렌더링하려면 어떻게 해야 합니까?

Kroki를 해당 mermaid 컴패니언 컨테이너와 함께 실행하고 KROKI_MERMAID_HOST을 해당 서비스 이름으로 설정하십시오. 그런 다음 다이어그램 텍스트를 /mermaid/svg로 POST하여 응답에서 SVG를 읽거나, 다이어그램을 GET URL로 인코딩한 뒤 <img> 태그가 이를 가리키도록 하십시오. Mermaid는 브라우저 엔진이 필요하므로 컴패니언 컨테이너는 Puppeteer를 통해 Chromium을 구동합니다. 따라서 메모리 사용량을 고려하십시오. KROKI_MERMAID_MAX_CONCURRENCY은 기본적으로 6개의 렌더링을 동시에 처리하도록 설정되어 있습니다.

이러한 도구 앞에 비밀번호를 설정해야 합니까?

네, 이 도구들 중 어떤 것도 계정 기능을 제공하지 않기 때문입니다. draw.io와 Excalidraw는 URL을 아는 누구에게나 전체 편집기 권한을 제공하며, Kroki는 전송된 모든 텍스트를 렌더링합니다. 두 편집기의 경우 리버스 프록시에서 기본 인증(Basic authentication)을 설정하는 것만으로 충분합니다. Kroki의 경우, 위키와 공유하는 Docker 네트워크 내부에 두고 외부에는 공개하지 마십시오. 독자의 브라우저에서 발생하는 <img> 요청은 다른 오리진으로 자격 증명을 전달하지 않으므로, 외부 공개 시 모든 삽입된 다이어그램이 깨지게 됩니다.

#diagrams#drawio#excalidraw#mermaid#kroki#docker