Self-hosted diyagram araçları karşılaştırması

Hangi self-hosted diyagram aracını çalıştırmalısınız?

Self-hosted diyagram araçları iki farklı yapıda sunulur ve bu yapı, özellik listesinden daha önemlidir. draw.io ve Excalidraw tarayıcı tabanlı uygulamalardır: container JavaScript kodunu sunar, çizim işlemini tarayıcınız gerçekleştirir ve sunucu diyagram içeriğini asla görmez. Kroki ise bunun tam tersidir. HTTP üzerinden metin tabanlı diyagram verisini gönderirsiniz ve sunucu size bir görsel döndürür; dolayısıyla her diyagram kendi makineniz üzerinden geçer.

Bir wiki yanında tam kapsamlı bir düzenleyici istiyorsanız draw.io çalıştırın. Hızlı bir karalama alanı istiyorsanız ve çizim yaptığınız tarayıcı dışında hiçbir yere kaydedilmemesini kabul ediyorsanız Excalidraw kullanın. Diyagramlarınız, tanımladıkları kodun yanında git içerisinde yaşayan metinlerden oluşuyorsa Kroki tercih edin.

Bir diyagram aracını kendi sunucunuzda barındırmanın gerçek etkileri

Hangi bileşenlerin sunucunuza temas ettiği konusunda kesin olun; çünkü bu durum, kendi kendine barındırmanın (self-hosting) size gizlilik mi yoksa sadece erişilebilirlik mi sağladığını belirler.

• draw.io tarayıcı üzerinde render edilir. Konteyneriniz sadece uygulama kodunu sunar. Dosya, düzenleyiciye kaydetmesi için nereyi gösterirseniz oraya gider.
• Excalidraw tarayıcı üzerinde render edilir ve mevcut sahneyi o tarayıcının yerel depolama alanında tutar. Sunucu tarafına hiçbir veri yazılmaz.
• Kroki sunucu üzerinde render edilir. Diyagram kaynağı ve oluşturulan görsel, konteynerinizin içinde bulunur.

Sadece üçüncü durum veriyi kontrolünüz altındaki donanıma taşır. İlk iki durumda kendi kendine barındırma, varlık kontrolü ve erişilebilirlik sağlar: JavaScript dosyaları sizin sunucunuzdan geldiği için, üçüncü taraf bir servis kesintiye uğradığında, hizmet şartlarını değiştirdiğinde veya ağınızdan erişilemez hale geldiğinde düzenleyici çalışmaya devam eder. Bu durum bazı ekipler için gerçek bir değer taşır. Bu, "diyagram asla binadan dışarı çıkmaz" iddiasından farklı bir durumdur.

draw.io: hiçbir veri depolamayan resmi container

Proje kendi imajını yayınlamaktadır ve README dosyasındaki hızlı başlangıç komutu tek satırdır.

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

Bu komut, düzenleyiciyi sunucunun sahip olduğu tüm adreslerde yayınlar. Bir VPS üzerinde, yayınlanan portu loopback arayüzüne bağlayın ve ona bir reverse proxy veya SSH tüneli üzerinden erişin.

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 adresini tünel üzerinden açın. README dosyası ?offline=1 değişkenini "bulut depolama desteğini devre dışı bırakan bir güvenlik özelliği" olarak tanımlar. Bu değişken kullanılmadığında düzenleyici; Google Drive, OneDrive ve GitHub gibi başkalarına ait sunucuları kaydetme hedefi olarak sunar.

127.0.0.1 adresine bağlama işlemi, ilgili portun genel internete açılmasını engeller. Basit bir -p 8080:8080 komutu ufw tarafından filtrelenmez; çünkü Docker, kendi iptables kurallarını ufw tarafından yönetilen zincirlerin önüne yerleştirir. Bu nedenle güvenlik duvarı doğru yapılandırılmış gibi görünse de port dış dünyaya yanıt vermeye devam eder. Docker'ın ufw'yi devre dışı bırakarak port yayınlaması başlıklı bölüm, bu mekanizmayı ve çözümünü açıklamaktadır.

Düzenleyici localhost üzerinde çalışmadığı anda iki ortam değişkeni önem kazanır.

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"

Sondaki eğik çizgi (slash) bir yazım hatası değildir. README dosyası DRAWIO_SERVER_URL değişkenini "sonda eğik çizgi bulunan genel dağıtım URL'si", DRAWIO_BASE_URL değişkenini ise "sonda eğik çizgi bulunmayan aynı URL" olarak tanımlar; ikincisi görüntüleyici, lightbox ve gömülü kod yolları tarafından kullanılır. Düzenleyiciyi https://www.example.com/drawio/ gibi bir alt dizin altında sunuyorsanız, uygulama kendi görüntüleyici ve gömülü URL'lerini bu değişkenlerden oluşturduğu için her iki değer de bu alt dizini içermelidir.

Kalıcılık: Veri kalıcılığı yoktur ve tasarım bu şekildedir. Compose dosyasında hiçbir volume tanımlanmamıştır çünkü container herhangi bir diyagram verisi tutmaz. Bir .drawio dosyası, düzenleyicinin tarayıcınıza ilettiği XML verisidir ve dosyanın nereye kaydedileceğine seçtiğiniz hedef karar verir: kendi makinenize bir indirme işlemi veya düzenleyiciyi içine gömen uygulama. Bu hedefi yedekleyin. Eğer hedef VPS üzerindeki bir klasör ise, korunması gereken şey o klasör ve ona erişmek için kullandığınız dosya yöneticisidir, çünkü draw.io hiçbir şeyin kopyasını tutmaz.

Sunucunuzdan hala neler çıkıyor. Eskisine göre daha az, çünkü dışa aktarma (export) artık hiçbir yere gitmiyor. README dosyası artık EXPORT_URL ve DRAWIO_SELF_CONTAINED değişkenlerini, hiçbir etkisi olmayan kaldırılmış değişkenler listesinde göstermektedir. Bu değişkenler düzenleyiciyi, "ömrünü tamamlamış" olan ayrı bir jgraph/export-server imajına yönlendiriyordu. Giriş noktası (entrypoint) artık PreConfig.js dosyasına window.EXPORT_URL = null değerini yazar; bu da düzenleyiciye herhangi bir dışa aktarma servisinin mevcut olmadığını bildirir. Uygulamada, PDF olarak dışa aktar seçeneği tarayıcının yazdırma iletişim kutusunu açar, bu nedenle PDF için diyagramın bir kopyasını dahil etme seçeneği sunulmaz ve sunucu tarafında oluşturulan PNG ve JPEG dışa aktarma seçenekleri gizlenir. Tarayıcıda oluşturulan PNG, JPEG ve SVG dışa aktarma işlemleri çalışmaya devam eder. ENABLE_DRAWIO_PROXY varsayılan olarak kapalıdır ve tarayıcı adına harici resim URL'lerini getiren bir /proxy uç noktasını etkinleştirir; bu nedenle ihtiyacınız olmadığı sürece kapalı tutun.

Excalidraw: arkasında sunucu bulunmayan statik bir paket

Resmi imaj sayfası şu komutu vermektedir.

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

Yayınlanan portu, önceki nedenlerle aynı şekilde loopback üzerine taşıyın.

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

Konteyner içinde nginx, 80 numaralı portta derlenmiş bir JavaScript paketini sunar. Yayınlanan imaj, sıkıştırılmış halde yaklaşık 41 MB boyutundadır (Docker Hub, Ekim 2026); bu da içinde ne kadar az şey olduğunu gösterir. Veritabanı, oturum deposu veya yükleme dizini yoktur çünkü sunucuda depolanacak hiçbir şey bulunmamaktadır.

İmaj sayfası sınırı açıkça belirtir: "Şu an için kendi örneğinizi barındırmak, paylaşım veya iş birliği özelliklerini desteklememektedir." Arayüzde düğmeler hala mevcuttur, bu yüzden nedenini bilmek önemlidir. Canlı iş birliği, ayrı olarak yayınlanan bir excalidraw/excalidraw-room websocket sunucusuna ihtiyaç duyar. Bir paylaşım bağlantısı, şifrelenmiş sahneyi tutmak için bir depolama servisine gereksinim duyar. Her ikisinin adresi de derleme zamanında Vite değişkenleri (VITE_APP_WS_SERVER_URL, VITE_APP_BACKEND_V2_GET_URL, VITE_APP_BACKEND_V2_POST_URL) olarak paketin içine derlenir ve depodaki üretim değerleri, Excalidraw'un kendi barındırdığı servislere işaret eder. Vite, derleme sırasında bu değerlerin yerine yenilerini koyar, böylece bunlar JavaScript içinde sabit dizgeler (literal strings) olarak kalır. Bunları konteyner ortam değişkenleri olarak ayarlamak hiçbir şeyi değiştirmez çünkü çalışma zamanında bunları okuyan bir kod yoktur. İş birliğini kendi oda sunucunuza yönlendirmek, ön yüzü kendi değerlerinizle kaynak koddan derlemeniz anlamına gelir. Plan yapmadan önce o sunucunun durumunu kontrol edin: Ekim 2026 itibarıyla, Docker Hub üzerindeki excalidraw/excalidraw-room imajının en son gönderimi Aralık 2023 tarihlidir.

Bir çizimin gerçekten nerede yaşadığı. Sahne, tarayıcının yerel deposunda, o cihazda ve o kaynak (origin) için tutulur. Aynı URL'yi gizli bir pencerede açtığınızda tuvalin boş olduğunu görürsünüz; bu, durumu kendinize kanıtlamanın en hızlı yoludur. Site verilerini temizlemek çizimi siler ve geri yüklenecek bir sunucu kopyası yoktur. Bu nedenle insanlara "Farklı kaydet..." seçeneğini kullanmalarını ve JSON formatındaki .excalidraw dosyasını yedeklenen bir yerde tutmalarını öğretin. Paylaşılan bir örnek, herkese kendi özel tuvalini sunar. Burayı, tesadüfen barındırılan kişisel bir karalama defteri olarak değerlendirin.

Kroki: kod olarak diyagramlar, sunucunuzda işlenir

Kroki, birçok işleyici (renderer) önünde duran bir HTTP ağ geçididir. Metin gönderir (POST) ve karşılığında SVG veya PNG alırsınız. Graphviz, PlantUML, D2 ve diğer bazı araçlar ağ geçidi imajının içine gömülüdür. Mermaid, BPMN ve Excalidraw işleyicileri ise yan konteynerlerde çalışır, bu nedenle Compose bu kurulum için en mantıklı yöntemdir. Aşağıdaki örnek, Kroki dokümantasyonundan alınmıştır.

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 ana makineye hiçbir port açmaz, bu sayede yan konteynerlere yalnızca Compose ağı üzerinden ağ geçidi erişebilir. İstenen durum budur. Eğer Kroki'yi çağıran wiki farklı bir sunucuda çalışmıyorsa, ağ geçidi satırını "127.0.0.1:8000:8000" olarak değiştirin. Daha önce bir sunucuda Compose dosyası yazmadıysanız, VPS üzerinde Docker Compose çalıştırma rehberi dosya yapısını ve docker compose up -d döngüsünü açıklar.

Aşağıdaki sırayla iki adet duman testi (smoke test) çalıştırın; bu testler farklı nedenlerle başarısız olabilirler.

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 ağ geçidinin içinde çalıştığı için, buradan gelecek bir SVG belgesi ağ geçidinin sağlıklı olduğunu kanıtlar. Şimdi konteynerler arası iletişimi test edin.

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

İkinci komuttan gelen SVG, KROKI_MERMAID_HOST adresinin çözümlendiğini ve yan konteynerin yanıt verdiğini kanıtlar. Birincisi çalışıyor ancak ikincisi çalışmıyorsa, sorun iki konteyner arasındadır; bu nedenle diyagram sözdizimine dokunmadan önce docker compose logs kroki kısmını okuyun.

GET formu, diyagramı URL içine kodlar; bir wiki'nin eklenti kullanmadan görseli bu şekilde gömmesinin yolu budur. Dokümantasyon bu kodlayıcıyı sağlar.

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 üzerinde bu komut python: command not found çıktısını verir, çünkü sistem python3 ile gelir ve sürümsüz bir python içermez. python3 kullanın. Çıktı, /{diagram-type}/{output-format}/{encoded-diagram} şeklindeki bir URL'nin sonuna eklenir ve herhangi bir <img> etiketi bu URL'yi işaret edebilir. Bir sınır mevcuttur: KROKI_MAX_URI_LENGTH varsayılan olarak 4096 bayttır, bu nedenle uzun diyagramların POST yöntemiyle gönderilmesi gerekir.

Kroki gönderdiğiniz metni okur, bu nedenle güvenlik ayarları kritik öneme sahiptir. KROKI_SAFE_MODE varsayılan olarak üç seviyeden en kısıtlayıcı olan SECURE değerindedir ve KROKI_PLANTUML_ALLOW_INCLUDE varsayılan olarak false değerine ayarlanmıştır. Bu varsayılanların var olma nedeni, PlantUML'in !include yönergesinin, işleyicinin bakış açısından dosya ve URL'leri okuyabilmesidir. Herkese açık bir uç noktada bu ayarları gevşetirseniz, internete konteynerinizin içinde çalışan bir dosya okuyucu vermiş olursunuz. Hangi include yoluna ihtiyacınız olduğunu bilmediğiniz sürece bu ayarları değiştirmeyin; ihtiyacınız olduğunda ise KROKI_PLANTUML_INCLUDE_PATH ile yolu belirtin.

Bellek: küçük bir VPS üzerinde hangisi sorun yaratır

Her container'ın ne çalıştırdığını bildiğinizde sıralama tahmin edilebilir hale gelir.

• Excalidraw imajı, statik dosyaları sunan bir nginx'tir. Üçü arasında açık ara en düşük maliyetli olanıdır.
• draw.io, bir Java uygulama sunucusu olan Tomcat üzerinde çalışır; dolayısıyla kimse çizim yapmasa bile bir JVM (Java virtual machine) yükü taşır.
• Kroki ağ geçidi de bir Java servisidir ve manuel kurulumlar için jar dosyası olarak dağıtılır.
• Mermaid bileşeni ise maliyetli olandır. Dockerfile dosyası Chromium kurar ve PUPPETEER_EXECUTABLE_PATH=/usr/lib/chromium/chrome ayarını yapar, çünkü Mermaid gerçek bir tarayıcı motorunda render edilir.

Bu nedenle boşta çalışma değerleri size çok az bilgi verir. Önemli olan sayı, bir diyagram render edilirken oluşan ani yük artışıdır ve KROKI_MERMAID_MAX_CONCURRENCY varsayılan olarak 6 değerindedir; yani aynı anda altı tarayıcı render işlemi gerçekleşebilir. Yayınlanmış bir rakama güvenmek yerine kendi sunucunuzda ölçüm yapın.

docker stats --no-stream
docker system df

İlk ölçümü her şey boşta çalışırken, ikincisini ise döngü içinde büyük bir mermaid diyagramı render ederken yapın. Eğer bu ani yük artışı küçük bir planda rahatsız edici düzeydeyse, tahmin yürütmek yerine sınırlama getirin: Compose servisinde bellek sınırlarını ayarlama konusu, sözdizimini ve bir container sınırına ulaştığında ne olduğunu gösterir. Mermaid bileşenini kaldırmak da geçerli bir çözümdür, çünkü ağ geçidi kendi içinde yerleşik olan tüm render motorlarını sunmaya devam eder.

Bunların hiçbiri bir kullanıcı modeli ile gelmediği için bir tane ekleyin

draw.io üzerinde hesap sistemi yoktur. Excalidraw üzerinde hesap sistemi yoktur. Kroki, kendisine ulaşan her isteğe yanıt verir. Herhangi bir oturum açma işlemi proxy üzerinden gerçekleştirilmelidir.

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

htpasswd -c dosyayı oluşturur ve mevcut olanın üzerine yazar, bu nedenle ilk seferde -c parametresini kullanın ve bir daha asla kullanmayın.

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 ile uygulayın. nginx -t kısmı önemlidir: hatalı bir yapılandırmada yeniden yükleme işlemi eski yapılandırmayı çalışır durumda bırakır, böylece site çalışmaya devam eder ancak yaptığınız değişiklik devreye girmez. Satır satır ters proxy yapılandırması açıklaması, bu kod parçacığında yer almayan başlık bloğunu ve sertifika yollarını ele alır.

Temel kimlik doğrulama (Basic authentication), Kroki için yanlış bir araçtır ve bunun nedenini anlamak önemlidir. Bir wiki sayfası, bir Kroki görselini <img> etiketiyle gömer. Okuyucunun tarayıcısı, bu URL'yi çapraz kökenli (cross-origin) bir alt kaynak olarak getirir. Tarayıcı, Kroki ana bilgisayarı için halihazırda elinde bulunan temel kimlik bilgilerini ekleyecektir; ancak güncel tarayıcılar çapraz kökenli bir görsel için oturum açma istemi göstermez. Bu nedenle, Kroki ana bilgisayarında doğrudan oturum açmamış olan her okuyucu 401 hatası alır ve sayfadaki tüm diyagramları bozuk görsel olarak görür. Kroki'yi genel internete açmayın. Onu wiki container'ı ile aynı Docker ağına yerleştirin ve wiki'nin ona servis adıyla ulaşmasını sağlayın; ana bilgisayarda hiçbir portu dışarıya açmayın. Compose ağları servis adlarını nasıl çözer, bu yapının çalışmasını sağlayan temel mekanizmadır.

Self-hosted bir wiki ile birlikte kullanılan diyagramlar

İnsanların bu tür bir yapılandırmayı istemesinin en yaygın nedeni budur. Bir wiki sayfasının görsele ihtiyacı olur ve kimse bu görselin birinin dizüstü bilgisayarından alınmış bir ekran görüntüsü olmasını istemez.

BookStack, self-hosted bir düzenleyici için birinci sınıf bir kanca sunar. Varsayılan gömme URL'si https://embed.diagrams.net/?embed=1&proto=json&spin=1&configure=1 şeklindedir ve .env içindeki tek bir satır, bunu kendi container'ınıza yönlendirir.

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

Sorgu dizisini (query string) tam olarak kopyalayın. BookStack belgeleri, embed=1&proto=json&spin=1 ifadesinin "BookStack ile entegrasyonun çalışması için gerekli" olduğunu belirtir; çünkü bu parametreler, iki sayfanın birbiriyle iletişim kurmak için kullandığı JSON mesaj protokolünü seçer. Aynı sayfa, "diğer harici servislerin kullanılmasını istemiyorsanız" stealth=1 seçeneğine işaret eder; bu, self-hosting amacınız dışa giden çağrıları durdurmaksa eklemeniz gereken seçenektir. Bu bağlantı kurulduğunda, BookStack çizimi sayfanın yanındaki kendi görsel depolama alanına kaydeder; böylece halihazırda aldığınız wiki yedeği, aynı zamanda diyagramın da yedeği olur.

Wiki seçiminiz henüz kesinleşmediyse, önce buna karar verin. BookStack, Wiki.js ve Outline arasından seçim yapmak, daha önceki bir karardır; çünkü wiki, bir diyagramın sayfaya nasıl ekleneceğini ve dolayısıyla bu araçlardan hangisini sisteme entegre edeceğinizi belirler.

Hata modları ve karşılaşacağınız dizgeler

BookStack içinde çizim düzenleyici açılıyor ve sürekli dönüyor. Döndürme simgesi spin=1 diyagram verisini bekliyor demektir. proto=json ile düzenleyici hazır olduğunda bir init olayı gönderir ve yanıt olarak diyagramı taşıyan bir load eylemi bekler; bu alışveriş tamamlanmadığında döndürme simgesi ekranda kalmaya devam eder. embed=1&proto=json&spin=1 değerinin DRAWIO değişkeninizde mevcut olduğunu ve ana makine kısmında yazım hatası bulunmadığını kontrol edin.

Düzenleyici çerçevesi HTTPS bir wiki üzerinde boş kalıyor. Tarayıcı konsolu, https:// içinde http:// yüklendiği için karma içerik (mixed content) hatası bildirir. Tarayıcı çerçeveyi engeller ve draw.io asla çalışmaz. Düzenleyiciyi HTTPS üzerinden sunun.

Kroki 413 Request Entity Too Large döndürüyor. Bu tam ifade, nginx'in hatayı adlandırma biçimidir; bu nedenle ilk şüpheli proxy'dir. Ancak Kroki de kendi başına bir 413 hatası gönderebilir; dokümantasyonu bunu Content Too Large olarak adlandırır. Nginx client_max_body_size varsayılanı 1 MB'tır ve PlantUML, ağ geçidi içinde işlendiği için büyük bir PlantUML kaynağının takıldığı sınır budur. Kroki'nin kendi KROKI_MAX_BODY_SIZE değeri de varsayılan olarak 1mb'tür ancak bu yalnızca diagrams.net, Excalidraw ve Mermaid yardımcı container'larında bulunur; bu nedenle büyük bir Mermaid kaynağı her iki sınıra da takılabilir. Öncelikle client_max_body_size değerini yükseltin, diyagram bir yardımcı container üzerinden geçiyorsa o taraftaki KROKI_MAX_BODY_SIZE değerini de artırın.

Graphviz çalışırken Mermaid başarısız oluyor. Ağ geçidi sağlıklı ancak yardımcı container'a ulaşılamıyor. docker compose ps ile servisin ayakta olduğunu kontrol edin, ardından KROKI_MERMAID_HOST değerinin servis adıyla eşleştiğini doğrulayın; çünkü bu değer varsayılan olarak 127.0.0.1'dur ve ağ geçidi container'ı içinde bu, ağ geçidinin kendisi anlamına gelir.

Excalidraw iş birliği asla bağlanmıyor. Eğer kendi oda sunucunuza karşı bir arayüz oluşturduysanız ve bunu nginx arkasına koyduysanız, proxy'nin bağlantıyı proxy_set_header Upgrade $http_upgrade; ve proxy_set_header Connection "upgrade"; ile yükseltmesi gerekir. Bunlar olmadan websocket el sıkışması sıradan bir HTTP isteği olarak yanıtlanır ve oturum asla başlamaz.

Tarayıcı temizliğinden sonra tuval boş kalıyor. Sahne o cihazdaki yerel depolamadaydı ve sunucu kopyası yok. Çözüm bir ayardan ziyade bir alışkanlıktır: saklamaya değer her şey için .excalidraw dosyasını dışa aktarın.

FAQ

draw.io uygulamasını kendi sunucumda barındırmak diyagramlarımı gizli tutar mı?

Uygulama kodunu sunucunuzda tutmak, verilerin gizli kalmasıyla aynı şey değildir. draw.io tarayıcınızda işlendiği için container hiçbir zaman bir diyagramı tutmaz. Gizlilik, dosyayı nereye kaydettiğinize ve hangi giden çağrıları etkin bıraktığınıza bağlıdır. Bulut depolama hedeflerini devre dışı bırakmak için ?offline=1 kullanın ve ENABLE_DRAWIO_PROXY seçeneğini kapalı tutun. Dışa aktarma işlemi de dışarıya hiçbir şey göndermez: görsel hiçbir dışa aktarma servisi yapılandırmaz, bu nedenle PDF dosyaları tarayıcının yazdırma iletişim kutusu üzerinden işlenir ve DRAWIO_SELF_CONTAINED artık herhangi bir etkiye sahip değildir.

Kendi barındırdığım Excalidraw üzerinde iş birliği neden çalışmıyor?

Resmi imaj sayfası, kendi kendine barındırmanın "paylaşım veya iş birliği özelliklerini desteklemediğini" belirtmektedir. Canlı iş birliği, ayrı bir excalidraw/excalidraw-room websocket sunucusu gerektirir ve paylaşım bağlantıları bir depolama servisine ihtiyaç duyar. Her iki adres de derleme zamanında JavaScript paketine VITE_APP_WS_SERVER_URL gibi Vite değişkenleri olarak gömülür, bu nedenle çalışan container üzerinde bir ortam değişkeni ayarlamanın hiçbir etkisi olmaz. Kendi oda sunucunuzu kullanmak, ön yüzü kendi değerlerinizle kaynak koddan derlemeniz gerektiği anlamına gelir.

Kendi sunucumda Mermaid diyagramlarını nasıl oluşturabilirim?

Kroki'yi mermaid yardımcı container'ı ile birlikte çalıştırın ve KROKI_MERMAID_HOST değerini bu servis adına ayarlayın. Ardından diyagram metnini /mermaid/svg adresine POST edin ve yanıt olarak gelen SVG'yi okuyun veya diyagramı bir GET URL'sine kodlayarak bir <img> etiketini bu URL'ye yönlendirin. Mermaid bir tarayıcı motoruna ihtiyaç duyduğu için yardımcı servis, Puppeteer aracılığıyla Chromium'u çalıştırır; bu nedenle bellek planlamanızı buna göre yapın: KROKI_MERMAID_MAX_CONCURRENCY varsayılan olarak aynı anda altı işleme izin verir.

Bu araçların önüne bir parola koymam gerekir mi?

Evet, çünkü hiçbirinde kullanıcı hesabı bulunmamaktadır. draw.io ve Excalidraw, URL'yi bulan herkese tam bir düzenleyici sunar ve Kroki kendisine gönderilen her metni işler. İki düzenleyici için reverse proxy üzerinde temel kimlik doğrulama (basic authentication) yeterlidir. Kroki için ise, onu wiki ile paylaşılan bir Docker ağı üzerinde yayınlanmamış şekilde tutun; çünkü bir okuyucunun tarayıcısı, farklı bir orijindeki <img> için giriş istemi göstermeyecektir, bu da Kroki'ye doğrudan giriş yapmamış herkes için tüm gömülü diyagramların bozulmasına neden olur.