Ubuntu Sunucularda Dify Kurulumu ve Yapay Zeka Orkestrasyonu

Bir yapay zeka uygulamasını birkaç dakikada prototip hâline getirmek kolay olabilir, fakat aynı uygulamayı şirket verileriyle çalışan, izlenebilir, yedeklenebilir ve güvenli bir servise dönüştürmek farklı bir iştir. Yaklaşık on yıldır Linux sunucuları, container altyapıları ve uygulama servisleriyle çalışırken en çok gördüğüm hata, kurulum tamamlandığında projenin bittiğinin düşünülmesidir. Asıl iş domain, HTTPS, secret yönetimi, model bağlantıları, RAG kalitesi, workflow kontrolü, loglama, yedekleme ve güncelleme süreçleri başladığında ortaya çıkar. Ubuntu Sunucularda Dify Kurulumu ve Yapay Zeka Orkestrasyonu konusunda bu rehberin amacı yalnızca çalışan bir Dify ekranı göstermek değil, sürdürülebilir bir self-hosted AI altyapısının nasıl kurulacağını anlatmaktır. Rehber boyunca Ubuntu sunucuya Dify nasıl kurulur, Dify Docker Compose ile Ubuntu kurulumu ve yapılandırması nasıl yapılır, Dify ile LLM RAG workflow ve AI agent orkestrasyonu nasıl yapılır gibi pratik sorulara birlikte yanıt bulacağız.

Dify self-hosted kurulumunda Ollama API SSL veritabanı ve güvenlik ayarları birbirinden ayrı konular değildir. Bir modelin çalışması, o modelin şirket verisine hangi yetkiyle ulaştığı, hangi API anahtarını kullandığı, hangi logları bıraktığı ve hata durumunda ne yaptığıyla birlikte değerlendirilmelidir. Kurumsal Dify kurulumu ve yapay zeka orkestrasyon hizmeti planlayan ekiplerin de önce uygulama akışını, veri sınıflarını ve kullanıcı rollerini çıkarması gerekir. Ben yeni bir Dify projesine başlarken önce model seçmek yerine “hangi veri nereden gelecek, kim kullanacak, hangi işlem otomatik yapılabilir ve hangi noktada insan onayı gerekir?” sorularını soruyorum. Bu yaklaşım Dify kurulumu ve yapay zeka entegrasyon danışmanlığı yakınımda şeklinde destek arayan işletmeler için de sağlıklı bir proje çerçevesi oluşturur.

Dify Nedir?

Dify, büyük dil modelleriyle çalışan uygulamalar geliştirmek ve yönetmek için kullanılan açık kaynaklı bir platformdur. Tek bir model çağrısının ötesine geçerek workflow, RAG, agent, tool, model sağlayıcıları ve uygulama API'lerini ortak bir ortamda yönetmenizi sağlar. Görsel arayüzü sayesinde birçok akış doğrudan kod yazmadan kurulabilir, fakat ihtiyaç olduğunda API, code node ve plugin gibi bileşenlerle geliştirilebilir. Bu nedenle Dify'ı yalnızca chatbot hazırlama aracı olarak görmek eksik olur. Ben Dify'ı uygulama mantığı ile LLM servisleri arasında kontrol katmanı oluşturan bir orkestrasyon platformu olarak değerlendirmeyi daha doğru buluyorum.

Dify Ne İşe Yarar?

Dify, LLM tabanlı bir fikri prototipten kullanılabilir uygulamaya taşırken gereken birçok bileşeni aynı ortamda birleştirir. Model sağlayıcısı seçebilir, kullanıcı girdisini işleyebilir, bilgi tabanından içerik çekebilir, koşullu akış oluşturabilir ve harici API'lere istek gönderebilirsiniz. Workflow run kayıtları sayesinde hangi node'un ne kadar sürdüğünü ve hangi çıktıyı ürettiğini incelemek de mümkündür. Uygulamayı Dify arayüzü üzerinden kullanabileceğiniz gibi API olarak kendi web veya mobil uygulamanıza bağlayabilirsiniz. Böylece ekipler model entegrasyon kodunu her proje için sıfırdan yazmak yerine ortak ve yönetilebilir bir uygulama katmanı oluşturabilir.

Dify ile Hangi Yapay Zeka Uygulamaları Geliştirilebilir?

Dify farklı yapay zeka kullanım senaryolarını aynı platform içinde geliştirmeye uygundur. Basit bir soru cevap botundan şirket dokümanlarını kullanan RAG uygulamasına kadar geniş bir alanı kapsar. Workflow özelliğiyle kullanıcı girdisini sınıflandırabilir, farklı modeller arasında yönlendirme yapabilir ve şirket API'lerinden veri çekebilirsiniz. Agent tarafında ise modele kontrollü araçlar vererek belirli görevleri adım adım tamamlamasını sağlayabilirsiniz. Uygulamanın sınırlarını daha en başta belirlemek, gereksiz node ve model çağrılarından kaçınarak maliyeti ve hata alanını azaltır.

AI Chatbot

AI chatbot, Dify ile başlanabilecek en anlaşılır kullanım senaryolarından biridir. Kullanıcının mesajı bir LLM'e gönderilir ve alınan cevap sohbet arayüzünde gösterilir. Sistem prompt'u, model parametreleri ve conversation context gibi alanlar merkezi şekilde yönetilebilir. Daha sonra bilgi tabanı veya harici araçlar eklenerek chatbot kapsamı genişletilebilir. Ben ilk kurulum testlerinde önce basit chatbot oluşturup model bağlantısını doğrulamayı, ardından RAG ve tool adımlarına geçmeyi tercih ediyorum.

RAG Uygulamaları

RAG uygulamaları modelin yalnızca eğitim verisine dayanmak yerine belirli dokümanlardan içerik bulup yanıt üretmesini sağlar. Dify dokümanları parçalara ayırabilir, embedding oluşturabilir ve ilgili parçaları sorgu sırasında geri getirebilir. Bu yöntem şirket prosedürleri, ürün dokümanları veya destek içerikleri için oldukça kullanışlıdır. Kalite yalnızca kullanılan LLM'e bağlı değildir, chunk yapısı, metadata, retrieval ayarları ve reranker seçimi de sonucu doğrudan etkiler. Bu nedenle iyi bir RAG sistemi kurarken önce doküman kalitesine ve retrieval testlerine odaklanmak gerekir.

AI Workflow

AI workflow, tek bir model çağrısını birden fazla kontrollü adıma dönüştürür. Kullanıcı girdisi sınıflandırılabilir, şartlara göre farklı yola gönderilebilir ve sonuç başka bir API ile zenginleştirilebilir. Deterministik işlemler için code veya template node kullanılarak gereksiz LLM çağrısı azaltılabilir. Bu yapı özellikle kurumsal süreçlerde öngörülebilirlik sağlar. Ben iş kurallarının açık olduğu durumlarda agent yerine workflow kullanmayı genellikle daha güvenli ve kolay izlenebilir buluyorum.

AI Agent

AI agent, modele belirli araçları kullanarak bir hedefe ulaşma esnekliği verir. Agent hangi tool'u hangi sırada çağıracağına modele ve tanımlanan stratejiye göre karar verebilir. Bu esneklik güçlüdür, ancak aynı zamanda yetki ve maliyet kontrolü gerektirir. Yazma yetkisi olan araçlar insan onayı olmadan verilirse beklenmeyen işlemler oluşabilir. Bu yüzden agent kullanımında minimum araç yetkisi, maksimum iterasyon ve açık hata sınırları belirlemek önemlidir.

İç Doküman Asistanı

İç doküman asistanı şirket içindeki prosedür, teknik belge, insan kaynakları dokümanı veya ürün bilgisini kullanıcıya doğal dille sunabilir. Belgeler Dify Knowledge Base içine alınarak RAG üzerinden aranabilir. Kullanıcının departmanına göre farklı bilgi kaynakları kullanılabilir. Yetki duyarlı retrieval tasarlanmadığında kullanıcının erişmemesi gereken içeriğin modele bağlam olarak gönderilme riski oluşur. Bu nedenle şirket içi asistan projelerinde yalnızca cevap kalitesi değil doküman erişim modeli de baştan tasarlanmalıdır.

API Tabanlı AI Servisleri

Dify workflow veya chatbot uygulamaları API üzerinden başka sistemlere servis olarak sunulabilir. Web uygulaması, mobil uygulama, CRM veya şirket backend'i bu API'yi çağırabilir. API anahtarının tarayıcı tarafında tutulmaması ve çağrıların güvenli backend üzerinden geçirilmesi gerekir. Rate limit, user ID ve input validation gibi kontroller de production kullanımı için önemlidir. Böylece Dify kullanıcı arayüzü yerine şirketin mevcut uygulamalarının arkasında çalışan merkezi AI servis katmanı hâline gelir.

Dify Neden Bir AI Orkestrasyon Platformudur?

Orkestrasyon, birden fazla model, veri kaynağı, araç ve işlem adımının belirli kurallarla birlikte çalıştırılması anlamına gelir. Dify bu işlemleri workflow ve agent yapıları üzerinden bir araya getirir. Bir sorgu önce sınıflandırılabilir, ardından bilgi tabanında aranabilir, gerekirse API çağrısı yapılabilir ve sonuç farklı bir model tarafından özetlenebilir. Her adımın girdisi ve çıktısı ayrı izlenebilir. Bu özellikler Dify'ı yalnızca LLM arayüzü olmaktan çıkarıp uygulama akışını yöneten bir orkestrasyon katmanına dönüştürür.

Low-Code LLMOps Nedir?

Low-Code LLMOps, model tabanlı uygulamaların geliştirme ve işletim süreçlerini mümkün olduğunca görsel ve tekrar kullanılabilir bileşenlerle yönetme yaklaşımıdır. Dify içinde prompt, model, workflow, knowledge base ve tool ayarları kod yazmadan büyük ölçüde yönetilebilir. Buna rağmen production sisteminde Linux, Docker, ağ, API ve veri güvenliği bilgisi önemini kaybetmez. Low-code yaklaşım geliştirmeyi hızlandırır, fakat altyapı sorumluluğunu ortadan kaldırmaz. Bu nedenle Dify kullanan ekiplerin hem uygulama tasarımını hem de temel sistem yönetimini anlaması uzun vadede ciddi avantaj sağlar.

Dify Cloud mu Self-Hosted Dify mı?

Dify kullanmaya başlarken ilk mimari kararlardan biri Cloud hizmeti ile self-hosted kurulum arasında seçim yapmaktır. Cloud modeli altyapı işletme yükünü azaltırken self-hosted model veri, ağ ve güncelleme üzerinde daha fazla kontrol verir. Tek doğru seçenek yoktur, çünkü veri sınıfı, ekip kapasitesi, maliyet ve entegrasyon ihtiyacı projeden projeye değişir. Ben hızlı prototiplerde yönetilen hizmetleri, şirket içi veri ve özel network entegrasyonlarının yoğun olduğu projelerde ise self-hosted seçeneğini daha sık değerlendiriyorum. Kararı yalnızca lisans veya sunucu maliyetine göre değil toplam operasyon sorumluluğuna göre vermek gerekir.

Dify Cloud Avantajları

Dify Cloud altyapı hazırlama ve temel bakım işlerini azaltarak uygulama geliştirmeye daha hızlı başlamayı sağlar. Sunucu, Docker ve ters proxy gibi katmanların yönetimiyle uğraşmadan workflow ve knowledge base tasarımına odaklanabilirsiniz. Küçük ekiplerin prototip oluşturması için bu önemli kolaylıktır. Bununla birlikte veri lokasyonu, dış servis kullanımı ve kurumsal gereksinimler ayrıca incelenmelidir. Cloud seçeneği operasyon süresini azaltır, ancak veri yönetişimi sorumluluğunu tamamen ortadan kaldırmaz.

Self-Hosted Dify Avantajları

Self-hosted Dify sunucu, ağ, depolama ve uygulama ayarları üzerinde daha geniş kontrol verir. Sistemi şirket içi network'e bağlayabilir, private API'lere erişim sağlayabilir ve local model servisleri kullanabilirsiniz. Veri akışının hangi sunucular üzerinden geçtiğini daha ayrıntılı tasarlamak mümkündür. Özel loglama, backup ve firewall politikaları da kurum standartlarına göre uygulanabilir. Buna karşılık bu özgürlük güncelleme, izleme, güvenlik ve felaket kurtarma sorumluluğunu sizin ekibinize taşır.

Veri Kontrolü ve Gizlilik

Self-hosted kurulumun en önemli nedenlerinden biri verinin nerede saklandığını ve hangi servislere gönderildiğini daha ayrıntılı kontrol edebilmektir. Conversation, knowledge base ve uygulama logları kurumun yönettiği altyapıda tutulabilir. Ancak cloud LLM kullanıyorsanız prompt ve context verisinin yine dış model sağlayıcısına gidebileceğini unutmamak gerekir. Local LLM kullanımı bazı veri çıkışlarını azaltabilir, fakat model sunucusunun güvenliği ayrıca yönetilmelidir. Veri kontrolü için tüm akışı uçtan uca çıkarmak, yalnızca Dify'ın kurulduğu lokasyona bakmaktan daha doğru bir yöntemdir.

Maliyet Kontrolü

Self-hosting ilk bakışta ucuz görünebilir, fakat gerçek maliyet sadece VPS ücretinden oluşmaz. Sunucu yönetimi, yedekleme, monitoring, güvenlik güncellemeleri ve teknik personel zamanı toplam maliyetin parçasıdır. Buna karşılık yoğun kullanımda kendi kaynaklarınız üzerinde çalıştırmak belirli senaryolarda avantaj sağlayabilir. Local LLM kullanılıyorsa GPU maliyeti ayrıca hesaplanmalıdır. En doğru yaklaşım kullanıcı sayısı, token tüketimi, depolama ve operasyon süresini birlikte değerlendirerek aylık toplam maliyet çıkarmaktır.

Local LLM Kullanabilme

Self-hosted Dify'ın güçlü yönlerinden biri Ollama gibi local model servislerine bağlanabilmesidir. Böylece belirli Llama veya Qwen tabanlı modeller şirket sunucusunda çalıştırılabilir. Bu yapı hassas verinin dış sağlayıcıya gönderilmesini azaltabilir ve bazı yoğun kullanım senaryolarında maliyet kontrolü sağlayabilir. Bununla birlikte kaliteli local inference için RAM, VRAM, GPU ve disk ihtiyacı hızla artabilir. Model seçiminde yalnızca parametre sayısına değil gerçek görev kalitesine ve sunucu kapasitesine bakmak gerekir.

Özelleştirme Özgürlüğü

Self-hosted kurulum sistemin çevresindeki altyapıyı kurum gereksinimine göre özelleştirmeyi kolaylaştırır. Reverse proxy, private DNS, VPN, özel sertifika, harici PostgreSQL veya object storage gibi bileşenler kullanılabilir. Plugin ve API entegrasyonları şirket içi servislerle doğrudan çalışabilir. Ortamı dev, staging ve production olarak ayırmak da mümkündür. Ancak her özelleştirme bakım yükü getirdiği için gerçekten ihtiyaç olmayan değişikliklerden kaçınmak faydalıdır.

Self-Hosting'in Operasyonel Sorumlulukları

Self-hosting yaptığınızda Dify servislerinin erişilebilirliği sizin sorumluluğunuzdadır. Docker container'larını, database sağlığını, Redis kullanımını, disk kapasitesini ve uygulama loglarını izlemeniz gerekir. Güvenlik güncellemeleri ve release notes düzenli takip edilmelidir. Backup almak kadar restore testinin çalıştığını doğrulamak da önemlidir. Bu sorumluluklar karşılanamayacaksa yönetilen hizmet kullanmak çoğu zaman daha güvenli bir tercih olabilir.

Dify'ı Ubuntu Sunucuda Çalıştırmak Neden Mantıklıdır?

Ubuntu özellikle LTS sürümleri, geniş topluluk desteği ve Docker uyumluluğu nedeniyle Dify self-hosting için pratik bir temel sağlar. Birçok VPS ve cloud sağlayıcı hazır Ubuntu image sunar. Paket yönetimi, SSH araçları ve ağ yönetimi geniş dokümantasyona sahiptir. Docker tabanlı kurulum sayesinde Dify bileşenleri host işletim sisteminden büyük ölçüde ayrılır. Ben production sunucularında masaüstü bileşenleri olmayan sade Ubuntu Server LTS kurulumu kullanmayı, ardından yalnızca gerekli servisleri eklemeyi tercih ediyorum.

Ubuntu LTS Avantajları

Ubuntu LTS sürümleri uzun süreli güvenlik güncellemeleri ve daha stabil paket tabanı sunar. Production servisinde sık işletim sistemi değişikliği yapmak istemeyen ekipler için bu önemlidir. Docker, Nginx, UFW ve Fail2ban gibi ihtiyaç duyulan araçlar rahatlıkla kullanılabilir. Geniş kullanıcı topluluğu sorun giderirken dokümantasyon bulmayı kolaylaştırır. Sunucu sürümünü seçerken destek süresi devam eden LTS sürümünü tercih etmek iyi bir başlangıçtır.

Docker Ekosistemi

Dify'ın self-hosted kurulumu Docker Compose ile kolayca ayağa kaldırılabildiği için Ubuntu ve Docker birlikteliği oldukça pratiktir. Container'lar API, web, worker ve veri servislerini birbirinden ayırır. Tek tek bağımlılıkları host üzerine manuel kurma ihtiyacı azalır. Güncelleme ve rollback işlemleri image sürümleri üzerinden daha yönetilebilir hâle gelir. Buna rağmen Docker'ın ağ, volume ve log davranışını anlamak production işletiminde önemini korur.

VPS ve Dedicated Server Seçenekleri

Küçük test ortamlarında birkaç çekirdekli bir VPS Dify için yeterli olabilir. Kullanıcı ve workflow sayısı arttığında daha fazla RAM ve hızlı SSD ihtiyacı oluşur. Local LLM çalıştırılacaksa GPU sunucusu veya dedicated donanım daha anlamlı olabilir. Dify uygulama katmanı ile model inference sunucusunu aynı makinede çalıştırmak zorunlu değildir. Özellikle GPU kullanan projelerde bu iki katmanı ayırmak kapasite yönetimini kolaylaştırabilir.

Cloud Sunucu vs On-Premise Sunucu

Cloud sunucu hızlı kaynak artırma ve yedek altyapı seçenekleriyle operasyon kolaylığı sağlar. On-premise sunucu ise şirket içi network ve hassas veri kaynaklarına doğrudan erişimde avantaj sunabilir. Her iki modelde de firewall, backup ve monitoring sorumluluğu devam eder. Hybrid yaklaşımda Dify şirket içinde çalışırken bazı modeller cloud API üzerinden kullanılabilir. Mimariyi seçerken network gecikmesi, veri çıkışı, maliyet ve ekip yetkinliği birlikte değerlendirilmelidir.

Şirket İçi AI Platformlarında Ubuntu Kullanımı

Şirket içi AI platformunda Ubuntu açık kaynak araçların ortak çalışma alanı olabilir. Dify, Ollama, Nginx, monitoring ajanları ve backup araçları aynı standart işletim sistemi politikasıyla yönetilebilir. Otomatik konfigürasyon için Ansible veya benzeri araçlar kullanılabilir. Güvenlik güncellemeleri merkezi patch sürecine bağlanabilir. Böylece tek bir deneme sunucusundan başlayan proje zamanla kurum içinde yönetilebilir bir AI hizmet platformuna dönüşebilir.

Dify Kurulumu İçin Sistem Gereksinimleri

Dify'ın minimum gereksinimleri ile gerçek production ihtiyacı birbirinden ayrılmalıdır. Resmî self-hosted başlangıç gereksinimleri düşük trafik için erişilebilir seviyededir, fakat knowledge base, worker ve eşzamanlı kullanıcı sayısı arttıkça kaynak ihtiyacı yükselir. CPU, RAM ve disk boyutlandırması sadece Dify web arayüzüne göre yapılmamalıdır. PostgreSQL, Redis, vector database ve worker işlemleri aynı host üzerinde kaynak tüketir. Local LLM de aynı makinede çalışacaksa GPU ve model belleği ayrı kapasite kalemi olarak hesaplanmalıdır.

Minimum CPU

Resmî hızlı başlangıç dokümantasyonunda en az iki CPU çekirdeği temel gereksinim olarak belirtilir. Bu değer test ve düşük trafik ortamı için başlangıç noktasıdır. Birden fazla worker, yoğun indeksleme veya eşzamanlı workflow çalıştırıldığında CPU kullanımı artar. Monitoring olmadan yalnızca vCPU sayısına bakmak yeterli değildir. Production için peak kullanım sırasında CPU saturation değerini ölçüp büyüme payı bırakmak daha sağlıklı olur.

Minimum RAM

Resmî başlangıç gereksinimi en az 4 GiB RAM seviyesindedir. Bu kapasite öğrenme ve küçük test kurulumu için düşünülebilir. PostgreSQL, Redis, vector store ve worker süreçleri aynı sunucuda çalıştığında daha fazla bellek gerekecektir. Knowledge base indeksleme sırasında kısa süreli RAM artışları görülebilir. Production ortamında swap'a sürekli yük binmesi performans sorununun işareti olarak görülmelidir.

Disk Alanı

Dify için disk ihtiyacı yalnızca uygulama container'larının boyutuyla sınırlı değildir. PostgreSQL verileri, upload edilen belgeler, vector database, plugin dosyaları ve loglar zamanla büyür. Knowledge base yoğun kullanılıyorsa disk kapasitesi daha hızlı tüketilebilir. SSD veya NVMe depolama database ve indexing performansını iyileştirebilir. Disk kullanımını yüzde olarak izleyip belirli eşiklerde alarm üretmek production işletiminde basit ama etkili bir kontroldür.

Docker Gereksinimi

Dify self-hosted kurulumunda en kolay ve yaygın yöntem Docker kullanmaktır. Docker Engine servislerin izole container'lar içinde çalışmasını sağlar. Host üzerinde doğrudan çok sayıda Python ve Node bağımlılığı yönetmek yerine image tabanlı dağıtım yapılır. Docker daemon erişiminin güçlü bir sistem yetkisi sağladığını unutmamak gerekir. Bu nedenle Docker grubuna yalnızca yönetim yetkisi gerçekten gerekli kullanıcılar eklenmelidir.

Docker Compose Gereksinimi

Dify'ın resmî hızlı kurulum akışı Docker Compose kullanır. Güncel proje README'sinde Docker Compose v2.24.0 veya üzeri belirtilmektedir. Compose dosyası Dify servislerini, network ilişkilerini, volume'ları ve environment değerlerini birlikte yönetir. `docker compose up -d` ile stack arka planda başlatılabilir. Production öncesinde kullanılan Compose sürümünü ve Dify release'ini değişiklik kaydına eklemek sorun giderme açısından faydalıdır.

Domain Gereksinimi

Local test için domain zorunlu değildir, çünkü Dify IP veya localhost üzerinden erişilebilir. Production kullanımında ise anlamlı bir domain kullanmak HTTPS ve kullanıcı erişimi açısından çok daha uygundur. Örneğin `ai.sirketiniz.com` gibi bir alt alan adı kullanılabilir. DNS kaydının reverse proxy sunucusuna yönelmesi gerekir. Domain aynı zamanda API ve console URL ayarlarının tutarlı yönetilmesini kolaylaştırır.

SSL Gereksinimi

Local lab dışında HTTPS kullanımı güçlü şekilde önerilir. Login oturumları, API çağrıları ve kullanıcı girdileri ağ üzerinde şifrelenmelidir. Let's Encrypt ve Certbot küçük ve orta ölçekli kurulumlarda kolay sertifika yönetimi sağlayabilir. Kurumsal ortamlarda şirket PKI veya merkezi certificate manager tercih edilebilir. Sertifika yenilemesinin otomatik olması kadar yenileme işleminin gerçekten test edilmesi de gerekir.

Local LLM Kullanılacaksa Ek Donanım Gereksinimleri

Local LLM çalıştırmak Dify uygulamasını çalıştırmaktan çok daha fazla kaynak isteyebilir. Model boyutu, quantization seviyesi ve context uzunluğu bellek kullanımını doğrudan etkiler. Küçük bir model CPU üzerinde çalışabilir, fakat cevap süresi yüksek olabilir. GPU kullanıldığında VRAM kapasitesi model seçimindeki ana sınırlardan biri hâline gelir. Bu nedenle Dify sunucusu ile Ollama veya başka inference sunucusunu ayrı makinelerde konumlandırmak birçok production senaryosunda daha kolay ölçeklenir.

RAM

Local model CPU veya kısmen GPU üzerinde çalışırken sistem RAM'i yoğun kullanılabilir. Model dosyasının boyutu ile çalışma sırasında gereken toplam bellek aynı değildir. Context büyüdükçe ek bellek tüketimi oluşabilir. Dify servislerinin de RAM kullandığı aynı host üzerinde mutlaka hesaba katılmalıdır. OOM sorunu yaşamamak için model yükü altında gerçek kullanım ölçülmeden kapasite kararı verilmemelidir.

GPU

GPU local LLM inference süresini ciddi şekilde azaltabilir. Bununla birlikte her GPU aynı model boyutunu verimli şekilde çalıştıramaz. Donanım seçerken CUDA veya kullanılan inference altyapısının uyumluluğu kontrol edilmelidir. Tek GPU yeterli değilse model splitting veya farklı inference sunucuları değerlendirilebilir. Küçük ekipler için önce gerçek kullanım senaryosunu benchmark edip ardından GPU yatırımı yapmak daha doğru olur.

VRAM

VRAM model ağırlıkları ve çalışma sırasında oluşan tensor verileri için kritik kaynaktır. Modelin quantization seviyesi VRAM ihtiyacını önemli ölçüde değiştirebilir. Büyük context penceresi de ek bellek gerektirebilir. Sınırda VRAM ile çalışan sistem yoğun eşzamanlı istekte beklenmedik hata verebilir. Bu nedenle model tek kullanıcı testine göre değil beklenen eşzamanlı kullanım altında ölçülmelidir.

Disk

Local LLM modelleri birkaç gigabayttan onlarca gigabayta kadar disk alanı tüketebilir. Birden fazla model ve embedding modeli tutulduğunda alan hızla büyür. SSD kullanımının model yükleme süresi üzerinde belirgin etkisi vardır. Eski ve kullanılmayan model dosyaları düzenli temizlenmelidir. Backup planında model dosyalarını her gün kopyalamak yerine gerektiğinde tekrar indirilebilir veriler ile benzersiz şirket verilerini ayırmak maliyeti azaltabilir.

Dify Sunucu Boyutlandırması Nasıl Yapılır?

Dify boyutlandırması kullanıcı sayısından daha fazla değişkene bağlıdır. Aynı anda çalışan workflow sayısı, knowledge retrieval yoğunluğu, upload edilen belgeler ve model çağrılarının süresi kaynak tüketimini belirler. Tek bir ağır RAG indexing işi, birçok basit chatbot isteğinden daha fazla CPU ve disk I/O kullanabilir. Bu nedenle production kapasitesi tahmini trafik ve gerçek yük testi birlikte kullanılarak belirlenmelidir. Ben başlangıçta orta düzey bir sunucu seçip CPU, RAM, disk ve worker queue metriklerini birkaç hafta izlemeyi, ardından ölçüme göre büyütmeyi tercih ediyorum.

Tek Kullanıcılı Test Ortamı

Tek kullanıcıyla öğrenme ve deneme ortamında minimum gereksinimlere yakın bir sanal makine yeterli olabilir. Burada amaç performans değil kurulumu ve workflow mantığını öğrenmektir. Küçük knowledge base ve az sayıda plugin kullanmak kaynak ihtiyacını düşük tutar. Local LLM farklı sunucuda çalıştırılırsa Dify host üzerindeki yük daha da azalır. Test ortamı internete açık tutulacaksa küçük olması güvenlik kontrollerinden vazgeçmek için gerekçe değildir.

Küçük Ekip

Birkaç kişinin aynı anda kullandığı ekip ortamında daha fazla RAM ve CPU payı bırakmak gerekir. Background indexing ve chat kullanımı aynı anda gerçekleşebilir. PostgreSQL ve Redis'in kaynak kullanımı izlenmelidir. Birkaç worker'ın eşzamanlı çalışması cevap sürelerini iyileştirebilir. Bu aşamada backup ve temel monitoring artık opsiyon değil düzenli operasyonun parçası olmalıdır.

Orta Ölçekli Şirket

Orta ölçekli şirket kullanımında tek sunucunun kapasitesi kadar erişilebilirliği de önem kazanır. Çok sayıda departman aynı Dify instance'ını kullanıyorsa worker queue ve database yükü artar. Harici object storage veya managed database seçenekleri değerlendirilebilir. Staging ve production ortamlarının ayrılması güncelleme riskini azaltır. Kullanıcı ve uygulama sayısı arttığında Dify'ı kritik iş servisi gibi izlemek gerekir.

Yoğun RAG Kullanımı

Yoğun RAG kullanımında vector database, embedding modeli ve indexing işleri ana kaynak tüketicilerine dönüşebilir. Büyük PDF koleksiyonları sürekli güncelleniyorsa worker kapasitesi önemlidir. Disk I/O ve vector search latency takip edilmelidir. Chunk sayısının gereksiz büyümesi hem depolama hem retrieval maliyetini artırır. İyi boyutlandırma sadece daha büyük sunucu almak değil doküman işleme stratejisini de optimize etmektir.

Local LLM Kullanımı

Local LLM aynı makinede çalışıyorsa GPU, RAM ve CPU planı Dify'ın kendisinden bağımsız değerlendirilmelidir. Model yükü Dify worker işlemlerinin kaynaklarını sıkıştırabilir. Yoğun kullanımda inference sunucusunu ayrı host'a taşımak daha dengeli olur. Model API'si internal network üzerinden Dify'a sunulabilir. Böylece Dify ve model katmanı farklı hızlarda ölçeklenebilir.

Yoğun Workflow ve Agent Kullanımı

Workflow ve agent kullanımı tek LLM çağrısına göre daha fazla işlem adımı oluşturur. Bir istek içinde birkaç model, tool ve HTTP çağrısı çalışabilir. Agent iterasyon sayısı kontrol edilmezse aynı kullanıcı isteği çok sayıda model çağrısına dönüşebilir. Worker concurrency ve queue uzunluğu bu nedenle düzenli izlenmelidir. Maliyet ve latency bütçesi workflow tasarımının parçası hâline getirilmelidir.

CPU, RAM ve Disk Darboğazlarını Öngörmek

CPU saturation, sürekli yüksek load average ve worker gecikmesi işlemci darboğazına işaret edebilir. RAM yetersizliğinde swap kullanımı ve OOM olayları görülebilir. Disk doluluğu kadar IOPS ve latency de database performansını etkiler. Tek bir metrik yerine bu kaynakları birlikte izlemek gerekir. Capacity planning için normal gün, yoğun saat ve toplu indexing zamanı ayrı ölçülürse daha gerçekçi sonuç elde edilir.

Ubuntu Sunucuyu Dify Kurulumuna Hazırlama

Dify kurulumuna başlamadan önce Ubuntu host'un temel güvenliğini hazırlamak daha sonra yapılacak düzeltmeleri azaltır. SSH erişimini key tabanlı hâle getirmek, root kullanımını sınırlandırmak ve yalnızca gerekli portları açmak ilk adımlar arasındadır. Sistem paketleri güncellenmeli ve saat ayarları doğrulanmalıdır. Sunucunun kim tarafından yönetileceği de kullanıcı hesapları üzerinden açıkça belirlenmelidir. Ben uygulama kurulumu öncesinde bu temel host hazırlığını tamamlamadan Docker servislerini internete açmamayı tercih ediyorum.

SSH ile Sunucuya Bağlanma

Sunucu yönetiminin başlangıç noktası genellikle SSH bağlantısıdır. İlk bağlantı cloud sağlayıcının verdiği kullanıcı veya geçici credential ile yapılabilir. Host key fingerprint ilk bağlantıda kontrol edilmelidir. Daha sonra kişisel yönetici hesabı ve SSH key kullanılmalıdır. Yönetim portunun internete açık olması gerekiyorsa IP allowlist veya VPN kullanmak saldırı alanını azaltır.

Sistem Paketlerini Güncelleme

Yeni kurulan Ubuntu sunucuda önce paket listesi yenilenmeli ve güvenlik güncellemeleri uygulanmalıdır. `apt update` ve uygun upgrade işlemleri bunun temelidir. Kernel veya kritik paket güncellemesi reboot gerektirebilir. Docker kurmadan önce sistemin stabil duruma getirilmesi hata ayıklamayı kolaylaştırır. Production ortamında güncellemeler için bakım penceresi ve rollback yaklaşımı bulunmalıdır.

Hostname ve Saat Dilimi

Anlamlı hostname sunucuyu monitoring ve log kayıtlarında ayırt etmeyi kolaylaştırır. Örneğin `dify-prod-01` gibi bir isim ortam ve rol bilgisini taşıyabilir. Saat dilimi kurum standardına göre ayarlanabilir, fakat log korelasyonu için UTC tercih eden ekipler de vardır. En önemlisi NTP senkronizasyonunun doğru çalışmasıdır. Yanlış saat API token süresi, sertifika kontrolleri ve incident timeline açısından sorun oluşturabilir.

Yeni Yönetici Kullanıcısı Oluşturma

Günlük yönetim için doğrudan root hesabı kullanmak yerine ayrı kullanıcı oluşturmak daha sağlıklıdır. Kullanıcıya yalnızca gerekli sudo yetkileri verilir. Her yönetici kendi kişisel hesabını kullanırsa audit izleri daha anlamlı olur. Shared account kullanımından kaçınmak gerekir. Çalışan ekipten ayrıldığında ilgili hesabın kapatılması da erişim yönetiminin doğal parçasıdır.

Root Kullanımını Sınırlandırma

Root hesabı tüm sistem üzerinde sınırsız yetkiye sahiptir. Günlük SSH bağlantılarında root login'i kapatmak hatalı veya ele geçirilmiş erişimin etkisini azaltır. Yönetici kullanıcı gerektiğinde sudo ile yetki yükseltebilir. Sudo logları yapılan işlemlerin takibini kolaylaştırır. Acil durum erişimi gerekiyorsa root credential güvenli ve sınırlı bir recovery sürecinde tutulabilir.

SSH Key Authentication

SSH key authentication parola tahmin saldırılarına karşı daha güçlü bir yöntemdir. Yönetici public key'i sunucudaki `authorized_keys` dosyasına eklenir. Private key kullanıcı cihazında güvenli biçimde saklanmalıdır. Mümkünse passphrase ve donanımsal anahtar gibi ek koruma kullanılabilir. Key kaybolduğunda veya çalışan ayrıldığında ilgili public key sunucudan kaldırılmalıdır.

Password Login'i Kapatma

Key authentication doğrulandıktan sonra SSH password login kapatılabilir. Bunu yapmadan önce yeni bir terminal oturumunda key ile girişin gerçekten çalıştığı test edilmelidir. Aksi hâlde kendinizi sunucunun dışında bırakabilirsiniz. SSH configuration değişikliğinden sonra servis yeniden yüklenir ve config doğrulanır. Cloud console veya recovery erişimi de acil durum için bilinmelidir.

UFW Firewall Kurulumu

UFW Ubuntu üzerinde basit host firewall yönetimi sağlar. İlk olarak SSH erişimi güvenli şekilde izinli tutulmalıdır. Ardından Dify production yayını için HTTP ve HTTPS portları açılabilir. PostgreSQL, Redis veya internal Dify servis portları internete açılmamalıdır. UFW etkinleştirilmeden önce izin listesi kontrol edilirse yanlışlıkla SSH bağlantısının kesilmesi önlenir.

SSH Portu

SSH için kullanılan port yalnızca gerekli yönetim kaynaklarına açık olmalıdır. Port numarasını değiştirmek tek başına ciddi güvenlik kontrolü değildir. Asıl koruma key authentication, root login kapatma ve kaynak IP sınırlamasından gelir. VPN üzerinden yönetim yapılabiliyorsa SSH portu genel internete hiç açılmayabilir. Fail2ban da tekrarlanan başarısız girişlere karşı ek koruma sağlar.

HTTP

TCP 80 portu genellikle Let's Encrypt doğrulaması ve HTTP'den HTTPS'e yönlendirme için kullanılır. Kullanıcı verisinin düz HTTP üzerinden işlenmemesi gerekir. Reverse proxy tüm normal trafiği HTTPS'e yönlendirebilir. HTTP servisi yalnızca Nginx gibi proxy katmanına ulaşmalıdır. Dify container'ının iç portunu ayrıca public olarak yayınlamak gereksizdir.

HTTPS

TCP 443 production Dify erişiminin ana portudur. TLS sertifikası burada sonlandırılabilir ve trafik reverse proxy üzerinden iç servise aktarılır. Güçlü TLS yapılandırması kullanılmalıdır. Admin ve uygulama kullanıcıları mümkün olduğunda aynı HTTPS güvenlik standardından yararlanmalıdır. Kurumsal erişim sadece VPN içinden olacaksa 443 portu da belirli internal kaynaklarla sınırlandırılabilir.

Fail2ban Kullanımı

Fail2ban belirli loglarda tekrar eden başarısız girişleri izleyerek kaynak IP'leri geçici olarak engelleyebilir. SSH servisinde yaygın kullanılır. Nginx veya başka servisler için de uygun jail tanımları oluşturulabilir. Fail2ban güçlü authentication'ın alternatifi değildir. En iyi sonucu SSH key, firewall ve minimum public servis yaklaşımıyla birlikte kullanıldığında verir.

Ubuntu'ya Docker Engine Kurulumu

Dify'ın Docker Compose tabanlı kurulumu için güvenilir bir Docker Engine kurulumu gerekir. Production sunucusunda dağıtımın resmî Docker repository üzerinden yapılması sürüm takibini kolaylaştırır. Önceden kurulmuş çakışan paketler varsa temizlenmelidir. Docker servisi kurulumdan sonra basit container testiyle doğrulanabilir. Docker erişiminin root seviyesine yakın yetki sağladığı unutulmamalı ve kullanıcı izinleri buna göre sınırlandırılmalıdır.

Eski Docker Paketlerini Temizleme

Ubuntu repository'sinden veya eski kurulumlardan kalan Docker paketleri yeni repository paketleriyle çakışabilir. Kurulum öncesinde mevcut Docker sürümü kontrol edilmelidir. Eski paketlerin kaldırılması gerektiğinde veri volume'larının durumu ayrıca incelenmelidir. Production sunucusunda rastgele paket silmek yerine mevcut container ve volume envanteri alınmalıdır. Temiz host üzerinde işlem daha kolay olsa da veri kaybına karşı her zaman kontrol yapılmalıdır.

Docker Resmî Repository'sini Ekleme

Docker'ın resmî repository'sini kullanmak güncel ve desteklenen paketlere erişimi kolaylaştırır. Repository anahtarı ve apt source Docker dokümantasyonuna göre eklenmelidir. Anahtar doğrulaması güvenilir paket kaynağı için önemlidir. Script kopyalarken eski blog yazıları yerine resmî dokümantasyon tercih edilmelidir. Repository eklendikten sonra paket listesi yeniden güncellenir.

Docker Engine Kurulumu

Docker Engine ve gerekli CLI bileşenleri apt üzerinden kurulabilir. Kurulumdan sonra `docker version` ile client ve server sürümleri kontrol edilir. Servisin çalıştığı `systemctl status docker` benzeri komutlarla doğrulanabilir. Production ortamında Docker daemon configuration ayrı dosyada yönetilebilir. Log rotation ve storage driver ayarları uzun süreli işletim için ayrıca değerlendirilmelidir.

Docker Compose Plugin Kurulumu

Modern Docker kurulumlarında Compose ayrı `docker-compose` binary'si yerine `docker compose` plugin olarak kullanılır. Dify'ın güncel hızlı başlangıcı Compose v2.24.0 veya üzerini bekler. Kurulumdan sonra `docker compose version` ile sürüm doğrulanmalıdır. Eski Compose v1 örnekleri güncel Dify dosyalarıyla sorun çıkarabilir. Sürüm bilgisi deployment dokümanına eklenirse başka ortamları aynı şekilde kurmak kolaylaşır.

Docker Servisini Test Etme

Kurulum sonrası küçük bir test container'ı çalıştırmak Docker daemon ve image pull işlemini doğrular. Test başarısızsa Dify kurulumuna geçmeden önce ağ veya permission sorunu çözülmelidir. DNS erişimi image registry bağlantıları için önemlidir. Proxy arkasındaki sunucularda Docker daemon proxy ayarı gerekebilir. Basit testler daha sonra Dify loglarında görülecek belirsiz hataları azaltır.

Kullanıcıyı Docker Grubuna Ekleme

Yönetici kullanıcı Docker komutlarını sudo olmadan çalıştıracaksa `docker` grubuna eklenebilir. Ancak bu grup container aracılığıyla host üzerinde geniş yetki sağlar. Bu nedenle sıradan uygulama kullanıcıları Docker grubuna eklenmemelidir. Grup değişikliğinin geçerli olması için yeniden oturum açmak gerekebilir. Kurum politikası sudo kullanımını tercih ediyorsa Docker grubu kullanmadan da yönetim yapılabilir.

Docker'ın Otomatik Başlatılması

Docker servisinin sistem açılışında otomatik başlaması production sunucusu için önemlidir. `systemctl enable docker` ile servis boot sürecine eklenebilir. Compose içindeki container restart policy değerleri de uygulama servislerinin geri gelmesini etkiler. Sunucuyu kontrollü yeniden başlatıp stack'in doğru açıldığını test etmek iyi bir doğrulamadır. Reboot testi yapılmayan sistemlerde planlanmamış yeniden başlatma sırasında sürprizler yaşanabilir.

Dify Sürümü Nasıl Seçilmeli?

Production Dify kurulumunda sürüm seçimi, kurulumu çalıştırmak kadar önemlidir. Main branch veya kontrolsüz `latest` kullanımı beklenmeyen değişiklikleri doğrudan production'a taşıyabilir. Belirli stabil release tag ile çalışmak hangi kodun aktif olduğunu açık hâle getirir. Güncellemeden önce release notes ve migration notları okunmalıdır. Ben dev ve staging ortamında yeni sürümü test etmeden kritik production instance'ı güncellememeyi temel kural olarak görüyorum.

Stable Release Kullanmak

Stable release belirli noktada test edilmiş ve yayınlanmış Dify sürümünü ifade eder. Production ortamında bu sürümler main branch'e göre daha öngörülebilir olur. Sürüm numarası deployment kayıtlarında tutulmalıdır. Güvenlik güncellemesi çıktığında mevcut versiyonla uyumluluk kontrol edilmelidir. Stabil sürüm kullanmak güncellemeleri durdurmak değil kontrollü yapmak anlamına gelir.

Main Branch Kullanmanın Riskleri

Main branch aktif geliştirme değişikliklerini içerebilir. Yeni özellikler henüz production için yeterince test edilmemiş olabilir. Compose yapısı veya environment değerleri kısa sürede değişebilir. Bu nedenle doğrudan main branch pull ederek canlı sistemi güncellemek risklidir. Geliştirme katkısı yapmıyorsanız release tag kullanmak daha güvenli olur.

Latest Tag Kullanmanın Riskleri

`latest` etiketi zaman içinde farklı image sürümünü gösterebilir. Bugün çalışan deployment aynı komutla birkaç hafta sonra farklı image indirebilir. Bu durum rollback ve audit sürecini zorlaştırır. Production'da mümkün olduğunda version pinning kullanılmalıdır. Image digest sabitlemek daha da güçlü tekrar üretilebilirlik sağlayabilir.

Belirli Bir Release Tag Sabitlemek

Release tag sabitlemek hangi Dify kod sürümünün kullanıldığını netleştirir. Güncelleme işlemi bilinçli olarak yeni tag'e geçiş şeklinde yapılır. Staging ve production aynı tag'i kullanarak test sonuçlarının karşılaştırılması kolaylaşır. Rollback gerektiğinde önceki tag bilinir. Bu yöntem değişiklik yönetiminin temelini oluşturur.

Release Notes Kontrolü

Release notes yeni özellik, düzeltme ve davranış değişikliklerini anlamak için okunmalıdır. Environment variable veya database migration değişikliği varsa deployment planı buna göre hazırlanır. Plugin sistemi gibi bileşenlerde uyumluluk notları özellikle önemlidir. Güncelleme sadece yeni image çekmek olarak görülmemelidir. Release notes üzerinden test senaryosu hazırlamak production riskini azaltır.

Security Release'lerini Takip Etmek

Self-hosted sistemde güvenlik sürümlerini takip etmek sizin sorumluluğunuzdadır. Repository release bildirimleri ve proje duyuruları düzenli izlenebilir. Kritik güvenlik düzeltmelerinde normal güncelleme takvimi beklenmeden risk değerlendirmesi yapılmalıdır. Internet-facing Dify kurulumları özellikle hızlı tepki gerektirebilir. Güncelleme sonrası smoke test ve rollback hazırlığı yine korunmalıdır.

Staging Ortamında Güncelleme Testi Yapmak

Staging production'a benzer konfigürasyonda yeni sürümü deneme alanıdır. Güncelleme önce burada uygulanır ve temel workflow, knowledge base, plugin ve API testleri çalıştırılır. Database migration davranışı gözlemlenir. Sorun görülmezse aynı sürüm production'a kontrollü olarak alınır. Staging'in amacı sadece arayüzü açmak değil gerçek kullanım akışlarını doğrulamaktır.

Ubuntu'ya Dify Nasıl Kurulur?

Ubuntu sunucuya Dify nasıl kurulur sorusunun en pratik cevabı, resmî repository'nin Docker Compose yapılandırmasını kullanmaktır. Genel akış repository'yi almak, `docker` dizinine geçmek, `.env.example` dosyasını `.env` olarak kopyalamak ve Compose stack'ini başlatmaktır. İlk kurulumda default değerleri production için olduğu gibi bırakmak yerine secret, URL ve network ayarları incelenmelidir. Servisler kalktıktan sonra container durumları ve loglar kontrol edilir. Ardından install ekranı üzerinden ilk administrator hesabı oluşturulur ve sistem domain ile HTTPS arkasına alınır.

Dify Git Repository'sini Klonlama

Öncelikle Dify'ın resmî Git repository'si sunucuya klonlanır. Production için yalnızca main branch üzerinde kalmak yerine kullanılacak release tag checkout edilmelidir. Repository'nin gerçek kaynaktan geldiği doğrulanmalıdır. Sunucu üzerinde Git geçmişi güncelleme ve sürüm takibi için yararlıdır. Deploy klasörü için sahiplik ve erişim izinleri yalnızca yönetici kullanıcılarla sınırlandırılmalıdır.

Docker Dizini

Dify repository içinde Docker Compose dosyaları `docker` dizini altında bulunur. Kurulum komutları bu dizin içinde çalıştırılır. Volume ve environment dosyalarının göreli yolları nedeniyle yanlış dizinde çalıştırmak sorun çıkarabilir. `docker compose config` komutu oluşacak birleşik yapılandırmayı kontrol etmek için kullanılabilir. Production değişikliğinden önce bu çıktıda beklenmeyen public port olup olmadığına bakmak faydalıdır.

.env.example Dosyasını Kopyalama

Başlangıç için `.env.example` dosyası `.env` olarak kopyalanır. Bu dosya Compose deployment'ın temel environment değerlerini içerir. Örnek değerler production secret'ı olarak kullanılmamalıdır. Dosya Git repository'ye yanlışlıkla commit edilmemelidir. Backup alınırken de `.env` hassas konfigürasyon olarak korunmalıdır.

Environment Değişkenlerini Yapılandırma

Environment değişkenleri console URL, API URL, database bağlantıları ve çeşitli güvenlik ayarlarını belirler. Production domain'i ve reverse proxy yapısı dikkate alınarak URL değerleri tutarlı girilmelidir. Varsayılan parolalar değiştirilmelidir. Kullanılmayan servislerin public expose değerleri kapalı tutulmalıdır. Her değişkeni internetten rastgele örnekle doldurmak yerine kullanılan Dify release'indeki `.env.example` açıklamalarına göre düzenlemek gerekir.

Docker Compose ile Servisleri Başlatma

Temel başlatma komutu `docker compose up -d` şeklindedir. `-d` container'ları arka planda çalıştırır. İlk çalıştırmada gerekli image'lar indirileceği için süre internet hızına bağlı olabilir. Komut döndükten sonra tüm servislerin hazır olduğu varsayılmamalıdır. Database ve diğer bağımlılıklar health check tamamlayana kadar loglar izlenmelidir.

Container Durumlarını Kontrol Etme

`docker compose ps` stack içindeki servislerin durumunu gösterir. `Exited`, `Restarting` veya `Unhealthy` görünen container varsa önce ilgili log incelenmelidir. Her container'ın `Up` olması uygulamanın tamamen doğru çalıştığını garanti etmez. API ve web health testleri ayrıca yapılmalıdır. Container durumunu monitoring sistemine taşımak production görünürlüğünü artırır.

İlk Log Kontrolü

Kurulum sonrasında `docker compose logs` ile servis başlangıç logları incelenebilir. Database connection, migration veya Redis hataları burada görülebilir. Çok uzun log çıktısında belirli servis adı ve `--tail` parametresi kullanmak daha pratiktir. Secret veya API key içerebilecek logları paylaşmadan önce veri kontrolü yapılmalıdır. Hata çözümünde önce ilk hata mesajına odaklanmak genellikle sonraki zincirleme hataları anlamayı kolaylaştırır.

Dify Kurulum Ekranına Erişme

Servisler doğru çalıştığında Dify ilk kurulum ekranına tarayıcı üzerinden erişilebilir. Local testte localhost veya sunucu IP'si kullanılabilir. Production ortamında kurulum ekranını mümkünse internet genelinden erişilebilir bırakmamak daha güvenlidir. Domain ve HTTPS yapılandırması erken aşamada tamamlanabilir. Kurulum bittikten sonra admin paneline erişim için ek ağ ve kimlik kontrolleri düşünülmelidir.

Admin Hesabı Oluşturma

İlk administrator hesabı güçlü ve benzersiz parola ile oluşturulmalıdır. Günlük kullanımda gerekenden fazla administrator hesabı açılmamalıdır. Shared admin hesabı yerine kişisel hesap kullanımı tercih edilmelidir. Kimlik doğrulama seçenekleri kullanılan Dify sürümü ve kurumsal yapı doğrultusunda değerlendirilmelidir. Administrator erişimleri düzenli olarak gözden geçirilmelidir.

Dify Docker Mimarisi Nasıl Çalışır?

Dify tek container'dan oluşan basit bir web uygulaması değildir. Web arayüzü, API, worker, scheduler, database, cache, vector store, reverse proxy ve plugin bileşenleri birlikte çalışır. Bu yapı bir servis bozulduğunda neden sadece belirli özelliklerin etkilenebildiğini açıklar. Örneğin web arayüzü açılırken worker sorunu nedeniyle indexing görevleri çalışmayabilir. Mimarinin temelini anlamak monitoring ve sorun giderme süresini ciddi biçimde kısaltır.

Web Frontend

Web frontend kullanıcıların Dify console ve uygulama arayüzleriyle etkileşim kurduğu katmandır. API servisinden veri alır ve tarayıcıya sunar. Reverse proxy üzerinden dış dünyaya yayınlanır. Frontend açılıyor olsa bile backend API hatalıysa bazı ekranlar çalışmayabilir. Bu nedenle sağlık kontrolünde yalnızca ana sayfayı görmek yeterli değildir.

API Service

API service Dify'ın uygulama mantığının önemli bölümünü yürütür. Console istekleri, uygulama API'leri ve birçok configuration işlemi bu katmandan geçer. PostgreSQL, Redis ve diğer servislerle bağlantı kurar. API container logları 5xx hatalarını araştırırken ilk bakılacak yerlerden biridir. Yoğun kullanımda API replica veya worker ayrımı ölçekleme planının parçası olabilir.

Worker

Worker uzun süren veya arka planda çalıştırılması gereken görevleri işler. Knowledge base indexing ve belirli asenkron süreçler worker kapasitesinden etkilenebilir. Queue büyüdüğünde kullanıcı arayüzü açık olsa bile işlemler gecikebilir. Worker concurrency değerleri CPU ve RAM kapasitesine göre ayarlanmalıdır. Monitoring içinde queue uzunluğu ve görev hata oranı mutlaka takip edilmelidir.

Worker Beat

Worker Beat zamanlanmış veya periyodik görevlerin tetiklenmesinde kullanılan bileşendir. Her workload sürekli kullanıcı isteğiyle başlamaz. Scheduler sorunu oluşursa bazı bakım veya planlı görevler sessizce çalışmayabilir. Container durumunun ayakta olması tek başına yeterli olmadığı için loglar izlenmelidir. Production monitoring planına scheduler sağlığı da eklenmelidir.

PostgreSQL

PostgreSQL Dify'ın temel kalıcı verilerinin önemli bölümünü tutar. Uygulama configuration, kullanıcı ve workflow ile ilişkili kayıtlar burada bulunabilir. Database backup bu nedenle felaket kurtarma planının ana parçalarından biridir. PostgreSQL portu genel internete yayınlanmamalıdır. Büyük production kurulumlarında harici veya yönetilen PostgreSQL kullanımı ölçeklenebilirlik ve yedekleme açısından değerlendirilebilir.

Redis

Redis cache ve queue gibi hızlı veri işlemlerinde kullanılan destek servisidir. Worker süreçlerinin sağlıklı çalışması için Redis bağlantısı önemlidir. Redis'in internete açık ve zayıf parola ile çalışması ciddi güvenlik riskidir. Internal Docker network içinde tutulması daha güvenli varsayımdır. Redis memory kullanımı ve bağlantı hataları monitoring kapsamında izlenmelidir.

Vector Database

Vector database RAG knowledge base içindeki embedding kayıtlarının aranmasını sağlar. Doküman chunk'ları embedding vektörleriyle ilişkilendirilir. Sorgu geldiğinde benzer içerikler bu katmandan geri getirilir. Büyük bilgi tabanlarında index büyüklüğü ve sorgu latency'si önemli hâle gelir. Backup ve restore planı kullanılan vector database teknolojisine göre ayrıca hazırlanmalıdır.

Nginx

Dify Compose mimarisinde Nginx veya dış host seviyesinde Nginx reverse proxy görevi görebilir. Kullanıcı bağlantıları tek giriş noktasında karşılanır. HTTPS, request body limiti ve timeout gibi ayarlar burada yönetilebilir. Streaming cevaplar için buffering ve timeout davranışı önemlidir. Public portları yalnızca proxy katmanına vermek servislerin doğrudan internete açılmasını önler.

Plugin Servisleri

Dify plugin sistemi model, tool ve başka entegrasyonların platforma eklenmesini sağlar. Plugin servisleri kod çalıştırdığı için güven kaynağı değerlendirilmelidir. Production ortamında rastgele plugin yüklemek uygulama güvenlik alanını büyütebilir. Plugin sürümleri ve kaynakları kayıt altında tutulmalıdır. Güncelleme sonrasında plugin uyumluluğu staging ortamında test edilmelidir.

Agent ile İlgili Servisler

Yeni Dify mimarisinde agent çalıştırma ve ilgili runtime servisleri sürüme göre ayrı bileşenler içerebilir. Bu servislerin network erişimi özellikle önemlidir çünkü agent tool çağrıları yapabilir. Internal servislerin internete gereksiz şekilde expose edilmemesi gerekir. Agent execution logları maliyet ve güvenlik analizi için izlenmelidir. Kullandığınız release'in Compose dosyasını inceleyerek gerçek servis listesini doğrulamak en güvenli yöntemdir.

Container'lar Arasındaki Ağ İletişimi

Container'lar Docker network üzerinden servis isimleriyle birbirine ulaşabilir. PostgreSQL veya Redis gibi servisleri host public IP'si üzerinden çağırmaya gerek yoktur. Internal network kullanımı portların dış dünyaya açılmasını önler. Docker network segmentlerini anlamak SSRF ve servis exposure risklerini değerlendirmede yardımcı olur. Production'da `docker compose config` çıktısı ve `ss -tulpn` ile host üzerinde hangi portların gerçekten dinlediği kontrol edilmelidir.

Dify .env Dosyası Nasıl Yapılandırılır?

Dify `.env` dosyası deployment davranışını belirleyen en önemli configuration kaynaklarından biridir. URL, secret, database, Redis, storage, vector store ve worker seçenekleri burada veya ilgili environment dosyalarında yönetilebilir. Dify sürümleri geliştikçe değişken yapısı değişebildiği için eski blog örneklerini doğrudan kopyalamak doğru değildir. Her zaman kullandığınız release'in `.env.example` dosyasını referans alın. Production secret değerlerini version control sistemine göndermeden güvenli şekilde yönetmek gerekir.

SECRET_KEY

SECRET_KEY uygulamanın güvenlik amaçlı kullandığı kritik gizli değerlerden biridir. Örnek veya tahmin edilebilir değer bırakılmamalıdır. Güçlü rastgele değer üretilmeli ve güvenli yerde saklanmalıdır. Değer değiştirmenin mevcut oturum veya şifreli kayıtlar üzerindeki etkisi release dokümantasyonuna göre değerlendirilmelidir. Bu yüzden secret rotation plansız yapılmamalıdır.

Console URL

Console URL administrator ve geliştirici arayüzünün dışarıdan hangi adres üzerinden erişildiğini tanımlamada kullanılır. Reverse proxy ve domain configuration ile tutarlı olmalıdır. HTTPS production'da tercih edilmelidir. Yanlış URL bazı redirect veya callback problemlerine yol açabilir. Dev, staging ve production ortamlarında farklı domain kullanılıyorsa değerler ortam bazında ayrılmalıdır.

App URL

App URL kullanıcıya sunulan uygulama adreslerinin oluşturulmasında etkili olabilir. Public chatbot veya webapp yayınlanacaksa dış domain yapısıyla tutarlı olmalıdır. Reverse proxy arkasında HTTP ve HTTPS ayrımı doğru bildirilmelidir. Yanlış host veya scheme kullanımı paylaşılan linklerin hatalı oluşmasına yol açabilir. Production deployment sonrası dışarıdan gerçek URL ile test yapılmalıdır.

API URL

API URL uygulama ve servis çağrılarının doğru endpoint'e yönelmesini sağlar. Backend internal URL ile public API URL birbirinden farklı olabilir. Reverse proxy kullanılıyorsa dış istemciler doğrudan internal container adına erişmemelidir. HTTPS domain kullanımı API client'ları için daha güvenlidir. URL değişiklikleri mevcut entegrasyonları etkileyebileceği için change management kapsamında yapılmalıdır.

PostgreSQL Ayarları

PostgreSQL host, port, database, user ve password değerleri doğru tanımlanmalıdır. Default parolalar production'da mutlaka değiştirilmelidir. Harici database kullanılıyorsa network erişimi yalnızca Dify sunucularıyla sınırlandırılabilir. TLS bağlantısı kurum gereksinimine göre etkinleştirilebilir. Connection pool ve max connection değerleri kullanıcı yükü arttığında izlenmelidir.

Redis Ayarları

Redis bağlantı adresi ve credential değerleri environment yapılandırmasının önemli parçalarındandır. Redis public internete açık olmamalıdır. Ayrı host kullanılıyorsa private network veya firewall allowlist tercih edilmelidir. Password ve gerekiyorsa TLS desteği kullanılmalıdır. Worker queue gecikmelerinde Redis latency ve memory kullanımı incelenmelidir.

Storage Ayarları

Dify upload edilen dosyaları local volume veya desteklenen harici storage seçeneklerinde tutabilir. Tek sunuculu küçük kurulumda local disk pratik olabilir. Çoklu replica veya Kubernetes ortamında object storage daha uygun olabilir. Storage seçimi backup ve restore planını doğrudan etkiler. Dosya verisi ile database backup'ın tutarlı zaman noktasında alınması önemlidir.

Vector Database Ayarları

Vector database seçimi RAG performansı ve operasyon modelini etkiler. Connection URL, authentication ve index ayarları kullanılan backend'e göre değişir. Default kurulumu production ölçeğinde olduğu gibi kullanmak zorunlu değildir. Büyük dataset için harici vector store seçeneği değerlendirilebilir. Backup, restore ve migration desteği seçim kriterleri arasında olmalıdır.

Worker Ayarları

Worker concurrency ve timeout gibi ayarlar background işlemlerin kapasitesini belirler. Değeri çok yükseltmek daha hızlı sistem garantisi vermez. CPU, RAM ve external API limitleri darboğaz oluşturabilir. Queue uzunluğu ve task duration ölçülerek ayar yapılmalıdır. Staging load testi worker tuning için güvenli ortam sağlar.

Dosya Yükleme Limitleri

Knowledge base veya workflow içinde büyük dosya yükleme ihtiyacı varsa upload limitleri kontrol edilmelidir. Limit yalnızca Dify tarafında değil reverse proxy üzerinde de bulunabilir. Nginx `client_max_body_size` gibi ayarlar uyumlu olmalıdır. Gereksiz büyük upload sınırı disk tüketimi ve abuse riskini artırabilir. Kurumun gerçek belge boyutuna göre makul değer belirlemek daha güvenlidir.

Log Seviyesi

Log level development ortamında ayrıntılı, production'da ise ihtiyaç kadar bilgi üretecek şekilde seçilmelidir. Debug log hassas verileri veya büyük miktarda ayrıntıyı kaydedebilir. Sürekli debug açık bırakmak hem disk hem gizlilik açısından sorun oluşturabilir. Hata araştırmasında geçici olarak yükseltilebilir. Log retention ve merkezi toplama politikasıyla birlikte yönetilmelidir.

Timeout Ayarları

LLM ve tool çağrıları klasik web isteklerinden daha uzun sürebilir. API, worker ve Nginx timeout değerleri birbiriyle uyumlu olmalıdır. Çok düşük timeout kullanıcıya sık hata gösterirken aşırı yüksek timeout kaynakların uzun süre meşgul kalmasına yol açabilir. Streaming kullanımında proxy davranışı ayrıca test edilmelidir. Her workflow için beklenen maksimum süreyi bilmek uygun timeout belirlemeyi kolaylaştırır.

.env Dosyasını Güvenli Tutmak

`.env` dosyası database şifresi, secret ve API key gibi hassas değerler içerebilir. Dosya izinleri yalnızca gerekli kullanıcılarla sınırlandırılmalıdır. Git repository'ye commit edilmemelidir. Backup kopyaları da şifreli veya erişimi kontrollü depoda tutulmalıdır. Daha gelişmiş production ortamlarında secret manager kullanarak hassas değerleri düz dosyadan çıkarmak değerlendirilebilir.

Secret Yönetimi Nasıl Yapılmalı?

Secret yönetimi self-hosted Dify güvenliğinin en önemli alanlarından biridir. Model API key'leri, database parolaları ve uygulama secret'ları kaynak koddan ayrı tutulmalıdır. Default değerler production'a taşınmamalıdır. Secret kullanımının kimler tarafından görülebildiği ve ne zaman değiştirildiği kayıt altına alınmalıdır. Bu konuda daha ayrıntılı otomasyon ve veri işleme örnekleri için https://www.diyarbakiryazilim.com.tr/posts/otonom-llm-destekli-veri-on-isleme-sistemleri-gelistirmek adresindeki içeriği de inceleyebilirsiniz.

Varsayılan Parolaları Değiştirmek

Compose örneklerinde geliştirme için kullanılabilecek varsayılan parola değerleri bulunabilir. Production'a geçmeden önce bunların tamamı değiştirilmelidir. PostgreSQL, Redis, plugin ve internal servis credential'ları kontrol edilmelidir. Güçlü ve benzersiz parolalar kullanılmalıdır. Değişiklik sonrası servislerin yeni credential ile gerçekten bağlandığı doğrulanmalıdır.

Güçlü SECRET_KEY Oluşturmak

SECRET_KEY tahmin edilemez ve yeterli entropiye sahip rastgele değer olmalıdır. İnsan tarafından seçilmiş cümle kullanmak yerine güvenli random generator tercih edilmelidir. Key terminal history içinde görünür bırakılmamalıdır. Secret manager veya güvenli password vault içinde saklanabilir. Rotation gerekiyorsa uygulama etkisi önceden test edilmelidir.

PostgreSQL Parolası

Database kullanıcısı yalnızca Dify'ın gerektirdiği yetkilere sahip olmalıdır. Production parolası başka sistemlerde tekrar kullanılmamalıdır. Harici PostgreSQL sunucusunda network allowlist uygulanmalıdır. Credential rotation bakım penceresinde test edilerek yapılabilir. Backup dosyalarının database secret'ından ayrı korunması gerekir.

Redis Parolası

Redis internal servis olsa bile authentication kullanmak defense in depth sağlar. Public port exposure kesinlikle önlenmelidir. Parola `.env` veya secret manager üzerinden sağlanabilir. Rotation sırasında worker ve API servislerinin aynı anda güncel credential kullanması gerekir. Redis connection error logları değişiklik sonrası yakından izlenmelidir.

Model API Key'leri

Cloud LLM sağlayıcılarının API key'leri doğrudan frontend'e verilmemelidir. Key'ler Dify model provider configuration veya güvenli backend secret store içinde tutulmalıdır. Kullanım limitleri ve billing alarmı sağlayıcı tarafında etkinleştirilebilir. Her ortam için ayrı API key kullanmak izleme ve rotation sürecini kolaylaştırır. Çalışan ayrıldığında kişisel hesaplara bağlı key'ler mutlaka yenilenmelidir.

Secret'ları Git'e Göndermemek

`.env`, private key veya model credential dosyaları Git repository'ye commit edilmemelidir. `.gitignore` yardımcıdır, fakat tek güvenlik kontrolü değildir. Secret scanning araçları pull request aşamasında yanlışlıkla eklenen credential'ları bulabilir. Bir secret Git geçmişine girdiyse dosyayı silmek yeterli değildir. İlgili credential derhal iptal edilmeli ve yenisi oluşturulmalıdır.

Secret Rotation

Secret rotation belirli credential'ların planlı aralıklarla veya olay sonrası yenilenmesidir. Rotation için önce hangi servislerin secret'a bağlı olduğu çıkarılmalıdır. Yeni secret devreye alındığında tüm client'lar güncellenmelidir. Bazı servislerde geçiş süresi için iki credential'ın paralel çalışması mümkün olabilir. Başarılı rotation log ve testlerle doğrulanmalıdır.

Production Secret Manager Kullanımı

Büyük production ortamında secret manager kullanmak düz `.env` dosyasına bağımlılığı azaltabilir. Merkezi erişim kontrolü ve audit log avantaj sağlar. Dify deployment yöntemiyle secret manager arasında entegrasyon katmanı tasarlanmalıdır. Container başlangıcında secret değerleri environment veya mounted file olarak sağlanabilir. Bu yaklaşımın da credential bootstrap sorununu çözmesi gerektiği unutulmamalıdır.

Dify'ı Domain Üzerinden Yayınlama

Production Dify instance'ını IP ve port üzerinden kullanmak yerine domain üzerinden yayınlamak yönetimi kolaylaştırır. DNS A kaydı sunucuya yönlendirilir ve Nginx reverse proxy dış bağlantıları karşılar. İç Dify portu public internetten kapalı tutulabilir. Proxy üzerinden HTTPS, rate limit ve güvenlik header'ları uygulanabilir. Domain tasarımı daha sonra staging veya API servislerini ayrı alt alan adlarında yönetmeyi de kolaylaştırır.

DNS A Kaydı Oluşturma

Domain sağlayıcısında seçilen alt alan adı Dify sunucusunun public IP adresine yönlendirilir. DNS değişikliği propagation süresine sahip olabilir. `dig` veya `nslookup` ile doğru IP'nin döndüğü kontrol edilmelidir. Cloud proxy kullanılıyorsa gerçek client IP header'ları ayrıca dikkate alınmalıdır. Sertifika almadan önce DNS çözümlemesinin doğru çalışması gerekir.

Dify İç Portunu Belirleme

Dify'ın dışarıya sunulduğu internal port Compose yapılandırmasına göre belirlenir. Host-level Nginx bu porta localhost veya private interface üzerinden bağlanabilir. Portun `0.0.0.0` üzerinden public dinlemesi gerekmiyorsa sınırlandırılmalıdır. UFW ile dış erişim kapatılabilir. Bu tasarım kullanıcıların doğrudan proxy katmanını atlayarak uygulamaya bağlanmasını önler.

Host-Level Nginx Kurulumu

Nginx Ubuntu paket yöneticisi üzerinden host'a kurulabilir. Dify için ayrı server block oluşturmak yönetimi kolaylaştırır. Configuration syntax `nginx -t` ile doğrulanmadan reload yapılmamalıdır. Default site kullanılmıyorsa kapatılabilir. Nginx logları access ve error analizi için merkezi monitoring sistemine gönderilebilir.

Reverse Proxy Yapılandırması

Reverse proxy kullanıcının HTTPS isteğini alır ve Dify internal servisine iletir. `proxy_pass` hedefi public IP yerine local veya Docker erişim noktasına yönlendirilmelidir. Host ve protocol header'ları doğru iletilmelidir. WebSocket veya streaming kullanımında gerekli proxy seçenekleri kontrol edilmelidir. Configuration değişikliği sonrası hem console hem app API test edilmelidir.

Proxy Header'ları

`Host`, `X-Real-IP` ve `X-Forwarded-For` gibi header'lar backend'in gerçek request bağlamını anlamasına yardımcı olur. HTTPS termination proxy'de yapılıyorsa `X-Forwarded-Proto` bilgisi önemlidir. Yanlış header güvenilirliği client IP spoofing riskine yol açabilir. Sadece kontrol ettiğiniz proxy'den gelen forwarded header değerlerine güvenmek gerekir. Dify ve Nginx loglarında gerçek IP'nin beklendiği gibi göründüğü test edilmelidir.

Streaming İçin Proxy Ayarları

LLM yanıtları streaming olarak kullanıcıya parça parça gönderilebilir. Proxy buffering yanlış ayarlandığında kullanıcı tüm cevabı ancak sonunda görebilir. Uzun süren model çağrıları için read timeout değeri de önemlidir. Nginx configuration gerçek Dify streaming endpoint'leriyle test edilmelidir. Mobil ağ veya yavaş client senaryoları da production öncesinde denenebilir.

Büyük Dosya Upload Limitleri

Knowledge base'e büyük PDF veya Word dosyaları yüklenecekse Nginx body limit kontrol edilmelidir. Limit Dify tarafındaki dosya boyutu ayarıyla uyumlu olmalıdır. Gereğinden büyük sınır koymak abuse ve disk tüketimi riskini artırabilir. Kurumun gerçek doküman boyutlarını ölçmek en iyi başlangıçtır. Upload başarısızlığında hem Nginx error log hem Dify application log incelenmelidir.

Proxy Timeout Ayarları

Uzun süren workflow ve model çağrıları standart proxy timeout değerlerini aşabilir. Bunun sonucu kullanıcı 504 veya bağlantı kapanması görebilir. Timeout'u sınırsız artırmak yerine gerçek workflow süresi ölçülmelidir. Çok uzun işlemler asenkron tasarıma taşınabilir. API, worker ve proxy timeout değerlerinin birbirine uygun olması gerekir.

Dify İçin HTTPS ve SSL Kurulumu

HTTPS production Dify kurulumu için temel güvenlik gereksinimidir. Login bilgileri, conversation içeriği ve API token'ları ağ üzerinden şifreli taşınmalıdır. Let's Encrypt ve Certbot küçük kurulumlarda pratik bir çözüm sağlar. Kurumsal PKI kullanan şirketler kendi sertifika altyapılarını tercih edebilir. Sertifika kurulumu kadar otomatik yenileme ve yenileme testi de işletim planının parçasıdır.

Let's Encrypt

Let's Encrypt ücretsiz ve otomatik yenilenebilir TLS sertifikaları sunar. Domain'in doğru DNS kaydı bulunmalıdır. HTTP veya DNS challenge yöntemlerinden uygun olanı kullanılabilir. Public olmayan internal domain'lerde şirket PKI daha uygun olabilir. Sertifika issuance limitleri ve otomasyon davranışı production tasarımında dikkate alınmalıdır.

Certbot Kurulumu

Certbot Ubuntu üzerinde paket veya önerilen dağıtım yöntemiyle kurulabilir. Nginx entegrasyonu sertifika alma ve configuration güncellemeyi kolaylaştırır. Kurulum kaynağı güncel resmî Certbot dokümantasyonuna göre seçilmelidir. Sistem üzerinde eski Certbot sürümü varsa kontrol edilmelidir. Otomatik yenileme timer'ının aktif olduğu doğrulanmalıdır.

SSL Sertifikası Alma

Domain sunucuya doğru yönlendikten sonra Certbot ile sertifika alınabilir. Nginx server name configuration domain ile eşleşmelidir. Sertifika üretildikten sonra tarayıcı ve `curl` ile HTTPS bağlantısı test edilir. Sertifika zinciri ve hostname doğrulaması kontrol edilmelidir. Private key dosyasının erişim izinleri sıkı tutulmalıdır.

HTTP'den HTTPS'e Yönlendirme

HTTP istekleri kalıcı olarak HTTPS'e yönlendirilebilir. Böylece kullanıcı yanlışlıkla düz HTTP adresi kullansa bile güvenli bağlantıya geçer. Redirect loop oluşmaması için proxy ve Dify URL ayarları uyumlu olmalıdır. API client'larının da HTTPS endpoint kullanması gerekir. HTTP portu yalnızca redirect ve sertifika doğrulaması için kullanılabilir.

Otomatik Sertifika Yenileme

Let's Encrypt sertifikaları kısa süreli olduğu için otomatik yenileme önemlidir. Certbot systemd timer veya cron mekanizması kullanabilir. Yenileme sonrası Nginx'in yeni sertifikayı yüklemesi gerekir. Expiry monitoring ayrıca alarm üretebilir. Böylece otomasyon başarısız olduğunda sertifika bitmeden müdahale edilebilir.

Sertifika Yenilemeyi Test Etmek

Otomatik görev tanımlanmış olması gerçek yenilemenin çalışacağını garanti etmez. Certbot dry-run ile yenileme senaryosu test edilebilir. DNS, firewall ve HTTP challenge erişimi doğrulanmalıdır. Test hataları production sertifika süresi dolmadan çözülmelidir. Bu kontrol aylık veya değişiklik sonrası tekrar yapılabilir.

Dify Sunucusunu İnternete Güvenli Açmak

Self-hosted Dify'ı internete açarken amaç mümkün olan en az servisi public hâle getirmektir. Genellikle kullanıcı trafiği için 80 ve 443 yeterlidir. Database, Redis, plugin internal portları ve model servisleri dış dünyaya açık olmamalıdır. Yönetim erişimi VPN veya IP allowlist üzerinden sınırlandırılabilir. Rate limiting, güçlü authentication ve düzenli security update internet-facing deployment için birlikte uygulanmalıdır.

Yalnızca 80 ve 443 Portlarını Açmak

Public web erişimi gereken tipik kurulumda yalnızca HTTP ve HTTPS portları dışarı açılır. SSH farklı kaynak kısıtlamasına tabi tutulabilir. Docker Compose'ta servis portlarının host üzerinde gereksiz yayınlanmadığı kontrol edilmelidir. `ss -tulpn` aktif dinleyen servisleri görmenizi sağlar. Cloud security group ile UFW aynı güvenlik hedefini desteklemelidir.

İç Dify Portunu İnternete Kapatmak

Reverse proxy kullanıyorsanız Dify'ın internal web portunu internete açmanız gerekmez. Kullanıcılar yalnızca Nginx üzerinden erişmelidir. Bu yapı HTTPS ve rate limit kontrollerinin bypass edilmesini önler. Port binding localhost veya internal interface ile sınırlandırılabilir. Dış ağdan port taramasıyla gerçekten kapalı olduğu test edilmelidir.

Database Portlarını Yayınlamamak

PostgreSQL portunun public internete açılması çoğu Dify deployment için gereksizdir. Container internal network veya private subnet kullanılması yeterlidir. Harici database varsa firewall sadece Dify kaynak IP'lerine izin vermelidir. Güçlü password tek başına public exposure için yeterli savunma değildir. Database logları şüpheli bağlantılar açısından izlenmelidir.

Redis'i İnternete Açmamak

Redis özellikle public exposure konusunda hassas bir servistir. Dify container'ları internal network üzerinden erişebilir. Harici Redis kullanılıyorsa private network ve authentication uygulanmalıdır. Public IP üzerinde 6379 dinlemesi gerekmemelidir. Cloud firewall ve host firewall ile erişim iki katmanlı sınırlandırılabilir.

IP Allowlist

Administrator console sadece belirli ofis veya VPN IP'lerinden erişilecekse allowlist kullanılabilir. Bu yöntem public saldırı alanını azaltır. Dinamik IP kullanan ekiplerde VPN daha yönetilebilir olabilir. IP allowlist güçlü authentication'ın alternatifi değildir. Değişen kaynak IP'ler için güncelleme süreci oluşturulmalıdır.

VPN ile Yönetim

Dify yönetim erişimini VPN içine almak admin panelinin public exposure'ını azaltır. Kullanıcı uygulaması public kalırken console yalnızca internal route üzerinden erişilebilir. MFA destekli VPN tercih edilebilir. Yönetim kullanıcıları kişisel hesaplarla bağlanmalıdır. VPN kesintisi için emergency access prosedürü önceden hazırlanmalıdır.

Rate Limiting

Rate limiting tek client'ın kısa sürede aşırı sayıda request göndermesini sınırlar. Nginx veya API gateway seviyesinde uygulanabilir. Login, public app ve API endpoint'leri için farklı limit gerekebilir. Çok düşük limit gerçek kullanıcıları etkileyebilir. Eşikler normal trafik ölçümlerine ve abuse riskine göre belirlenmelidir.

Brute-Force Koruması

Login endpoint'lerinde tekrarlanan başarısız denemeler izlenmelidir. Reverse proxy, WAF veya Fail2ban gibi araçlar ek engelleme sağlayabilir. MFA desteği varsa administrator hesapları için kullanılmalıdır. Başarısız login logları merkezi SIEM'e gönderilebilir. Account lockout politikası kullanıcı deneyimi ve saldırı riskini dengeli yönetmelidir.

Admin Panelini Koruma

Admin paneli normal kullanıcı uygulamasından daha yüksek yetkiye sahiptir. Public erişim gerekiyorsa ek authentication veya network kısıtlaması uygulanabilir. Administrator sayısı minimum tutulmalıdır. Session süresi ve login event'leri izlenmelidir. Kullanılmayan admin hesapları hızla kapatılmalıdır.

Dify'a Yapay Zeka Modeli Nasıl Eklenir?

Dify farklı model sağlayıcılarını ortak arayüz üzerinden yönetmenizi sağlar. Chat modeli, embedding modeli ve reranker aynı sağlayıcıdan gelmek zorunda değildir. Cloud API, OpenAI-compatible endpoint veya local model altyapısı kullanılabilir. Model eklerken yalnızca bağlantının çalışmasına değil veri akışı ve maliyet politikasına da bakmak gerekir. Varsayılan model seçimi her workflow için otomatik doğru model anlamına gelmediğinden kullanım senaryosu bazlı seçim yapmak daha faydalıdır.

Model Provider Kavramı

Model provider Dify'ın model servisiyle nasıl iletişim kuracağını tanımlayan entegrasyon katmanıdır. Provider configuration içinde API endpoint ve credential gibi bilgiler bulunabilir. Birden fazla model aynı provider üzerinden kullanılabilir. Plugin tabanlı model sağlayıcıları sürüme göre ayrıca kurulabilir. Provider kurulumu sonrasında basit prompt ile bağlantı ve yetki testi yapılmalıdır.

Cloud LLM Sağlayıcıları

Cloud LLM servisleri güçlü modellere yerel GPU yatırımı olmadan erişim sağlar. API üzerinden kullanım başına maliyet oluşur. Veri işleme koşulları ve bölgesel gereksinimler kurum açısından incelenmelidir. Provider dashboard üzerinde bütçe ve rate limit ayarları yapılabilir. Farklı görevler için farklı model sınıfları kullanmak maliyet kontrolü sağlar.

OpenAI-Compatible API Kullanımı

Birçok inference sunucusu OpenAI-compatible API sunarak entegrasyonu kolaylaştırır. Dify uygun provider veya custom endpoint üzerinden bu API'lere bağlanabilir. Base URL, API key ve model adı doğru tanımlanmalıdır. Tüm OpenAI-compatible implementasyonların davranışı birebir aynı olmayabilir. Streaming, tool calling ve structured output özellikleri ayrı test edilmelidir.

Chat Modeli

Chat modeli kullanıcı mesajına doğal dil yanıtı üretir. Workflow ve chatbot uygulamalarının ana LLM katmanı olabilir. Model seçerken kalite, context penceresi, latency ve maliyet birlikte değerlendirilmelidir. Her görev için en büyük modeli kullanmak gerekli değildir. Classification veya kısa özetleme işleri daha küçük modelle daha ekonomik çalışabilir.

Embedding Modeli

Embedding modeli metni vektör temsil hâline getirerek semantic search yapılmasını sağlar. Knowledge base indexing sırasında kullanılan embedding modeli retrieval kalitesini doğrudan etkiler. Index oluşturulduktan sonra modeli değiştirmek yeniden embedding gerektirebilir. Çok dilli Türkçe içerikte modelin dil performansı özellikle test edilmelidir. RAG kalitesi için kendi soru setinizle retrieval benchmark yapmak önemlidir.

Reranker

Reranker ilk retrieval sonucundaki belgeleri sorguya göre yeniden sıralar. Özellikle benzer çok sayıda chunk bulunan bilgi tabanlarında cevap kalitesini artırabilir. Ek model çağrısı latency ve maliyet oluşturabilir. Her projede zorunlu değildir. Retrieval testlerinde reranker açık ve kapalı sonuçları karşılaştırılarak gerçek fayda ölçülmelidir.

Speech ve Multimodal Modeller

Dify kullanılan provider özelliklerine göre konuşma veya multimodal modellerle de çalışabilir. Görsel, ses veya belge analizi için farklı model yetenekleri gerekir. Input boyutu ve format limitleri uygulama tasarımına dahil edilmelidir. Hassas görsel veya ses verisinin dış sağlayıcıya gönderilip gönderilmediği veri politikası açısından değerlendirilmelidir. Multimodal akışlarda token ve latency maliyeti klasik text chat'ten daha yüksek olabilir.

Varsayılan Model Seçimi

Varsayılan model yeni uygulamalarda kolaylık sağlar, ancak bütün workflow'ların aynı modele bağlı olması gerekmez. Classification için küçük, final answer için daha güçlü model kullanılabilir. Local ve cloud modeller arasında koşullu routing yapılabilir. Model başarısız olduğunda fallback stratejisi tasarlanabilir. Varsayılan seçim belli aralıklarla kalite ve maliyet ölçümleriyle yeniden değerlendirilmelidir.

Ollama ile Dify'a Local LLM Bağlama

Ollama local LLM modellerini Ubuntu üzerinde çalıştırmayı kolaylaştıran popüler bir inference aracıdır. Dify ile birlikte kullanıldığında model çağrıları şirketin kontrol ettiği sunucuya yönlendirilebilir. Dify container'larının Ollama host'una ulaşabilmesi için network adreslemesi doğru yapılmalıdır. Ollama servisinin public internete açılması genellikle gerekli değildir. Model bağlantısı kurulduktan sonra yalnızca “cevap geliyor” kontrolü değil latency, context ve eşzamanlı kullanıcı testleri de yapılmalıdır.

Ollama Nedir?

Ollama çeşitli açık model ailelerini yerel veya sunucu ortamında çalıştırmayı kolaylaştırır. Model indirme ve servis endpoint'i oluşturma işlemlerini basitleştirir. Dify gibi orkestrasyon platformları Ollama API üzerinden modellere bağlanabilir. Ollama kendi başına workflow veya RAG yönetim platformu değildir. Dify ile birlikte kullanıldığında inference ve application orchestration sorumlulukları ayrılmış olur.

Ubuntu'ya Ollama Kurulumu

Ollama Ubuntu sunucuda resmî kurulum yöntemine göre yüklenmelidir. Kurulum script'i kullanılacaksa kaynağı doğrulanmalıdır. Servis systemd altında çalıştırılabilir ve boot sırasında otomatik başlatılabilir. GPU driver uyumluluğu local inference performansı için önemlidir. Kurulum sonrası API endpoint'i host üzerinden test edilmelidir.

Model İndirme

Ollama model dosyalarını pull komutuyla indirebilir. Model seçimi sunucunun RAM ve VRAM kapasitesine göre yapılmalıdır. Llama veya Qwen ailesindeki farklı boyutların performansı kendi görev verinizle ölçülmelidir. Bir modelin genel benchmark başarısı şirket dokümanlarındaki Türkçe soru cevap kalitesini garanti etmez. İlk aşamada daha küçük modelle başlayıp gerçek test sonuçlarına göre büyütmek pratik bir yöntemdir.

Embedding Modeli İndirme

RAG için chat modelinden ayrı embedding modeli gerekebilir. Ollama veya başka local servis üzerinden embedding sunulabilir. Türkçe ve çok dilli veri için embedding modelinin retrieval performansı test edilmelidir. Model değişirse knowledge base yeniden index gerektirebilir. Embedding latency yoğun ingestion sırasında worker kapasitesini etkileyebilir.

Ollama Network Ayarları

Ollama'nın hangi interface üzerinde dinlediği güvenlik açısından önemlidir. Dify aynı host'taysa public internet yerine local veya private interface yeterlidir. Ayrı sunucudaysa sadece Dify subnet'inden erişime izin verilebilir. Firewall ile API portu sınırlandırılmalıdır. Authentication desteği bulunmayan veya sınırlı servislerde reverse proxy ve private network özellikle önem kazanır.

Docker Container'dan Host Ollama'ya Erişim

Container içindeki `localhost` container'ın kendisini ifade eder, host işletim sistemini değil. Bu nedenle Dify container'ından host Ollama'ya erişmek için uygun host gateway veya reachable IP kullanılmalıdır. Linux Docker ortamında Compose network ve `host-gateway` seçenekleri değerlendirilebilir. Adresin development örneklerinden kopyalanması yerine gerçek network tasarımına göre belirlenmesi gerekir. Container içinden `curl` ile endpoint testi yaparak bağlantı doğrulanabilir.

Dify Model Provider Ayarları

Dify model provider ekranında Ollama endpoint'i ve model adı tanımlanır. Chat ve embedding modelleri ayrı eklenebilir. Base URL container tarafından erişilebilir adres olmalıdır. Model configuration tamamlandığında test özelliğiyle basit istek gönderilir. Hata varsa önce network, ardından model adı ve Ollama logları kontrol edilmelidir.

Ollama Bağlantısını Test Etme

İlk test doğrudan Ollama host üzerinde API çağrısıyla yapılmalıdır. Ardından aynı endpoint Dify container içinden test edilir. Son aşamada Dify model provider üzerinden prompt gönderilir. Bu üç aşama sorunun network mü yoksa Dify configuration mı olduğunu ayırmayı kolaylaştırır. Testte response süresi de kaydedilirse ileride performans karşılaştırması yapılabilir.

Local Model Performansını İzleme

Local model kullanırken GPU utilization, VRAM, RAM ve token üretim hızı izlenmelidir. Eşzamanlı kullanıcı arttığında queue veya latency hızla yükselebilir. Model context uzunluğu kaynak tüketimini etkiler. Kullanıcı açısından time-to-first-token ve toplam cevap süresi ölçülmelidir. Bu veriler model boyutu veya GPU kapasitesi artırma kararını somutlaştırır.

Local LLM mi Cloud API mi?

Local LLM ve cloud API arasında tek bir doğru seçim yoktur. Hassasiyet, model kalitesi, maliyet, latency ve ekip kapasitesi birlikte değerlendirilmelidir. Local model veri kontrolü sağlayabilir, ancak GPU ve operasyon gerektirir. Cloud API güçlü modellere hızlı erişim verir, fakat kullanım maliyeti ve dış veri aktarımı dikkate alınmalıdır. Birçok kurum için en verimli yaklaşım iki modeli görev türüne göre birlikte kullanan hibrit mimaridir.

Gizlilik

Local LLM kullanımı prompt ve context verisinin şirket altyapısında kalmasını sağlayabilir. Ancak Dify içindeki tool veya başka API çağrıları veriyi yine dışarı gönderebilir. Cloud model kullanımında sağlayıcının veri işleme koşulları incelenmelidir. Hassas veri sınıfları belirlenerek hangi modelin kullanılabileceği policy olarak tanımlanabilir. Gizlilik kontrolü yalnızca model seçimi değil tüm workflow akışının kontrolüdür.

Maliyet

Cloud API kullanımında maliyet genellikle token veya istek miktarına göre artar. Local modelde GPU, elektrik, bakım ve kapasite maliyeti öne çıkar. Düşük kullanımda cloud API daha ekonomik olabilir. Yoğun ve öngörülebilir kullanımda local inference avantaj sağlayabilir. Gerçek karşılaştırma için aylık toplam token, GPU maliyeti ve operasyon zamanı birlikte hesaplanmalıdır.

Gecikme

Cloud API internet bağlantısı ve sağlayıcı yüküne bağlı latency oluşturur. Local model network olarak daha yakın olabilir, fakat zayıf donanımda üretim hızı düşük kalabilir. Time-to-first-token kullanıcı deneyiminde önemli metriktir. RAG ve tool çağrıları toplam latency'ye modelden daha fazla ek süre de katabilir. Bu nedenle yalnızca tek model benchmark'ı yerine uçtan uca workflow süresi ölçülmelidir.

Model Kalitesi

Büyük cloud modelleri bazı karmaşık görevlerde küçük local modellere göre daha yüksek kalite sunabilir. Buna karşılık iyi tasarlanmış RAG ve task-specific prompt ile küçük model birçok kurumsal görevde yeterli olabilir. Kendi verinizden oluşturulan regression dataset ile modeller karşılaştırılmalıdır. Factual accuracy ve groundedness ayrı ölçülmelidir. Model seçimi popülerlik yerine gerçek iş başarısına dayanmalıdır.

GPU Gereksinimi

Cloud API kullanırken kurumun GPU sahibi olması gerekmez. Local modelde ise kabul edilebilir cevap süresi için GPU çoğu zaman önemli hâle gelir. Küçük quantized modeller CPU üzerinde çalışabilir. Eşzamanlı kullanıcı sayısı arttığında GPU belleği ve throughput sınırı daha belirgin olur. Donanım yatırımı yapmadan önce kısa proof of concept ile gerçek inference yükü ölçülmelidir.

Ölçeklenebilirlik

Cloud sağlayıcılar büyük altyapıya sahip olsa da API rate limit uygulayabilir. Local sistemde ölçek tamamen sizin GPU ve inference mimarinize bağlıdır. Birden fazla model server veya load balancing gerekebilir. Dify uygulama katmanı inference katmanından bağımsız ölçeklenebilir. Bu ayrım architecture planında baştan düşünülürse büyüme daha kolay olur.

Hibrit Model Stratejisi

Hibrit stratejide hassas veya basit görevler local modelde, daha zor görevler cloud modelde çalıştırılabilir. If/Else veya classifier node ile routing yapılabilir. Cloud fallback yalnızca local model belirli güven skorunun altında kaldığında devreye girebilir. Böylece maliyet ve veri çıkışı azaltılır. Routing kararı ölçüm ve test setiyle doğrulanmalıdır.

Dify'da Yapay Zeka Orkestrasyonu Nedir?

Dify ile LLM RAG workflow ve AI agent orkestrasyonu nasıl yapılır sorusunun temeli, işlemi tek prompt yerine kontrollü adımlara ayırmaktır. Kullanıcı girdisi önce sınıflandırılabilir, ardından bilgi tabanı, model veya tool seçilebilir. Node'lar arasında değişkenler taşınır ve koşullara göre farklı yollar izlenir. Bazı işlemler paralel veya tekrarlı yürütülebilir. Orkestrasyonun amacı daha fazla node eklemek değil işi açıklanabilir, ölçülebilir ve güvenli adımlara dönüştürmektir.

Orkestrasyon Kavramı

Orkestrasyon birden fazla bileşenin belirlenmiş sırada veya kurallarla birlikte çalıştırılmasıdır. AI uygulamasında bu bileşenler LLM, retrieval, API, code ve human approval olabilir. Her adımın girdisi ve çıktısı açıkça tanımlandığında hata noktası daha kolay bulunur. Aynı iş tekrarlandığında süreç aynı kurallarla yürütülebilir. Bu nedenle kurumsal AI projelerinde orkestrasyon modeli doğrudan model seçiminden daha önemli olabilir.

LLM'i Tek Başına Çağırmak ile Workflow Arasındaki Fark

Tek LLM çağrısında prompt ve cevap arasında sınırlı kontrol bulunur. Workflow ise girdiyi işleyip birden fazla adım üzerinden sonuç oluşturabilir. Örneğin kullanıcı türüne göre farklı bilgi tabanı ve model seçilebilir. API başarısızlığında alternatif yol çalıştırılabilir. Bu yapı deterministik iş kuralları ile probabilistic model davranışını birbirinden ayırmaya yardımcı olur.

Node Tabanlı Orkestrasyon

Dify workflow canvas üzerinde işlemler node olarak temsil edilir. Her node belirli görevi yapar ve bir sonraki node'a veri gönderir. Bu görsel yapı akışın ekip içinde anlaşılmasını kolaylaştırır. Çok büyük workflow'larda isimlendirme ve gruplama standardı gerekir. Her node'un gerçekten gerekli olup olmadığı düzenli olarak sorgulanmalıdır.

Değişken Akışı

Workflow içinde kullanıcı girdisi ve node çıktıları değişkenlerle taşınır. Bir node'un ürettiği JSON alanı sonraki LLM veya HTTP request node'unda kullanılabilir. Değişken isimlerinin anlaşılır olması bakım kolaylığı sağlar. Hassas credential değişkeni kullanıcı görünür output'a taşınmamalıdır. Debug sırasında değişken değerleri loglarda görünüyorsa veri güvenliği ayrıca değerlendirilmelidir.

Koşullu Akış

If/Else node belirli koşullara göre workflow'u farklı dallara yönlendirebilir. Kullanıcı intent'i, veri varlığı veya score threshold routing kriteri olabilir. Bu yöntem her isteği aynı pahalı modele göndermek yerine daha uygun yol seçmeyi sağlar. Koşullar anlaşılır ve test edilebilir olmalıdır. Çok fazla iç içe branch workflow bakımını zorlaştırabileceği için gerektiğinde alt workflow'lara bölmek faydalıdır.

Paralel ve Tekrarlanan İşlemler

Bazı görevler birbirinden bağımsız olduğu için paralel çalıştırılabilir. Birden fazla belgeyi aynı işlemden geçirmek iteration ile yapılabilir. Tekrarlanan işlemlerde maksimum adım sınırı önemlidir. Her tekrar LLM çağrısı içeriyorsa maliyet hızla artabilir. Paralellik kullanırken external API rate limit değerleri de hesaba katılmalıdır.

Tool Calling

Tool calling model veya workflow'un dış sistemlerde tanımlı fonksiyonları çağırmasını sağlar. CRM sorgusu, dosya okuma veya hesaplama buna örnek olabilir. Tool girdileri validate edilmelidir. Yazma ve silme yetkisi olan tool'lar ekstra approval gerektirir. Agent'a gereksiz geniş tool listesi vermek güvenlik ve karar kalitesi açısından iyi bir yaklaşım değildir.

RAG

RAG, kullanıcının sorusuyla ilgili doküman parçalarını bulup LLM context'ine ekler. Model böylece kurum bilgisinden yararlanır. Retrieval sonucu doğru değilse en güçlü model bile yanlış veya eksik cevap verebilir. Chunk, embedding ve metadata ayarları bu nedenle kritik öneme sahiptir. Workflow içinde retrieval sonucu score'a göre farklı yollara yönlendirilebilir.

Agent Orkestrasyonu

Agent orchestration sabit workflow'a göre daha esnek karar verme alanı tanır. Agent tool listesinden seçim yapabilir ve sonucu değerlendirerek yeni adım başlatabilir. Bu esneklik özellikle araştırma veya çok adımlı görevlerde faydalıdır. Buna karşılık deterministic business process için her zaman agent kullanmak gereksiz olabilir. Maximum iteration, tool permissions ve human approval güvenli agent tasarımının temelidir.

Dify Uygulama Türleri

Dify farklı uygulama tipleriyle farklı kullanım modellerini destekler. Chatbot sohbet odaklı deneyim sunarken Workflow daha deterministik işlem zincirleri için uygundur. Chatflow conversation özelliklerini workflow mantığıyla birleştirir. Agent ise tool kullanarak daha dinamik görev yürütür. Uygulama tipini seçerken “hangisi daha güçlü?” yerine “iş akışı ne kadar belirli ve ne kadar karar özgürlüğü gerekiyor?” sorusunu sormak daha doğru olur.

Chatbot

Chatbot kullanıcıyla sürekli konuşma yürütmek için uygundur. Conversation context korunabilir ve knowledge base bağlanabilir. Basit destek veya iç bilgi asistanı projelerinde hızlı başlangıç sağlar. İşlem adımları karmaşıklaştığında Chatflow veya Workflow daha uygun olabilir. Chatbot'un sistem prompt'u ve bilgi kaynakları düzenli kalite testine tabi tutulmalıdır.

Chatflow

Chatflow sohbet deneyimi ile node tabanlı akışı birleştirir. Kullanıcıyla çok turlu konuşma devam ederken farklı node'lar çalıştırılabilir. Conversation variable kullanımı bu senaryoda önemlidir. Durum bilgisi gereksiz büyürse token ve veri saklama maliyeti artabilir. Session yaşam döngüsü ve retention politikası baştan belirlenmelidir.

Workflow

Workflow giriş verisini belirli node zinciri üzerinden işleyip çıktı üretir. Arka planda belge analizi veya API servisleri için uygundur. Conversation zorunlu değildir. Deterministik business rule ve LLM çağrılarını bir arada kullanabilir. Production otomasyonunda test edilebilirlik açısından güçlü seçeneklerden biridir.

Agent

Agent belirlenen hedefe ulaşmak için araç seçme ve adım tekrar etme yeteneğine sahiptir. Kullanıcı isteğinin hangi tool ile çözüleceği önceden tam belirli değilse yararlı olabilir. Ancak tool erişimi ne kadar genişse risk o kadar artar. Kritik işlemlerde human approval kullanılmalıdır. Agent davranışı regression testlerle düzenli ölçülmelidir.

Completion

Completion tipi tek girdiden tek çıktı üretmeye odaklanır. Özetleme, sınıflandırma veya metin üretimi gibi basit görevlerde kullanılabilir. Conversation state'e ihtiyaç duymaz. API tabanlı küçük AI fonksiyonları için uygun olabilir. İhtiyaç büyüdüğünde Workflow'a geçiş değerlendirilebilir.

Hangi Uygulama Türü Ne Zaman Kullanılmalı?

Sürekli sohbet gerekiyorsa Chatbot veya Chatflow seçilebilir. Belirli adımlı arka plan işlemi gerekiyorsa Workflow daha uygundur. Tool seçimi ve esnek planlama gerekiyorsa Agent değerlendirilebilir. Tek seferlik metin dönüşümü için Completion yeterli olabilir. Ben mümkün olan en basit uygulama türüyle başlayıp gerçek ihtiyaç oluştuğunda daha esnek yapıya geçmeyi tercih ediyorum.

Dify Workflow Nedir?

Dify Workflow, kullanıcı girdisinden son çıktıya kadar geçen AI ve business işlemlerini görsel node'larla tanımlayan yapıdır. Her node belirli bir görevi gerçekleştirir ve ürettiği veri sonraki adımlarda kullanılabilir. Workflow test run özelliği production'a yayınlamadan önce davranışı görmeyi sağlar. Run logları hata ve latency analizi için önemlidir. İyi tasarlanmış workflow model davranışını iş kurallarından ayırarak daha anlaşılır bir uygulama mimarisi oluşturur.

Workflow Canvas

Workflow Canvas node'ların görsel olarak yerleştirildiği çalışma alanıdır. Bağlantılar işlemin hangi sırada ilerleyeceğini gösterir. Büyük akışlarda node adları işlevi anlatacak şekilde verilmelidir. Aynı mantığı tekrar eden bloklar mümkünse yeniden kullanılabilir yapıya taşınmalıdır. Canvas düzeni ekip review sırasında akışın daha hızlı anlaşılmasını sağlar.

Node

Node workflow içindeki tek işlem adımıdır. LLM çağrısı, HTTP request veya koşul kontrolü node olabilir. Her node belirli input alır ve output üretir. Hata yönetimi node seviyesinde düşünülmelidir. Gereksiz LLM node'larını code veya template ile değiştirmek maliyeti azaltabilir.

Edge

Edge iki node arasındaki işlem bağlantısını temsil eder. Akışın hangi node'dan nereye ilerlediğini gösterir. Koşullu branch yapılarında birden fazla edge oluşabilir. Yanlış edge bağlanması beklenmeyen workflow sonucuna yol açabilir. Test run sırasında gerçek execution path izlenmelidir.

Input ve Output

Workflow input kullanıcı veya API tarafından sağlanan başlangıç verisidir. Output ise son tüketiciye dönen sonuçtur. Input schema ne kadar açık olursa validation daha kolay olur. Output formatı başka uygulama tarafından kullanılacaksa JSON gibi deterministik yapı tercih edilebilir. Kullanıcıya gösterilen output içinde internal debug veya secret bilgisi bulunmamalıdır.

Variable

Variable node'lar arasında veri taşımayı sağlar. Metin, sayı, liste veya structured data kullanılabilir. Anlamlı variable isimleri workflow bakımını kolaylaştırır. Aynı isim farklı amaçla tekrar kullanılmamalıdır. Hassas değişkenlerin log veya final output'a taşınması engellenmelidir.

Workflow Execution

Workflow execution kullanıcı isteği veya trigger sonucunda akışın çalıştırılmasıdır. Node'lar belirlenen bağlantı ve koşullara göre yürütülür. Her çalışma benzersiz log kaydı oluşturabilir. Başarısız execution hangi node'da hata oluştuğunu görmeyi sağlar. Production KPI'larında execution success rate önemli metriktir.

Test Run

Test Run workflow'u yayınlamadan önce örnek veriyle çalıştırmanızı sağlar. Her branch için ayrı test girdisi hazırlanmalıdır. Sadece başarılı senaryoyu test etmek yeterli değildir. Hatalı JSON, boş input ve API timeout gibi durumlar da denenmelidir. Test sonuçları regression dataset oluşturmak için saklanabilir.

Workflow Run Logs

Run logs node'ların çalışması sırasında oluşan input, output ve süre bilgilerini gösterir. Hangi model çağrısının yavaş olduğunu anlamak kolaylaşır. Tool veya retrieval sonucu da analiz edilebilir. Hassas veri loglarda yer alıyorsa erişim ve retention sınırlanmalıdır. Production sorunlarında run ID üzerinden kullanıcı isteğini izlemek çok faydalıdır.

Temel Dify Workflow Node'ları

Dify workflow node'ları farklı görevleri küçük ve anlaşılır adımlara ayırır. User Input, LLM, Knowledge Retrieval, If/Else, Code, HTTP Request ve Tool sık kullanılan örneklerdir. Her işlemi LLM'e yaptırmak yerine deterministik node kullanmak daha öngörülebilir sonuç verir. Node seçimi maliyet ve güvenlik üzerinde doğrudan etkilidir. Workflow tasarlarken önce gerekli iş adımlarını yazıp ardından her adıma uygun node seçmek pratik bir yöntemdir.

User Input

User Input workflow'a dışarıdan gelen başlangıç verilerini tanımlar. Metin, dosya veya başka alanlar olabilir. Input isimleri API tüketicileri tarafından da görülebilir. Validation gereksinimi baştan belirlenmelidir. Hassas veya gereksiz veri istememek veri minimizasyonu açısından önemlidir.

LLM

LLM node model çağrısının yapıldığı temel bileşendir. Prompt, context ve model parametreleri burada tanımlanabilir. Girdi uzunluğu token maliyetini etkiler. Structured output gerekiyorsa desteklenen formatlar kullanılabilir. Aynı node için farklı modelleri test ederek kalite ve maliyet karşılaştırması yapılabilir.

Knowledge Retrieval

Knowledge Retrieval node bilgi tabanından sorguyla ilgili chunk'ları geri getirir. Top-K ve score threshold gibi ayarlar retrieval kapsamını etkiler. Fazla sonuç context'i gereksiz büyütebilir. Çok az sonuç ise önemli bilgiyi kaçırabilir. Kendi soru setinizle retrieval kalitesini test etmek gerekir.

Question Classifier

Question Classifier kullanıcı isteğini önceden tanımlı kategorilere ayırmak için kullanılır. HR, satış veya teknik destek gibi routing senaryoları oluşturulabilir. Kategoriler birbirinden açık şekilde ayrılmalıdır. Ambiguous sorular için fallback sınıfı bulunması faydalıdır. Classification accuracy gerçek kullanıcı sorularıyla ölçülmelidir.

Parameter Extractor

Parameter Extractor doğal dil içinden yapılandırılmış alanlar çıkarmayı sağlar. Tarih, müşteri numarası veya ürün adı örnek verilebilir. Çıktı sonraki API çağrısında kullanılabilir. Kritik işlemlerde çıkarılan parametre doğrudan kullanılmadan validate edilmelidir. Belirsiz değerlerde kullanıcıdan ek bilgi istemek daha güvenlidir.

If/Else

If/Else node belirli koşula göre workflow branch'i seçer. Score, kullanıcı tipi veya parametre değeri karar kriteri olabilir. Business rule burada açıkça görülebilir. Çok fazla koşul oluşursa ayrı workflow veya policy katmanı düşünülmelidir. Her branch için test verisi hazırlanmalıdır.

Code

Code node deterministik veri işleme ve hesaplama için kullanılır. JSON parse, string dönüşümü veya basit hesaplar LLM'e ihtiyaç duymadan yapılabilir. Bu hem maliyeti hem hata olasılığını azaltır. Code node'a dış sistem credential'ı gömmek güvenli değildir. Harici işlem gerekiyorsa kontrol edilen tool veya API kullanılmalıdır.

HTTP Request

HTTP Request node REST API'lere doğrudan istek göndermeyi sağlar. GET, POST ve diğer gerekli method'lar kullanılabilir. Header ve body dinamik değişkenlerden oluşturulabilir. Timeout ve non-2xx response durumları için hata yolu tasarlanmalıdır. Internal endpoint'lere erişimde SSRF ve network yetkisi riskleri değerlendirilmelidir.

Tool

Tool node önceden tanımlanmış fonksiyon veya plugin aracını çağırır. Arama, hesaplama veya şirket API'si tool olarak sunulabilir. Input parametreleri açık schema ile tanımlanmalıdır. Tool'un sahip olduğu backend yetkisi minimum tutulmalıdır. Kullanıcı girdisinin doğrudan komut veya sorguya dönüşmesi durumunda injection riskleri kontrol edilmelidir.

Template

Template node değişkenleri belirli metin veya structured output formatına dönüştürür. Basit birleştirme işlemleri için LLM kullanmaya gerek bırakmaz. JSON sonucu kullanıcı dostu metne çevirebilir. Aynı output formatı her çalışmada korunur. Bu nedenle deterministik sunum katmanında çok değerlidir.

Iteration

Iteration listedeki her öğe üzerinde aynı işlemin çalıştırılmasını sağlar. Birden fazla belge veya ürün için tekrar eden görevlerde kullanılabilir. Her öğe LLM çağrısı oluşturuyorsa toplam maliyet önceden hesaplanmalıdır. Liste boyutu için limit koymak abuse riskini azaltır. Sonuçlar aggregator veya template ile birleştirilebilir.

Loop

Loop belirli koşul sağlanana kadar işlemi tekrar çalıştırabilir. Agent benzeri iteratif kontrol akışlarında kullanılabilir. Sonsuz döngüyü önlemek için maksimum tekrar sayısı belirlenmelidir. Her turda external API çağrısı varsa rate limit izlenmelidir. Loop sonunda neden durduğu loglanmalıdır.

Variable Aggregator

Variable Aggregator farklı branch veya node çıktılarının ortak değişkende toplanmasını sağlar. Koşullu workflow sonlarında tek output yolu oluşturmayı kolaylaştırır. Veri tiplerinin uyumlu olması gerekir. Farklı branch'ler eksik alan döndürüyorsa default değer tanımlanabilir. Aggregator kullanımı büyük workflow'larda final output tasarımını sadeleştirir.

Output

Output node workflow'un dışarı döndüreceği son veriyi tanımlar. API entegrasyonunda schema mümkün olduğunca stabil tutulmalıdır. Kullanıcıya gereksiz internal metadata gönderilmemelidir. Hata durumları için ayrı status veya message alanı tasarlanabilir. Output değişiklikleri mevcut client uygulamalarını etkileyebileceği için versioning düşünülmelidir.

Dify Workflow'da Değişken Yönetimi

Değişken yönetimi workflow'un okunabilirliği ve doğruluğu üzerinde büyük etkiye sahiptir. Kullanıcı girdileri, node çıktıları ve conversation state birbirine karışırsa debugging zorlaşır. Anlamlı isim standardı kullanmak ve structured data tercih etmek bakım kolaylığı sağlar. Hassas değerler normal workflow değişkeni olarak gereksiz yere taşınmamalıdır. Büyük JSON yapılarını her node'a aktarmak yerine yalnızca gereken alanı göndermek token ve performans açısından daha verimli olabilir.

Kullanıcı Girdileri

Kullanıcı girdileri workflow'un güvenilmez dış verisi olarak değerlendirilmelidir. Uzunluk ve format kontrolü yapılmalıdır. URL, ID veya tarih gibi alanlar parse edilmeden backend işlemine gönderilmemelidir. Prompt injection içerebilecek serbest metin tool erişimiyle doğrudan birleştirilmemelidir. Input validation hem güvenlik hem workflow kalitesi sağlar.

Node Output Değişkenleri

Her node belirli output alanları üretebilir. Sonraki node yalnızca ihtiyaç duyduğu alanı referans almalıdır. Node output yapısı değişirse downstream akış etkilenebilir. Bu nedenle önemli workflow'larda output schema regression testi yapılmalıdır. Debug sırasında örnek output kaydı faydalı olur.

System Variables

System variables çalıştırma bağlamıyla ilgili hazır bilgileri sağlayabilir. Kullanıcı, conversation veya run bilgileri sürüme ve uygulama tipine göre farklı olabilir. Bu alanların anlamı dokümantasyondan doğrulanmalıdır. Hassas system variable kullanıcı output'una doğrudan aktarılmamalıdır. Access control kararında kullanılıyorsa değerin güvenilir kaynaktan geldiği doğrulanmalıdır.

Conversation Variables

Conversation variable bir sohbet boyunca belirli state bilgisini koruyabilir. Kullanıcının seçtiği departman veya tercih bilgisi buna örnek olabilir. State'in süresiz büyümesi hem depolama hem token maliyeti yaratabilir. Hassas verinin conversation state içinde tutulması veri retention gereksinimine tabidir. Oturum bitiminde hangi verinin kalacağı açıkça belirlenmelidir.

Node'lar Arasında Veri Aktarma

Node'lar arasında veri açık variable referanslarıyla taşınır. Bir node tüm önceki output'u almak zorunda değildir. Gerekli alanları seçmek workflow bağımlılığını azaltır. Tip uyuşmazlığı hataları test run sırasında yakalanabilir. API entegrasyonlarında string ve JSON ayrımı özellikle dikkat gerektirir.

JSON ve Structured Data

Structured data LLM çıktısını sonraki sistemlerin güvenilir biçimde kullanmasını kolaylaştırır. JSON schema açıkça tanımlanırsa parse hataları azalır. Ancak modelin her zaman geçerli JSON üreteceği varsayılmamalıdır. Output validation veya retry mekanizması kullanılabilir. Deterministik dönüşümler Code node ile yapılmalıdır.

Değişken İsimlendirme Standartları

`user_question`, `customer_id` veya `retrieval_score` gibi açıklayıcı isimler workflow'u anlaşılır hâle getirir. `x1` veya `temp2` gibi belirsiz isimlerden kaçınmak gerekir. Input, intermediate ve output değişkenleri için ortak convention kullanılabilir. Ekip içinde standardın dokümante edilmesi review süresini azaltır. Büyük workflow değişikliklerinde isim refactor işlemi regression testle desteklenmelidir.

If/Else ile Akıllı Workflow Routing

If/Else routing, her kullanıcı isteğini aynı işlem zincirine göndermek yerine ihtiyaca göre yol seçmenizi sağlar. Basit soru küçük modele, hassas şirket sorusu RAG akışına ve işlem talebi tool kullanan branch'e yönlendirilebilir. Bu yaklaşım maliyet ve latency kontrolü sağlar. Routing için kullanılan score veya category sonuçlarının hata yapabileceği unutulmamalıdır. Kritik kararlar yalnızca belirsiz LLM sınıflandırmasına bırakılmamalıdır.

Koşullu Akış Nedir?

Koşullu akış belirli bir ifadenin doğru veya yanlış olmasına göre farklı node zinciri çalıştırır. Karar kullanıcı rolü, parameter veya retrieval sonucu üzerinden verilebilir. Business rule açık olduğunda LLM yerine deterministik koşul tercih edilmelidir. Her branch sonunda tutarlı output üretilmesi client entegrasyonunu kolaylaştırır. Koşul sayısı büyüdükçe test kapsamı da artırılmalıdır.

Intent'e Göre Model Seçimi

Kullanıcının isteği basit sınıflandırma ile farklı model seviyelerine yönlendirilebilir. Kısa özetleme küçük modelde çalışırken zor analiz daha güçlü modele gidebilir. Intent classifier hata yaptığında fallback modeli bulunmalıdır. Routing başarısı gerçek kullanıcı verisiyle ölçülmelidir. Bu yöntem token maliyetini önemli ölçüde optimize edebilir.

Kullanıcı Türüne Göre Routing

Çalışan, müşteri ve administrator farklı bilgi kaynaklarına ihtiyaç duyabilir. Kimlik doğrulaması backend tarafından yapılmalı ve güvenilir role bilgisi workflow'a aktarılmalıdır. Kullanıcının kendi gönderdiği `role=admin` alanına güvenilmemelidir. Departman bazlı knowledge base ve tool set tanımlanabilir. Yetki kontrolü yalnızca prompt instruction seviyesinde bırakılmamalıdır.

Veri Var/Yok Kontrolü

Retrieval veya API sonucu boş olduğunda workflow farklı yola gidebilir. Veri yokken modelin uydurma cevap vermesi yerine açık bilgi eksikliği mesajı döndürmek çoğu kurumsal senaryoda daha güvenlidir. Gerekirse ikinci bilgi kaynağı denenebilir. Empty ve null değer ayrımı doğru yapılmalıdır. Bu branch test dataset içinde mutlaka bulunmalıdır.

Confidence Score'a Göre Routing

Retrieval score veya model confidence belirli threshold altında kaldığında farklı işlem yapılabilir. Düşük güvenli cevap kullanıcıya kesin bilgi gibi sunulmamalıdır. Human review veya harici arama branch'i devreye alınabilir. Threshold rastgele seçilmemelidir. Test seti üzerinde precision ve recall dengesiyle belirlenmelidir.

Hata Durumlarında Alternatif Yol

External API veya model provider geçici olarak çalışmayabilir. Workflow hata branch'i alternatif provider veya kullanıcı mesajına yönlenebilir. Sonsuz retry yapılmamalıdır. Retry sayısı ve backoff değeri açık olmalıdır. Failure rate monitoring bu fallback mekanizmasının ne sıklıkla çalıştığını gösterir.

Iteration ve Loop Nasıl Kullanılır?

Iteration ve Loop tekrar eden işlemleri workflow içinde yönetmeye yarar. Liste üzerindeki her öğeye aynı işlem uygulanabilir veya belirli koşul sağlanana kadar adımlar tekrarlanabilir. Bu özellikler güçlüdür, fakat kontrolsüz kullanılırsa çok sayıda LLM ve API çağrısı üretebilir. Maksimum öğe ve maksimum iterasyon sınırı mutlaka düşünülmelidir. Production maliyet alarmı özellikle kullanıcı tarafından belirlenen uzun listelerde önemlidir.

Iteration Nedir?

Iteration bir liste içindeki her öğeyi aynı alt akıştan geçirir. Örneğin on dokümanın her biri ayrı ayrı özetlenebilir. Her iterasyonun output'u sonradan birleştirilebilir. Liste boyutu yüzlerce öğeye çıktığında worker ve model rate limitleri etkilenebilir. Input boyutu için sınır koymak güvenli yaklaşım sağlar.

Loop Nedir?

Loop koşul sağlanana veya maksimum tekrar sayısına ulaşılana kadar aynı akışı çalıştırır. Modelin önce taslak üretip sonra kontrol etmesi gibi senaryolarda kullanılabilir. Her tur sonuç kalitesini garanti etmez. Maliyet ve latency her tekrar ile artar. Kesin maximum iteration kullanmak production güvenliği için gereklidir.

Liste Üzerinde İşlem Yapmak

Kullanıcıdan veya API'den gelen ürün listesi iteration ile işlenebilir. Her öğe için ayrı LLM veya code işlemi yapılabilir. Başarısız tek öğenin tüm işi bozup bozmayacağı önceden belirlenmelidir. Partial result yaklaşımı bazı süreçlerde daha kullanışlıdır. Liste büyüklüğü log ve maliyet raporuna dahil edilmelidir.

Birden Fazla Belgeyi İşlemek

Birden fazla belge önce text extraction, ardından özetlama veya metadata çıkarma adımlarından geçirilebilir. Büyük belge koleksiyonlarında işlemi background queue üzerinden yürütmek daha sağlıklıdır. Her belge için durum bilgisi tutulabilir. Hatalı dosya diğer belgelerin işlenmesini engellememelidir. Duplicate dosya kontrolü gereksiz embedding maliyetini azaltır.

Çoklu İçerik Üretimi

Farklı ürün veya başlıklar için çoklu içerik oluşturma iteration kullanımına örnektir. Her öğeye aynı template ve model uygulanabilir. Kullanıcı tek istekte binlerce üretim başlatamamalıdır. Rate limit ve quota kullanılmalıdır. Çıktılar yayınlanmadan önce kalite ve güvenlik kontrolü yapılmalıdır.

Agent Benzeri Tekrarlı Akışlar

Loop kullanılarak agent benzeri “deneme, kontrol, düzeltme” döngüsü kurulabilir. Bu yapı karar adımlarını sabit tutmak istediğinizde agent'tan daha kontrol edilebilir olabilir. Her turda önceki output input olarak kullanılabilir. Stop condition açıkça tanımlanmalıdır. Son tur başarısız olsa bile workflow güvenli fallback sonucu döndürmelidir.

Sonsuz Döngüyü Önlemek

Her Loop mutlaka maksimum iteration sınırına sahip olmalıdır. Stop condition LLM tarafından üretilen belirsiz metne tamamen bağlı olmamalıdır. Timeout ve maliyet limiti ek güvenlik sağlar. Loop sayısı run loglarında izlenebilir. Normalden yüksek iteration security veya kalite problemi sinyali olabilir.

Template Node ile Deterministik Çıktı Üretmek

Her metin birleştirme işi için LLM çağırmak gereksiz maliyet oluşturur. Template node değişkenleri sabit formatta bir araya getirerek daha öngörülebilir çıktı üretir. API sonuçlarını kullanıcıya sunmak veya JSON alanlarını rapora dönüştürmek için idealdir. Çıktı aynı girdide aynı yapıyı korur. Ben mümkün olan her deterministik formatting işinde önce template kullanmayı, yalnızca doğal dil üretimi gerekiyorsa LLM'e geçmeyi tercih ediyorum.

Template Node Nedir?

Template node değişkenleri şablon içine yerleştirerek yeni metin üretir. Başlık, liste ve API response alanları bu şekilde birleştirilebilir. Model çağrısı olmadığı için token maliyeti oluşmaz. Çıktı formatı test edilebilir. User-generated değerler HTML içine yerleştiriliyorsa uygun escaping ihtiyacı değerlendirilmelidir.

Jinja2 Kullanımı

Dify'ın desteklediği template yapısında Jinja2 benzeri syntax kullanılabilir. Değişken, condition ve loop işlemleri yapılabilir. Çok fazla iş mantığını template içine taşımak okunabilirliği azaltabilir. Karmaşık hesaplama için Code node daha uygundur. Template test input'larıyla doğrulanmalıdır.

LLM Yerine Template Kullanılması Gereken Durumlar

Sabit e-posta iskeleti veya API response formatı için LLM kullanmak gereksizdir. Veriler zaten doğru ve yalnızca birleştirilecekse template daha güvenilir sonuç verir. Modelin alan atlama veya format değiştirme riski ortadan kalkar. Latency düşer. Token maliyeti de sıfıra yaklaşır.

JSON'u Metne Dönüştürme

API'den gelen structured JSON kullanıcı dostu metne dönüştürülebilir. Belirli alanlar seçilip liste hâline getirilebilir. Eksik alanlar için default değer gösterilebilir. Tüm raw JSON'u LLM'e gönderme ihtiyacı azalır. Hassas alanlar template'e hiç eklenmemelidir.

Çoklu Sonuçları Birleştirme

Iteration çıktıları template ile tek raporda birleştirilebilir. Her öğe aynı formatla gösterilebilir. Sıralama gerekiyorsa önce Code node kullanılabilir. Çok büyük liste kullanıcı arayüzünü zorlayabileceği için limit belirlenebilir. Sonuç API tarafından tüketilecekse JSON formatı metinden daha uygun olabilir.

Token Maliyetini Azaltma

Deterministik formatting görevlerini template'e taşımak gereksiz model çağrılarını azaltır. Ayrıca LLM'e gönderilen context sadece gerçekten yorumlanması gereken verilerle sınırlandırılabilir. Daha kısa prompt hem maliyeti hem latency'yi azaltır. Workflow observability üzerinden hangi node'un token tükettiği izlenebilir. En pahalı node her zaman en fazla değer sağlayan node olmayabilir.

Code Node Nasıl Kullanılır?

Code node küçük deterministik işlemleri workflow içinde çalıştırmak için kullanışlıdır. Veri dönüştürme, JSON parse ve hesaplama gibi işler modele bırakılmadan çözülebilir. Kod mümkün olduğunca kısa ve görev odaklı tutulmalıdır. Dış sisteme erişim veya yüksek yetki gereken işlemler doğrudan code node yerine kontrollü tool üzerinden yapılmalıdır. Güvenlik açısından kullanıcı girdisinin kod veya shell komutuna dönüşmesine kesinlikle izin verilmemelidir.

Code Node'un Kullanım Alanları

Code node liste filtreleme, string normalization ve veri yapısı dönüştürme için uygundur. Küçük business logic adımları da uygulanabilir. Ağır CPU işlemleri için tasarlanmış runtime olarak görülmemelidir. Çok uzun kod bakım ve test sorununa yol açar. Büyük iş mantığını ayrı servis veya repository içinde yönetmek daha doğru olabilir.

Veri Dönüştürme

API'den gelen alan adları workflow'un istediği formata dönüştürülebilir. Tarih, sayı veya liste formatı normalize edilebilir. Bu işlem LLM'e yaptırıldığında gereksiz hata ihtimali oluşur. Code node aynı girdiye aynı sonucu üretir. Tip validation eklemek downstream hataları azaltır.

JSON Parse Etme

String olarak gelen JSON uygun hata kontrolüyle parse edilebilir. Invalid JSON durumunda workflow alternatif branch'e yönlendirilebilir. Kullanıcının gönderdiği büyük JSON için boyut limiti uygulanmalıdır. Güvenilmeyen alanlar backend sorgularında doğrudan kullanılmamalıdır. Parse sonucu yalnızca gereken alanlara indirgenebilir.

Hesaplama

Matematiksel hesaplar LLM yerine kodla yapılmalıdır. Vergi, oran veya toplam gibi işlemler deterministik araç gerektirir. Floating point ve para hesaplarında uygun veri tipi seçilmelidir. Sonuç gerekiyorsa ayrıca açıklama için LLM'e verilebilir. Hesabı modelin yapmasına güvenmek gereksiz risk oluşturur.

LLM Gerektirmeyen Deterministik İşlemler

Tarih formatlama, ID oluşturma ve veri filtreleme gibi işler model çağrısı gerektirmez. Bu adımları code veya template node'a taşımak maliyeti düşürür. Model yalnızca doğal dil anlama veya üretim gereken yerde kullanılmalıdır. Workflow review sırasında her LLM node için “bu işi kodla yapabilir miyiz?” sorusu faydalıdır. Basitlik uzun vadeli bakım kalitesini artırır.

Code Node Güvenliği

Code node'un execution ortamı ve izinleri kullanılan Dify sürümüne göre anlaşılmalıdır. Kullanıcı girdisini eval veya shell benzeri şekilde çalıştırmak ciddi risk oluşturur. Secret değerleri code içine sabit yazılmamalıdır. Dosya veya network erişimi varsa minimum yetki uygulanmalıdır. Plugin ve runtime güvenlik güncellemeleri düzenli takip edilmelidir.

Harici İşlemler İçin Tool Kullanmak

CRM kaydı oluşturmak gibi dış işlem gerektiğinde kontrollü API tool daha iyi sınır sağlar. Tool schema hangi parametrelerin kabul edildiğini tanımlar. Backend credential kullanıcıya veya modele açıklanmaz. Yazma işlemlerinde approval katmanı eklenebilir. Böylece code node ile kontrolsüz network erişimi vermek yerine açık yetkili servis kullanılır.

HTTP Request ile Dify'ı Şirket Sistemlerine Bağlamak

HTTP Request node Dify'ı mevcut CRM, ERP ve mikroservislerle bağlamanın en doğrudan yollarından biridir. REST API üzerinden veri alınabilir veya kontrollü işlem başlatılabilir. Authentication header ve request body güvenli şekilde oluşturulmalıdır. Internal API'lere erişim verildiğinde Dify sunucusunun network yetkisi dikkatle sınırlandırılmalıdır. Özellikle kullanıcı tarafından sağlanan URL'leri doğrudan çağırmak SSRF riskine yol açabileceği için endpoint'ler mümkün olduğunca sabit veya allowlist olmalıdır.

REST API Çağırmak

Dify HTTP node bir REST endpoint'e istek gönderebilir. URL, header ve body workflow değişkenlerinden oluşturulabilir. API response sonraki node'da parse edilebilir. Status code kontrolü mutlaka yapılmalıdır. 200 dönen her response'un business açısından başarılı olduğu da ayrıca doğrulanmalıdır.

GET ve POST İstekleri

GET veri okumak, POST ise veri göndermek veya işlem başlatmak için sık kullanılır. Method seçimi API sözleşmesine göre yapılmalıdır. GET query parametrelerinde hassas veri taşımak loglarda görünürlük oluşturabilir. POST body JSON formatında açık schema ile hazırlanabilir. Idempotency gereken işlemlerde API desteği varsa idempotency key kullanılmalıdır.

Authentication Header

Bearer token veya API key çoğunlukla header içinde gönderilir. Credential workflow metnine düz olarak yazılmamalıdır. Secret store veya güvenli tool configuration kullanılabilir. Token süresi dolduğunda refresh mekanizması gerekiyorsa ayrı servis tercih edilebilir. Header değerleri loglarda maskelenmelidir.

JSON Body Oluşturmak

POST request body structured data olarak hazırlanmalıdır. Kullanıcı girdisi doğrudan raw JSON string içine eklenmeden önce validation yapılmalıdır. Zorunlu alanlar kontrol edilmelidir. Backend API beklenmeyen alanları reddetmelidir. Debug sırasında gerçek müşteri verisi loglara yazılmamalıdır.

CRM Entegrasyonu

Dify CRM üzerinden müşteri veya fırsat bilgisi okuyabilir. Salt okunur endpoint ile başlamak daha güvenlidir. Kayıt güncelleme gerekiyorsa user confirmation veya human approval eklenebilir. CRM token'ı yalnızca gerekli scope'lara sahip olmalıdır. Her tool çağrısı audit log içinde kullanıcı ve workflow run ile ilişkilendirilebilir.

ERP Entegrasyonu

ERP sistemleri finans ve stok gibi kritik iş süreçleri içerir. Dify'a doğrudan geniş ERP write yetkisi vermek doğru değildir. İlk entegrasyon read-only rapor veya ürün sorgusu gibi sınırlı API'lerle yapılabilir. Sipariş veya ödeme işlemleri için insan onayı zorunlu tutulabilir. Backend ayrıca kendi authorization kontrolünü uygulamalıdır.

Webhook Kullanımı

Webhook başka bir sistemin olay olduğunda Dify workflow'u tetiklemesini sağlar. Endpoint authentication veya signed request ile korunmalıdır. Replay attack riskine karşı timestamp veya nonce kullanılabilir. Gelen payload schema doğrulanmalıdır. Webhook failure durumunda kaynak sistemde retry politikası bulunmalıdır.

Timeout ve Hata Yönetimi

External API her zaman hızlı ve erişilebilir olmayabilir. HTTP node için makul timeout belirlenmelidir. Geçici hata durumunda sınırlı retry uygulanabilir. Permanent 4xx hatalarda tekrar denemek gereksizdir. Kullanıcıya backend hata detayını olduğu gibi göstermek yerine güvenli ve anlaşılır mesaj döndürülmelidir.

Dify Tools Nedir?

Dify Tools modellerin ve workflow'ların harici yeteneklere erişmesini sağlayan bileşenlerdir. Bir tool arama yapabilir, API çağırabilir veya belirli şirket işlemini gerçekleştirebilir. Tool'ların gücü kadar sahip oldukları backend yetkisi de önemlidir. Agent'ın hangi tool'u seçebileceği ve hangi parametreleri gönderebileceği açık schema ile sınırlandırılmalıdır. Production tasarımında tool access bir kullanıcıya verilen API yetkisi kadar ciddi ele alınmalıdır.

Tool Calling Nedir?

Tool calling modelin belirli bir fonksiyonun gerekli olduğuna karar verip yapılandırılmış parametrelerle çağrı yapmasıdır. Model doğrudan backend credential görmemelidir. Tool arayüzü sadece gereken parametreleri kabul etmelidir. Sonuç modele context olarak geri verilebilir. Kritik side-effect oluşturan tool çağrısı insan onayı gerektirebilir.

Built-in Tools

Dify platform içinde hazır araçlar sunabilir. Kullanılabilir tool listesi sürüme ve plugin ekosistemine göre değişir. Hazır olması otomatik olarak kurum açısından güvenilir olduğu anlamına gelmez. Tool hangi dış servise veri gönderiyor kontrol edilmelidir. Kullanılmayan araçlar agent'a verilmemelidir.

Plugin Tools

Plugin tool Dify plugin sistemi üzerinden eklenen işlevdir. Marketplace veya özel paket kaynağından kurulabilir. Plugin code çalıştırdığı için kaynağı ve sürümü önemlidir. Production'da yalnızca güvenilir ve review edilmiş plugin kullanılmalıdır. Güncelleme sırasında permission veya behavior değişikliği kontrol edilmelidir.

Custom API Tools

Şirket içi API'ler custom tool olarak modele sunulabilir. API gateway araya konularak authentication ve rate limit merkezi yönetilebilir. Tool schema yalnızca gerekli operasyonları içermelidir. Salt okunur ve yazma işlemleri ayrı tool olarak tasarlanabilir. Böylece agent'a verilen yetki daha açık ve denetlenebilir olur.

Workflow as a Tool

Bir workflow başka bir agent veya workflow tarafından tool olarak kullanılabilir. Bu yaklaşım büyük sistemi küçük ve tekrar kullanılabilir işlevlere böler. Alt workflow kendi validation ve error handling kurallarına sahip olabilir. Versiyon değişikliği üst workflow'ları etkileyebileceği için contract korunmalıdır. Tool adı ve açıklaması modelin doğru seçim yapmasını kolaylaştırmalıdır.

Agent'ın Tool Seçmesi

Agent tool açıklamalarına ve kullanıcı isteğine göre uygun aracı seçmeye çalışır. Açıklamalar belirsizse yanlış tool seçimi artabilir. Benzer iş yapan araçlar açık ayrımlarla tanımlanmalıdır. Kritik işlemlerde seçimden sonra confirmation adımı eklenebilir. Tool success rate agent kalitesi için izlenmesi gereken metriktir.

Tool Output'unu Workflow'da Kullanmak

Tool sonucu structured data olarak sonraki node'a aktarılabilir. Output doğrudan kullanıcıya gösterilmeden önce validation yapılabilir. API hata mesajları LLM'e gereksiz hassas bilgi taşımamalıdır. Büyük response içinden yalnızca gereken alanlar seçilebilir. Bu yaklaşım token maliyetini ve veri sızıntısı riskini azaltır.

Dify Plugin Sistemi

Dify plugin sistemi platformun model, tool, agent strategy ve datasource gibi alanlarda genişletilmesini sağlar. Plugin geliştirme ekosistemi şirket özel entegrasyonları için büyük esneklik sunar. Bunun karşılığında plugin kodu uygulama güvenlik alanının parçası hâline gelir. Kurulan her plugin için kaynak, sürüm ve ihtiyaç gerekçesi tutulmalıdır. Production ortamında plugin approval süreci oluşturmak faydalıdır.

Tool Plugin

Tool plugin modele veya workflow'a yeni işlem yeteneği ekler. Harici API çağrısı veya özel iş fonksiyonu sunabilir. Credential'ın plugin configuration içinde güvenli saklanması gerekir. Tool schema açık ve minimum kapsamlı olmalıdır. Yazma işlemleri audit ve approval ile desteklenmelidir.

Model Plugin

Model plugin yeni model sağlayıcısını Dify'a bağlar. Chat, embedding veya başka model türleri sunabilir. Provider authentication ve endpoint behavior doğru implement edilmelidir. Plugin güncellemesi model response formatını değiştirebilir. Production geçişinden önce staging testleri yapılmalıdır.

Agent Strategy Plugin

Agent strategy plugin agent'ın tool seçme ve adım planlama biçimini genişletebilir. Farklı model ve görevlerde farklı stratejiler daha iyi sonuç verebilir. Ancak daha fazla özerklik daha fazla risk anlamına gelebilir. Iteration ve tool scope limitleri korunmalıdır. Strategy başarısı task success rate ile ölçülmelidir.

Extension Plugin

Extension plugin platforma belirli ek yetenekler sağlayabilir. Kullanım alanı Dify sürümündeki plugin mimarisine göre değişebilir. Kurulum öncesi resmi dokümantasyon ve permission ihtiyacı okunmalıdır. Eklentinin dış network erişimi olup olmadığı kontrol edilmelidir. Gereksiz extension production attack surface'ini büyütebilir.

Datasource Plugin

Datasource plugin harici bilgi kaynağını Dify knowledge pipeline içine bağlayabilir. Kurumsal wiki, dosya deposu veya başka içerik platformları örnek olabilir. Kaynaktan çekilen belgelerde erişim yetkisi korunmalıdır. Tüm şirket içeriğini tek global knowledge base'e aktarmak her zaman doğru değildir. Incremental sync ve deletion behavior test edilmelidir.

Trigger Plugin

Trigger plugin bir olay oluştuğunda workflow başlatmayı sağlar. E-posta, webhook veya başka sistem event'i giriş noktası olabilir. Trigger authentication ve payload validation gerektirir. Duplicate event durumunda aynı işlemin iki kez yapılması önlenmelidir. Trigger logları workflow run ID ile ilişkilendirilmelidir.

Plugin Marketplace

Plugin Marketplace farklı geliştiriciler tarafından sunulan eklentilere erişim sağlar. Marketplace'te bulunmak tek başına kurum güvenlik onayı anlamına gelmez. Kaynak, maintainer ve permission ihtiyacı incelenmelidir. Production için allowlist yaklaşımı kullanılabilir. Kullanılmayan plugin'ler kaldırılmalıdır.

Private Plugin Geliştirme

Şirket kendi API ve model servisleri için private plugin geliştirebilir. Kod internal Git repository'de version control altında tutulmalıdır. CI içinde security scanning ve test uygulanabilir. Plugin credential'ları code içine gömülmemelidir. Release süreci Dify sürüm uyumluluğunu da kontrol etmelidir.

Event-Driven Dify Workflow Oluşturma

Event-driven workflow kullanıcının manuel başlatmasını beklemeden belirli olay gerçekleştiğinde çalışır. Yeni e-posta, dosya veya CRM event'i tetikleyici olabilir. Bu yapı Dify'ı pasif chatbot'tan aktif iş süreci bileşenine dönüştürür. Event kaynağı güvenilir şekilde authenticate edilmelidir. Duplicate event, retry ve idempotency kontrolü tasarımın önemli parçalarıdır.

Trigger Nedir?

Trigger workflow'u başlatan olay veya sinyaldir. Webhook, schedule veya plugin event'i olabilir. Trigger input'u workflow değişkenlerine dönüştürülür. Güvenilmeyen event verisi validate edilmelidir. Her trigger run için source ve event ID loglanmalıdır.

Webhook Trigger

Webhook trigger HTTP request geldiğinde workflow başlatır. Endpoint secret veya signature ile korunabilir. Payload schema ve body size sınırı uygulanmalıdır. Retry edilen aynı event'in tekrar işlem üretmemesi için idempotency tasarlanmalıdır. Public webhook endpoint rate limiting ile korunabilir.

E-posta Geldiğinde Workflow Başlatmak

E-posta integration belirli mailbox'a yeni ileti geldiğinde workflow çalıştırabilir. Mesaj içeriği sınıflandırılabilir veya taslak yanıt üretilebilir. E-posta içeriği indirect prompt injection taşıyabileceği için agent tool erişimiyle doğrudan birleştirilmemelidir. Attachment'lar malware ve file type kontrolünden geçmelidir. Otomatik gönderim yerine kritik e-postalarda insan onayı tercih edilebilir.

Yeni Dosya Geldiğinde Workflow Başlatmak

Dosya deposuna yeni belge geldiğinde ingestion workflow başlatılabilir. Dosya tipi ve boyutu kontrol edilmelidir. Text extraction ve metadata işlemi sonrasında knowledge base güncellenebilir. Duplicate belge hash ile tespit edilebilir. Silinen veya güncellenen dosyaların vector index içindeki karşılığı da yönetilmelidir.

CRM Event'i ile Workflow Başlatmak

Yeni müşteri kaydı veya fırsat değişikliği Dify workflow'u tetikleyebilir. Workflow ilgili kaydı özetleyebilir veya satış ekibine öneri hazırlayabilir. CRM event credential'ı ve source doğrulanmalıdır. Otomatik müşteri iletişimi gerekiyorsa approval policy belirlenmelidir. Event ID loglanarak sonuç CRM kaydıyla ilişkilendirilebilir.

Zamanlanmış İşler

Belirli saatte çalışan workflow günlük rapor veya indeks yenileme için kullanılabilir. Scheduler timezone'u açıkça bilinmelidir. Aynı iş önceki tur bitmeden tekrar başlamamalıdır. Uzun süren job'lar için lock veya concurrency kontrolü gerekebilir. Başarısız schedule run alarm üretmelidir.

Trigger Verisini Workflow Input'una Dönüştürmek

Event payload çoğu zaman workflow'un doğrudan kullanabileceği temiz formatta değildir. Code veya mapping adımıyla gerekli alanlar seçilebilir. Zorunlu değerler yoksa workflow erken ve kontrollü biçimde durmalıdır. Untrusted field'lar tool parametresi olmadan önce validate edilmelidir. Bu normalize katmanı farklı event kaynaklarını ortak workflow'a bağlamayı kolaylaştırır.

Dify'da AI Agent Nasıl Oluşturulur?

Dify agent oluştururken ilk adım modele sınırsız yetki vermek değil, hedefi ve gerekli araçları açıkça tanımlamaktır. Agent instruction hangi görevin yapılacağını ve hangi sınırların olduğunu anlatır. Tool listesi minimum tutulmalıdır. ReAct veya function calling gibi stratejilerin desteği kullanılan modele göre değişebilir. Agent'ın başarısı sadece final cevaba değil doğru tool seçimi, iterasyon sayısı ve güvenli davranışa göre değerlendirilmelidir.

Agent Nedir?

Agent bir hedefe ulaşmak için modeli ve araçları tekrar eden adımlarla kullanan uygulama yapısıdır. Sabit workflow'dan daha esnek karar verebilir. Model bir tool sonucuna göre yeni tool çağrısı yapabilir. Bu esneklik beklenmeyen yollara da izin verebilir. Bu nedenle agent üretimde sınırlandırılmış yetki ve izleme ile kullanılmalıdır.

Workflow ile Agent Arasındaki Fark

Workflow adımları önceden büyük ölçüde belirlenir. Agent ise hangi adımın sırada geleceğine model kararıyla yaklaşabilir. Finansal veya hukuki işlem gibi kontrollü süreçlerde workflow daha uygun olabilir. Araştırma veya çeşitli araçlardan bilgi toplama görevinde agent avantaj sağlayabilir. Hibrit mimaride workflow içinde sınırlı agent node kullanmak da mümkündür.

Agent Strategy

Agent strategy modelin düşünme ve tool kullanma düzenini belirler. Function calling destekleyen modeller structured tool seçimi yapabilir. Farklı stratejiler aynı görevde farklı başarı oranı gösterebilir. Model provider ve tool schema uyumluluğu test edilmelidir. Strategy değişikliği production behavior değişikliği olarak ele alınmalıdır.

Tool Seçimi

Agent'a yalnızca görevi için gerekli tool'lar verilmelidir. Benzer araçların açıklamaları açıkça ayrılmalıdır. Tool adı kullanıcıya doğrudan görünmese bile model seçimini etkiler. Kritik write tool'ları farklı agent veya approval katmanında tutulabilir. Tool usage oranı gözlemlenerek kullanılmayan yetkiler kaldırılmalıdır.

Function Calling

Function calling modelin tool adını ve parametrelerini structured biçimde seçmesini sağlar. Schema doğru tanımlanırsa parse hataları azalır. Model tarafından gönderilen parametre yine backend tarafında validate edilmelidir. Function calling authorization kontrolünün yerini tutmaz. Kullanıcıya kapalı bir işlem tool üzerinden erişilebiliyorsa backend ayrıca kimlik kontrolü yapmalıdır.

ReAct

ReAct yaklaşımı modelin gözlem ve tool sonuçlarına göre tekrar karar vermesine dayanır. Çok adımlı görevlerde faydalı olabilir. Her adım model çağrısı oluşturabileceği için maliyet artar. Maksimum iterasyon sınırı kullanmak gerekir. Reasoning veya internal prompt bilgilerinin kullanıcıya gereksiz şekilde gösterilmemesine dikkat edilmelidir.

Agent Instruction

Agent instruction görevin kapsamını ve davranış sınırlarını açıklar. “Her şeyi yap” gibi geniş talimat yerine izinli görevler belirtilmelidir. Tool kullanmadan cevap verilebilecek durumlar da tanımlanabilir. Prompt injection'ın instruction'ı değiştiremeyeceği varsayılmamalıdır. Kritik güvenlik kontrolleri prompt dışında sistem ve tool katmanında uygulanmalıdır.

Maksimum Iterasyon

Maximum iteration agent'ın sonsuz tool döngüsüne girmesini önler. Görev türüne göre makul düşük sınır seçilmelidir. Sürekli limite çarpan agent tasarım veya tool problemi gösterir. Her ekstra tur token ve API maliyeti oluşturur. Monitoring dashboard iterasyon dağılımını gösterebilir.

Agent Output

Agent output kullanıcıya veya başka sisteme gönderilecek final sonuçtur. Structured output gerekiyorsa schema kullanılabilir. Tool kaynaklarından gelen hassas alanlar final cevaptan çıkarılmalıdır. Agent kaynak veriye dayanmıyorsa belirsizlik açıkça belirtilmelidir. Output validation production integration için önemlidir.

Agent'ın Hata Yapabileceği Durumlar

Agent yanlış tool seçebilir veya doğru tool'a yanlış parametre gönderebilir. Tool output'unu yanlış yorumlayabilir. Prompt injection nedeniyle kullanıcı isteğinden sapabilir. Uzun görevde gereksiz tekrar yaparak maliyeti artırabilir. Bu riskler test dataset, permission sınırı ve human approval ile azaltılmalıdır.

Dify Agent Güvenliği

Agent güvenliği yalnızca prompt içine “güvenli davran” yazmakla sağlanmaz. Gerçek koruma tool permission, network erişimi, credential isolation ve human approval katmanlarında uygulanır. Agent'ın okuma ve yazma yetkileri ayrı değerlendirilmelidir. Prompt injection ve SSRF gibi riskler özellikle harici içerik işleyen agent'larda önemlidir. Her agent için maksimum iterasyon ve maliyet sınırı tanımlamak kötü veya hatalı davranışın etkisini azaltır.

Least Privilege

Agent yalnızca görevi için gerekli tool ve data kaynaklarına erişmelidir. Müşteri destek agent'ına database admin yetkisi verilmemelidir. Role veya application bazlı ayrı credential kullanılabilir. Kullanılmayan tool yetkileri kaldırılmalıdır. Least privilege düzenli access review ile korunmalıdır.

Salt Okuma Araçları

Başlangıç agent projelerinde read-only tool kullanmak risk seviyesini düşürür. Veri okuyabilir, fakat sistem durumunu değiştiremez. Bununla birlikte hassas veri okuma da authorization gerektirir. Agent response üzerinden veri sızıntısı oluşmaması için erişim scope'u sınırlanmalıdır. Read-only olması otomatik olarak güvenli olduğu anlamına gelmez.

Yazma Yetkisi Olan Araçlar

Kayıt oluşturma, silme veya ödeme başlatma gibi tool'lar yüksek risklidir. Parametre validation backend tarafından yapılmalıdır. User identity ve role kontrolü tool tarafında tekrar doğrulanmalıdır. Kritik işlemler approval beklemelidir. Audit log kim, ne zaman ve hangi agent run üzerinden işlem yaptığını göstermelidir.

Kritik İşlemlerde İnsan Onayı

Human approval agent kararını gerçek işlem öncesinde kullanıcı veya görevli kişiye gösterir. Ödeme, sözleşme veya müşteri kaydı silme gibi işlemler için uygundur. Onay ekranı tool parametrelerini açıkça göstermelidir. Kullanıcı “onayla” dediğinde hangi işlemi onayladığı belirsiz olmamalıdır. Approval logu audit için saklanmalıdır.

Prompt Injection

Prompt injection kullanıcı girdisinin agent instruction'ını manipüle etmeye çalışmasıdır. Sistem prompt'u bunu tamamen engelleyemez. Tool permission ve backend authorization en önemli savunmadır. Kullanıcı metni ile trusted instruction farklı bağlamlarda tutulmalıdır. Şüpheli input güvenlik test setinde düzenli denenmelidir.

Indirect Prompt Injection

Indirect prompt injection agent'ın okuduğu web sayfası, belge veya e-posta içinde kötü yönlendirme bulunmasıdır. Agent bu metni kullanıcı talimatı gibi yorumlayabilir. Harici içerik hiçbir zaman trusted system instruction kabul edilmemelidir. Tool çağrıları için policy katmanı uygulanmalıdır. Özellikle e-posta ve web scraping agent'ları bu risk açısından test edilmelidir.

Tool Abuse

Tool abuse agent'ın sahip olduğu meşru aracı istenmeyen amaçla kullanmasıdır. Fazla geniş arama, veri export veya tekrar eden mesaj gönderimi örnek olabilir. Rate limit ve scope kısıtlaması uygulanmalıdır. Tool backend'inde authorization bulunmalıdır. Anormal kullanım SIEM veya application monitoring üzerinden alarm üretebilir.

SSRF Riski

SSRF kullanıcı kontrollü URL üzerinden Dify sunucusunun internal network kaynaklarına istek göndermesine yol açabilir. HTTP tool'un serbest URL kabul etmesi bu riski artırır. Endpoint allowlist ve network egress filtering kullanılabilir. Metadata service gibi hassas internal adresler engellenmelidir. SSRF koruması uygulama ve network katmanında birlikte ele alınmalıdır.

Hassas Credential'ları Agent'tan Gizlemek

Agent'ın API token veya database password metnini bilmesi gerekmez. Credential tool backend'inde saklanmalıdır. Model yalnızca tool schema ve gerekli parametreleri görmelidir. Tool response içine credential yanlışlıkla eklenmemelidir. Log masking de ek koruma sağlar.

Agent Iterasyon Limiti

Agent iteration limiti runaway execution riskini azaltır. Göreve göre üç, beş veya başka makul sınır belirlenebilir. Limite sık ulaşılıyorsa tool tasarımı veya instruction iyileştirilmelidir. Kullanıcıdan ek bilgi istemek sonsuz denemeden daha doğru olabilir. Limit olayı monitoring metric olarak kaydedilebilir.

Maliyet Limiti

Agent tek istekte çok sayıda model ve tool çağrısı yapabilir. Kullanıcı, uygulama veya günlük bütçe limiti uygulanabilir. Cloud provider spending alert ek savunma sağlar. Çok pahalı workflow production'a çıkmadan test edilmelidir. Maliyet bilgisi kalite metrikleriyle birlikte izlenmelidir.

MCP ile Dify Orkestrasyonu

Model Context Protocol, model uygulamaları ile harici araç ve veri kaynakları arasında ortak bağlantı yaklaşımı sunmayı hedefler. Dify ekosisteminde MCP destekli entegrasyonlar kullanılabilir, ancak özelliklerin tam kapsamı sürüme göre değişebileceği için güncel dokümantasyon kontrol edilmelidir. MCP araçları şirket içi servisleri modele daha standart şekilde sunabilir. Bununla birlikte güvenilmeyen MCP server kullanmak geniş tool ve veri erişimi riski oluşturur. Her MCP bağlantısı normal API entegrasyonu kadar güvenlik review sürecinden geçmelidir.

Model Context Protocol Nedir?

MCP model uygulamasının araç ve context sağlayıcılarıyla standart biçimde iletişim kurmasına yardımcı olan protokol yaklaşımıdır. Farklı uygulamalar aynı server tarafından sunulan araçları kullanabilir. Bu standardizasyon entegrasyon kodunu azaltabilir. Ancak protokol standardı authorization politikasını sizin yerinize belirlemez. Hangi araçların hangi kullanıcıya sunulacağı ayrıca tasarlanmalıdır.

MCP Server Nedir?

MCP Server model uygulamasına belirli tool veya kaynakları sunan servis olarak düşünülebilir. Şirket içi API'ler bu katmanın arkasında temsil edilebilir. Server hangi credential ile backend'e erişiyorsa o yetkinin kapsamı önemlidir. Public internete gereksiz açılmamalıdır. Loglama ve rate limiting uygulanmalıdır.

Dify ile MCP Araçlarını Kullanmak

Dify'ın desteklediği MCP entegrasyonu üzerinden server araçları workflow veya agent'a bağlanabilir. Tool schema ve açıklama agent seçim kalitesini etkiler. Connection bilgileri güvenli saklanmalıdır. Production'da server sürümü ve kullanılan tool listesi kayıt altına alınmalıdır. Yeni tool eklendiğinde agent'ın davranış testleri tekrar çalıştırılmalıdır.

Şirket İçi Sistemleri MCP ile Açmak

CRM, doküman veya ticket sistemi MCP server üzerinden sınırlı araçlar şeklinde sunulabilir. Backend'in tamamını expose etmek yerine belirli iş fonksiyonları tanımlanmalıdır. Read ve write işlemleri ayrı tutulmalıdır. User authorization server tarafında uygulanmalıdır. Agent yalnızca kullanıcının zaten sahip olduğu erişim çerçevesinde işlem yapmalıdır.

MCP mi Custom API Tool mu?

Tek bir basit REST endpoint için custom API tool yeterli olabilir. Birden fazla agent ve uygulamanın ortak araç kataloğunu kullanacağı ortamda MCP avantaj sağlayabilir. Ek protokol katmanı operasyon ve security management yükü de getirir. Seçim ekosistem ihtiyacına göre yapılmalıdır. Küçük projede sadece popüler olduğu için yeni katman eklemek gerekli değildir.

MCP Güvenlik Riskleri

MCP server geniş dosya, shell veya database erişimine sahipse model dolaylı olarak aynı güce sahip olabilir. Tool description manipülasyonu veya kötü server davranışı da risk oluşturur. Server identity ve source doğrulanmalıdır. Network erişimi minimum tutulmalıdır. İnsan onayı ve audit log kritik write araçları için korunmalıdır.

Güvenilmeyen MCP Server Kullanmanın Riskleri

Güvenilmeyen MCP server modele kötü niyetli tool veya veri sunabilir. Credential veya kullanıcı verisi dış servise aktarılabilir. Server'ın update edildiğinde davranış değiştirme riski de vardır. Production'da yalnızca onaylı server allowlist kullanılmalıdır. Third-party server önce izole test ortamında incelenmelidir.

Dify Knowledge Base ve RAG Mimarisi

Dify Knowledge Base, şirket dokümanlarını LLM uygulamalarına bağlamak için kullanılan RAG katmanını yönetir. Doküman text extraction işleminden geçer, chunk'lara ayrılır ve embedding vektörleri oluşturulur. Kullanıcı sorgusunda benzer chunk'lar vector database üzerinden bulunur. Gerekirse reranker sonuç sırasını iyileştirir. Son context LLM'e gönderilerek modelin belgeye dayalı yanıt üretmesi amaçlanır.

RAG Nedir?

Retrieval-Augmented Generation, model cevap üretmeden önce harici bilgi kaynağından ilgili içerik bulma yaklaşımıdır. Amaç model eğitim bilgisini şirket verisiyle tamamlamaktır. Retrieval sonucu doğru değilse cevap da zayıflar. RAG model fine-tuning'in birebir alternatifi değildir. Güncel veya sık değişen kurumsal bilgi için genellikle daha yönetilebilir çözüm sunar.

Knowledge Base Oluşturma

Knowledge Base oluştururken önce konu ve erişim sınırı belirlenmelidir. Her dokümanı tek büyük havuza eklemek retrieval kalitesini düşürebilir. Departman veya uygulama bazlı ayrı collection oluşturulabilir. Metadata daha sonra filtreleme için kullanılabilir. Veri sahibi ve güncelleme sorumlusu belirlenmelidir.

Doküman Yükleme

PDF, Word veya desteklenen başka dosyalar knowledge base'e yüklenebilir. Dosya adı ve içerik encoding sorunları text extraction kalitesini etkileyebilir. Tarama görüntüsü içeren PDF'lerde ayrıca OCR ihtiyacı oluşabilir. Hassas belge yüklenmeden önce access policy doğrulanmalıdır. Duplicate dosyalar gereksiz index büyümesini önlemek için kontrol edilebilir.

Text Extraction

Text extraction belge içindeki gerçek metni indekslenebilir formata dönüştürür. Tablo veya çok kolonlu PDF'lerde sıra bozulabilir. Extraction çıktısı örnek belgeler üzerinde manuel kontrol edilmelidir. Bozuk metni embedding etmek retrieval kalitesini düşürür. Gerekirse doküman ön işleme pipeline'ı oluşturulabilir.

Chunking

Chunking uzun dokümanı küçük ve aranabilir parçalara böler. Çok küçük chunk context kaybına, çok büyük chunk ise alakasız metnin modele taşınmasına yol açabilir. Başlık ve paragraf yapısını koruyan semantic chunking bazı belgelerde daha iyi sonuç verir. Tek bir ideal boyut bütün doküman türleri için geçerli değildir. Test sorularıyla chunk stratejisi karşılaştırılmalıdır.

Embedding

Embedding metni semantic similarity için vektöre dönüştürür. Query ve belge chunk'ları aynı embedding uzayında karşılaştırılır. Çok dilli içerikte model dil performansı önemlidir. Model değiştirildiğinde eski vektörlerle uyumluluk bozulabilir. Bu nedenle embedding modeli production architecture kararının önemli parçasıdır.

Vector Database

Vector database embedding kayıtlarını hızlı benzerlik araması için tutar. Index türü ve distance metric backend'e göre değişebilir. Büyük veri setinde memory ve disk ihtiyacı artar. Backup ve restore süreci normal relational database'den farklı olabilir. Vector store kaybı durumunda kaynak belgelerden yeniden index mümkün olsa bile bu işlem zaman alabilir.

Retrieval

Retrieval kullanıcı sorgusuyla ilgili chunk'ları arar. Top-K değeri kaç sonuç alınacağını belirler. Metadata filter yetki veya konu bazlı daraltma sağlayabilir. Retrieval sonucu kullanıcı cevabından bağımsız olarak ayrı kalite metriğiyle değerlendirilmelidir. Doğru belge ilk sonuçlarda değilse modelin cevap üretmesini beklemek sağlıklı değildir.

Reranking

Reranking ilk arama sonuçlarını daha güçlü modelle tekrar sıralar. Semantic similarity tek başına yeterli olmadığında fayda sağlayabilir. Ek latency ve inference maliyeti oluşturur. Reranker seçimi Türkçe dokümanlar üzerinde test edilmelidir. En iyi ayar gerçek retrieval benchmark ile bulunur.

LLM'e Context Aktarma

Retrieval sonucundaki chunk'lar LLM prompt'una context olarak eklenir. Çok fazla chunk model context'ini doldurup cevabı zayıflatabilir. Kaynak başlığı ve metadata eklemek citation üretimini kolaylaştırabilir. Modelden yalnızca verilen context'e dayanması istenebilir. Ancak instruction tek başına hallucination'ı tamamen engellemediği için groundedness ölçülmelidir.

Dify RAG Kalitesi Nasıl Artırılır?

RAG kalitesini artırmanın en hızlı yolu daha büyük LLM seçmek değildir. Önce retrieval'ın doğru belgeyi bulup bulmadığı ölçülmelidir. Chunking, metadata, Top-K, threshold ve reranking ayarları sistematik biçimde test edilebilir. Gerçek kullanıcı sorularından küçük bir benchmark seti oluşturmak değişikliklerin etkisini görmeyi sağlar. Ben RAG projelerinde model tuning'e geçmeden önce retrieval hit rate ve source relevance metriklerini düzeltmeyi tercih ediyorum.

Chunk Boyutunu Optimize Etmek

Chunk boyutu dokümanın yapısına ve soru türüne göre belirlenmelidir. Sıkı prosedür maddelerinde daha küçük chunk işe yarayabilir. Uzun açıklamalı teknik belgelerde daha büyük bağlam gerekebilir. Sadece token sayısına göre değil semantic bütünlüğe bakılmalıdır. Farklı boyutlar aynı test setinde karşılaştırılmalıdır.

Chunk Overlap

Chunk overlap paragraf sınırında bilginin parçalanmasını azaltabilir. Çok yüksek overlap aynı metnin defalarca index'e girmesine yol açar. Bu durum retrieval sonuçlarında duplicate content oluşturabilir. Overlap belgenin yapısına göre ayarlanmalıdır. Sonuçlarda aynı cümlenin tekrar tekrar gelmediği kontrol edilmelidir.

Metadata Kullanımı

Metadata doküman departmanı, tarih, ürün veya access group gibi bilgileri taşıyabilir. Retrieval sırasında filter uygulanarak arama alanı daraltılabilir. Yetki duyarlı RAG için metadata önemli araçtır. Ancak metadata kullanıcı tarafından manipüle edilebilen kaynaktan geliyorsa doğrulanmalıdır. Belge lifecycle değiştiğinde metadata da güncellenmelidir.

Top-K

Top-K retrieval sonucunda kaç chunk'ın alınacağını belirler. Değeri artırmak daha fazla bilgi sunar, fakat context gürültüsünü ve token maliyetini de yükseltir. Çok düşük değer gerekli belgeyi kaçırabilir. Ideal değer test sorularında ölçülmelidir. Farklı soru türleri için dinamik Top-K de değerlendirilebilir.

Score Threshold

Score threshold yeterince ilgili olmayan chunk'ların context'e girmesini engelleyebilir. Çok yüksek threshold gerçek cevabı kaçırabilir. Çok düşük threshold alakasız sonuç getirir. Embedding model değiştiğinde score dağılımı da değişebilir. Threshold her model ve dataset için benchmark üzerinden seçilmelidir.

Reranker

Reranker özellikle ilk vector search sonuçları yakın olduğunda sıralamayı iyileştirebilir. Belge ve sorguyu birlikte değerlendirerek daha alakalı sonuçları üste taşıyabilir. Ek maliyet ve latency üretir. Bütün uygulamalarda zorunlu değildir. Kullanılmadan önce retrieval metric'lerinde gerçek iyileşme gösterdiği doğrulanmalıdır.

Hybrid Search

Hybrid search semantic vector arama ile keyword tabanlı aramayı birleştirir. Ürün kodu veya özel teknik terimlerde keyword search avantajlı olabilir. Kavramsal sorularda embedding güçlü sonuç verebilir. İki yöntemin skorlarını birleştirme stratejisi önemlidir. Kendi doküman setinde hybrid ve vector-only sonuçları karşılaştırılmalıdır.

Query Transformation

Kullanıcı sorusu retrieval için iyi biçimde yazılmamış olabilir. Query rewrite veya expansion ile arama sorgusu iyileştirilebilir. Ancak dönüşüm asıl kullanıcı niyetini değiştirmemelidir. Ek model çağrısı latency ve maliyet ekler. Sadece ihtiyaç duyulan soru türlerinde kullanmak daha verimli olabilir.

Retrieval Test Seti Oluşturmak

Gerçek dokümanlardan soru ve beklenen kaynak eşleşmeleri hazırlanabilir. Her soru için hangi chunk veya belge bulunmalı kaydedilir. Retrieval değişikliği sonrası aynı test seti tekrar çalıştırılır. Böylece “daha iyi görünüyor” yerine ölçülebilir sonuç elde edilir. Test seti yeni kullanıcı hatalarıyla düzenli genişletilmelidir.

Şirket İçi Belgeler Dify'a Nasıl Bağlanır?

Şirket içi belge entegrasyonunda teknik bağlantı kadar erişim modeli önemlidir. PDF, Word, wiki, database ve datasource plugin kullanılabilir. Belge değiştiğinde knowledge base'in nasıl güncelleneceği planlanmalıdır. Kullanıcının yetkisi olmayan belge retrieval sonucuna girmemelidir. Kurumsal Dify kurulumu ve yapay zeka orkestrasyon hizmeti tasarlanırken veri sahibi ve retention politikası en başta belirlenmelidir.

PDF ve Word Belgeleri

PDF ve Word şirket bilgisinin en yaygın kaynakları arasındadır. Dosya yükleme sonrası text extraction sonucu kontrol edilmelidir. Tarama PDF'leri farklı pipeline gerektirebilir. Belge versioning varsa eski sürümler knowledge base'ten kaldırılmalıdır. Hassas dokümanlar ayrı access scope içinde tutulmalıdır.

Markdown

Markdown temiz başlık ve metin yapısı sayesinde RAG için oldukça kullanışlıdır. Teknik dokümantasyon repository içinde Markdown tutulabilir. Git değişiklikleri ingestion pipeline'ını tetikleyebilir. Başlık metadata'ları chunking sırasında korunabilir. Eski branch dokümanlarının yanlışlıkla production knowledge base'e eklenmemesine dikkat edilmelidir.

Web Sayfaları

Web sayfaları crawler veya datasource entegrasyonu üzerinden alınabilir. Dinamik sayfalarda gerçek içerik extraction zor olabilir. Public sayfa bile güvenilir instruction kaynağı kabul edilmemelidir. Sayfa içindeki indirect prompt injection RAG veya agent davranışını etkileyebilir. İçerik snapshot ve update zamanı metadata olarak tutulabilir.

Veritabanları

Structured şirket verisi doğrudan doküman olarak embed edilmek yerine çoğu zaman kontrollü API veya tool üzerinden sorgulanmalıdır. Database'e agent'ın doğrudan geniş SQL yetkisi verilmemelidir. Read-only view veya güvenli service endpoint kullanılabilir. Kullanıcı authorization backend tarafından uygulanmalıdır. RAG ile transactional veriyi karıştırmadan önce veri güncelliği gereksinimi değerlendirilmelidir.

Kurumsal Wiki

Kurumsal wiki sürekli güncellenen iç bilgi için değerli kaynaktır. Datasource entegrasyonu veya periyodik sync ile knowledge base güncellenebilir. Sayfa permission bilgileri mümkünse retrieval'a taşınmalıdır. Silinen sayfalar vector store içinde stale kalmamalıdır. Wiki space veya department metadata'sı arama kalitesini artırabilir.

Datasource Plugin

Datasource plugin belirli içerik platformundan veri çekme işini standartlaştırabilir. Credential minimum read scope'a sahip olmalıdır. Sync periyodu veri güncelliğine göre belirlenir. Plugin update sonrası mapping ve deletion behavior test edilmelidir. Production'da plugin logları veri ingestion hataları açısından izlenmelidir.

Belgelerin Otomatik Güncellenmesi

Knowledge base sadece ilk import günündeki snapshot olarak kalmamalıdır. Kaynak belge değiştiğinde incremental sync veya scheduled ingestion yapılabilir. Duplicate içerik ve stale chunk temizliği önemlidir. Yeni belge hemen production cevabına girmeden önce approval gerekebilir. Güncelleme başarısızlığında alarm üretilmelidir.

Yetki Duyarlı Retrieval

Yetki duyarlı retrieval kullanıcının sadece erişebildiği belgelerde arama yapmasını sağlar. User role veya group metadata filter ile ilişkilendirilebilir. Bu kontrol yalnızca LLM prompt'unda “gizli belgeyi söyleme” şeklinde uygulanmamalıdır. Retrieval katmanı yetkisiz belgeyi modele hiç göndermemelidir. Access rule testleri farklı kullanıcı rolleriyle düzenli çalıştırılmalıdır.

Dify ile Uçtan Uca Örnek AI Workflow

Basit ama production'a yakın örnek bir workflow kullanıcı sorusuyla başlayabilir. Önce question classifier isteğin bilgi sorusu mu yoksa işlem talebi mi olduğunu belirler. Bilgi sorusunda knowledge retrieval çalışır ve LLM bulunan context üzerinden cevap üretir. Retrieval confidence düşükse harici API veya human review yolu açılabilir. Sonuç template ile standardize edilip output node üzerinden kullanıcıya döndürülür.

Kullanıcı Sorusu

Kullanıcının serbest metin sorusu ilk input'tur. Uzunluk limiti uygulanabilir. Prompt injection ve kişisel veri açısından riskli içerik log policy içinde değerlendirilmelidir. User ID backend tarafından güvenilir şekilde eklenmelidir. Girdi normalize edilmeden direkt kritik tool'a gönderilmemelidir.

Question Classification

Classifier soruyu örneğin “ürün bilgisi”, “hesap işlemi” ve “diğer” sınıflarına ayırabilir. Belirsiz sorular fallback yoluna gider. Classification hatası yanlış tool veya knowledge base seçimine yol açabileceği için ölçülmelidir. Kritik işlemler sadece classifier sonucuyla authorize edilmemelidir. Test seti gerçek kullanıcı ifadeleri içermelidir.

Knowledge Retrieval

Bilgi sorusunda uygun knowledge base aranır. Metadata filter kullanıcının departmanına göre daraltılabilir. Top-K ve threshold ayarları retrieval benchmark ile belirlenir. Hiç güvenilir sonuç yoksa modelden uydurma cevap istenmez. Bu durumda alternatif bilgi kaynağı veya açık “bilgi bulunamadı” cevabı tercih edilir.

LLM Yanıtı

LLM yalnızca gerekli user question ve retrieval context ile çağrılır. Sistem instruction modelden kaynak dışı iddia üretmemesini ister. Cevapta kullanılan kaynak metadata'sı eklenebilir. Structured output gerekiyorsa JSON schema kullanılabilir. Model latency ve token kullanımı run loglarda izlenir.

Confidence Kontrolü

Retrieval score veya ayrı evaluation sonucu belirli eşik altında kaldığında cevap doğrudan kullanıcıya gönderilmez. Daha güçlü model veya ikinci retrieval yöntemi denenebilir. Kritik kullanımda insan onayı alınabilir. Threshold gerçek test verisiyle belirlenmelidir. Confidence kavramı modelin kendi “eminim” ifadesine dayandırılmamalıdır.

Gerekirse Harici API Çağrısı

Bilgi tabanında bulunmayan güncel müşteri veya stok bilgisi şirket API'sinden alınabilir. Endpoint ve parametre allowlist ile sınırlandırılır. User authorization backend API tarafından tekrar doğrulanır. API timeout veya hata durumunda fallback mesajı oluşturulur. Hassas response alanları LLM context'ine gereksiz eklenmez.

Template ile Çıktı Formatlama

Final cevap sabit formatta sunulacaksa Template node kullanılabilir. Kaynak adı, cevap ve uyarı alanları aynı düzende birleştirilebilir. Modelin her seferinde format üretmesi gerekmez. HTML veya Markdown output gerekiyorsa escaping ve güvenlik göz önünde bulundurulur. API client için structured JSON daha uygun olabilir.

Output

Output node kullanıcı veya backend'e dönen final sonucu tanımlar. Hassas internal debug bilgileri temizlenir. Error ve success formatı tutarlı tutulur. API contract değişecekse versioning düşünülmelidir. Final response kullanıcıya neyin kesin bilgi neyin öneri olduğunu açıkça ifade etmelidir.

Workflow Testi

Test yalnızca “normal” kullanıcı sorusuyla yapılmamalıdır. Boş input, yanlış kullanıcı rolü, retrieval yokluğu ve API timeout senaryoları denenmelidir. Prompt injection örnekleri güvenlik testine eklenmelidir. Her release değişikliğinde regression dataset tekrar çalıştırılabilir. Test sonucu production deployment gate olarak kullanılabilir.

Dify ile Şirket İçi AI Asistanı Örneği

Şirket içi AI asistanı Dify'ın RAG, workflow ve tool özelliklerini birlikte kullanan güçlü bir senaryodur. Kullanıcı kimliği şirket identity sistemi tarafından doğrulanır. Departman bilgisine göre uygun knowledge base ve tool set seçilir. HR veya CRM gibi sistemlere erişim minimum scope ile sağlanır. Kritik write işlemleri insan onayından geçerken bütün workflow run'ları merkezi log ve monitoring sistemiyle izlenir.

Kullanıcı Kimliği

Asistan kullanıcı rolünü kendi sohbet mesajından öğrenmemelidir. Backend veya SSO katmanı güvenilir identity bilgisini Dify'a aktarır. User ID conversation ve audit kayıtlarıyla ilişkilendirilebilir. Departman değiştiğinde access mapping otomatik güncellenmelidir. Kimlik doğrulama ve authorization ayrı kavramlar olarak ele alınmalıdır.

Şirket Bilgi Tabanı

Şirket prosedürleri ve iç dokümanlar kontrollü knowledge base'lere ayrılabilir. HR belgeleri ile teknik belgeler aynı global alanda olmak zorunda değildir. Metadata access group ile ilişkilendirilir. Belge owner ve review tarihi tutulmalıdır. Eski prosedürler production retrieval'dan kaldırılmalıdır.

RAG

Asistan kullanıcı sorusu için yalnızca yetkili bilgi tabanlarında retrieval yapar. Kaynak chunk'lar final cevapta referans olarak gösterilebilir. Retrieval bulunamadığında model genel bilgi uydurmak yerine açıklama yapabilir. RAG testleri departman bazlı hazırlanmalıdır. Sensitive belge leakage için negative access testleri yapılmalıdır.

Departman Bazlı Routing

Kullanıcı role ve department bilgisi workflow routing'de kullanılabilir. Finans kullanıcısı finans knowledge base'e erişebilir, fakat HR özel belgelerini göremez. Routing policy backend tarafından doğrulanan identity attribute'larına dayanmalıdır. Fallback branch yanlışlıkla global bilgi tabanına gitmemelidir. Erişim matrisi düzenli review edilmelidir.

HR Tool

HR tool izin bakiyesi veya şirket prosedürü gibi sınırlı verileri sağlayabilir. Kullanıcı sadece kendi bilgisine erişebilmelidir. Administrator HR işlemleri ayrı role ve approval gerektirir. Tool backend authorization kontrolü yapmalıdır. LLM'in gönderdiği employee ID tek başına yetki kanıtı değildir.

CRM Tool

CRM tool satış ekibine müşteri özetleri sunabilir. İlk sürüm read-only tasarlanabilir. Kayıt güncelleme gerektiğinde kullanıcıya değişiklik özeti gösterilip onay alınabilir. CRM API token minimum scope'a sahip olmalıdır. Tool logları ilgili müşteri kaydı ve kullanıcıyla ilişkilendirilebilir.

İnsan Onayı

Kritik işlemlerde asistan yalnızca öneri veya taslak hazırlamalıdır. Kullanıcı sonucu görüp onayladıktan sonra write tool çağrılır. Onay ekranında yapılacak değişiklik açıkça gösterilir. “Devam et” gibi belirsiz cevaplar kritik işlem için yeterli sayılmamalıdır. Approval kayıtları audit amacıyla saklanabilir.

Loglama

Workflow run, tool call ve authentication event'leri merkezi olarak loglanmalıdır. Loglarda API key ve password gibi secret'lar maskelenmelidir. Prompt ve conversation içeriğinin saklama süresi veri politikasına göre belirlenir. Incident investigation için user ID ve run ID ilişkilendirilir. Log erişimi sadece yetkili ekiplerle sınırlandırılmalıdır.

API ile Şirket Uygulamasına Entegrasyon

Dify asistanı şirket portalına API üzerinden entegre edilebilir. API key browser içinde tutulmaz. Backend kullanıcı session'ını doğrular ve Dify çağrısını kendisi yapar. User ID Dify isteğine güvenilir backend tarafından eklenir. Rate limit ve audit logging aynı gateway katmanında uygulanabilir.

Dify Workflow'u API Olarak Yayınlamak

Dify workflow bir kez test edildikten sonra API olarak yayınlanabilir. Bu yaklaşım Dify arayüzünü son kullanıcıya göstermek yerine mevcut uygulamalara AI yeteneği eklemeyi sağlar. API key server-side tutulmalıdır. Streaming ve blocking response seçenekleri kullanım senaryosuna göre seçilir. Conversation ve user ID yönetimi backend architecture içinde açıkça tasarlanmalıdır.

Publish

Workflow geliştirme aşamasından sonra yayınlanarak dış kullanım için hazır hâle getirilebilir. Production'a publish etmeden önce test run'ları tamamlanmalıdır. Büyük değişiklikler staging instance üzerinde doğrulanmalıdır. Published sürümün hangi workflow revision olduğu kaydedilmelidir. Geri dönüş için önceki export saklanabilir.

API Key

API key Dify application API'sine erişim credential'ıdır. Frontend JavaScript içine gömülmemelidir. Backend secret store içinde tutulmalıdır. Key sızarsa derhal rotate edilmelidir. Farklı uygulamalar için ayrı key kullanmak kullanım takibini kolaylaştırır.

REST API

REST API standart HTTP çağrısıyla Dify workflow'u çalıştırmanızı sağlar. Request body workflow input'larını içerir. Backend response status ve hata alanlarını kontrol etmelidir. Input schema application contract olarak dokümante edilmelidir. API değişiklikleri client sürümleriyle koordineli yapılmalıdır.

Blocking Response

Blocking response workflow tamamlanana kadar HTTP bağlantısını açık tutar. Kısa işlemler için basittir. Uzun model veya tool çağrılarında timeout riski artar. Proxy ve client timeout değerleri uyumlu olmalıdır. Çok uzun görevler için asenkron tasarım daha uygun olabilir.

Streaming Response

Streaming response model çıktısını parça parça kullanıcıya iletir. Chat deneyiminde algılanan latency'yi azaltır. Reverse proxy buffering ayarı doğru olmalıdır. Client stream'in hata ve kapanma davranışını desteklemelidir. Loglarda final token ve session sonucu ayrıca tutulabilir.

Conversation ID

Conversation ID çok turlu sohbetlerde state'in aynı oturumda devam etmesini sağlar. Kullanıcılar arasında conversation ID karışmamalıdır. Backend conversation ownership kontrolü yapmalıdır. Uzun süreli conversation context token maliyetini artırabilir. Retention ve cleanup politikası uygulanmalıdır.

User ID

User ID Dify çağrısını belirli son kullanıcıyla ilişkilendirmek için önemlidir. Bu değer frontend'den güvenilmez biçimde kabul edilmemelidir. Backend authentication sonucundan üretilmelidir. Rate limit ve audit işlemlerinde kullanılabilir. Hassas kişisel tanımlayıcı yerine uygun internal pseudonymous ID tercih edilebilir.

Web Uygulamasından Çağırmak

Browser doğrudan Dify API key kullanmamalıdır. Web uygulaması kendi backend endpoint'ine istek gönderir. Backend user session'ını doğrulayıp Dify API çağrısını gerçekleştirir. Input validation ve rate limit burada uygulanır. Streaming gerekiyorsa backend proxy bunu güvenli biçimde iletebilir.

Backend Servisinden Çağırmak

Backend servis Dify API key'i secret manager'dan okuyabilir. Network erişimi private route üzerinden sağlanabilir. Retry ve timeout policy merkezi uygulanır. Her request user veya service identity ile loglanabilir. Bu architecture API key sızıntısı riskini frontend yaklaşımına göre önemli ölçüde azaltır.

Dify API Güvenliği

Dify API production uygulamasının doğrudan veri ve model katmanına erişim sağlar. Bu nedenle API key'in gizliliği, rate limit ve input validation temel kontrollerdir. Kullanıcıdan gelen veri doğrudan tool veya internal API parametresine dönüşmemelidir. Output da güvenilmeyen model içeriği olarak ele alınmalıdır. API güvenliğini sadece HTTPS kullanmakla sınırlamak yeterli değildir.

API Key'i Frontend'de Tutmamak

Browser kaynak kodu kullanıcı tarafından görüntülenebilir. Bu nedenle frontend içine Dify API key koymak credential'ı fiilen public hâle getirir. Obfuscation güvenlik sağlamaz. Key yalnızca backend'de tutulmalıdır. Frontend kendi authenticated backend endpoint'ini çağırmalıdır.

Backend Proxy Kullanmak

Backend proxy client ile Dify arasında güvenlik katmanı oluşturur. Kullanıcı authentication ve authorization burada yapılabilir. API key client'a gönderilmez. Rate limit ve input size kontrolü uygulanabilir. Dify response gerekiyorsa filtrelenip kullanıcıya iletilir.

Rate Limiting

Her kullanıcı veya API client sınırsız request gönderememelidir. Rate limit hem maliyet hem abuse koruması sağlar. Burst ve uzun dönem limit ayrı belirlenebilir. High-value kullanıcı için farklı quota uygulanabilir. Limit aşımları monitoring sistemine gönderilebilir.

User-Based Limits

Global limit tek kötü kullanıcının bütün kapasiteyi tüketmesini engellemeyebilir. User-based quota her kullanıcıya ayrı sınır koyar. Backend authenticated user ID üzerinden sayaç tutabilir. Günlük token veya request limiti uygulanabilir. Kurumsal departman bazlı bütçe raporu üretilebilir.

Input Validation

Input tip, uzunluk ve format açısından doğrulanmalıdır. Dosya upload'larında MIME type ve boyut kontrolü yapılmalıdır. URL input varsa allowlist yaklaşımı değerlendirilebilir. Prompt injection tamamen validation ile çözülemez, fakat tool parametreleri ayrı doğrulanabilir. Hatalı input kontrollü 4xx response üretmelidir.

Output Validation

LLM çıktısı güvenilir backend verisi gibi kabul edilmemelidir. JSON schema bekleniyorsa parse ve schema validation yapılmalıdır. HTML gösterilecekse XSS açısından escape veya sanitize edilmelidir. Tool parametresi olarak kullanılacak output tekrar kontrol edilmelidir. Modelin “işlem başarılı” demesi gerçek API sonucunun yerine geçmez.

API Key Rotation

API key düzenli veya olay bazlı rotate edilebilir. Yeni key backend'e yüklenip eski key kısa geçiş sonrası iptal edilir. Rotation işlemi downtime oluşturmadan planlanabilir. Her environment ayrı key kullanmalıdır. Key kullanım logları beklenmeyen source IP açısından izlenebilir.

Dify ve n8n Birlikte Nasıl Kullanılır?

Dify ve n8n aynı problemi çözmek zorunda değildir. Dify LLM, RAG, prompt ve AI workflow katmanında güçlüdür. n8n ise geniş genel iş otomasyonu ve sistemler arası event tabanlı süreçlerde kullanılabilir. İki platform webhook veya REST API üzerinden birbirine bağlanabilir. Ben LLM kararının Dify'da, uzun business automation zincirinin ise genel otomasyon katmanında tutulduğu ayrımı çoğu projede daha anlaşılır buluyorum.

Dify'ın Güçlü Olduğu Alanlar

Dify model provider, RAG ve AI workflow yönetimini ortak arayüzde birleştirir. Prompt ve knowledge retrieval testleri görsel olarak yapılabilir. Agent ve tool entegrasyonu doğrudan AI uygulamasına odaklanır. Workflow run logları model davranışını izlemeyi kolaylaştırır. Bu nedenle AI reasoning ve context orchestration katmanı için doğal seçim olabilir.

n8n'in Güçlü Olduğu Alanlar

n8n genel iş otomasyonunda çok sayıda sistem entegrasyonuna odaklanan bir platformdur. Zamanlama, webhook ve veri taşıma süreçleri için kullanılabilir. AI dışındaki operasyonları da aynı workflow içinde yönetebilir. Dify ile kullanıldığında model mantığını kendisi taşımak zorunda değildir. İki platform arasında görev sınırı belirlemek bakım kolaylığı sağlar.

Dify'ı AI Reasoning Katmanı Olarak Kullanmak

n8n iş sürecinde ihtiyaç duyduğu sınıflandırma veya RAG cevabı için Dify API'yi çağırabilir. Dify sadece yapılandırılmış karar veya metin sonucu döndürür. Model API key'leri Dify tarafında merkezi kalır. AI workflow değişikliği n8n business akışını değiştirmeden yapılabilir. Bu ayrım ekip sorumluluklarını netleştirebilir.

n8n'i İş Süreci Orkestrasyonu İçin Kullanmak

Dosya geldiğinde e-posta gönderme veya CRM kaydı oluşturma gibi uzun entegrasyon zincirleri genel workflow sisteminde tutulabilir. Dify yalnızca gerekli AI adımında çağrılır. Böylece model hatası tüm business logic'in içine dağılmaz. Retry ve schedule mekanizmaları ayrı yönetilir. Her sistem kendi güçlü olduğu göreve odaklanır.

Webhook ile Birbirine Bağlamak

Dify ve otomasyon platformu webhook üzerinden event paylaşabilir. Endpoint authentication ve signature kullanılmalıdır. Payload schema versioned tutulmalıdır. Duplicate event için idempotency kontrolü yapılmalıdır. Her iki sistemde aynı correlation ID loglanırsa troubleshooting kolaylaşır.

Dify Workflow API'sini n8n'den Çağırmak

n8n HTTP request node üzerinden Dify workflow API'yi çağırabilir. Dify API key güvenli credential store'da tutulmalıdır. Input alanları açık schema ile hazırlanır. Response JSON içinden gerekli alanlar alınır. Timeout ve rate limit hataları için retry policy uygulanabilir.

Hibrit Orkestrasyon Mimarisi

Hibrit mimaride AI kararları Dify'da, uzun business süreçleri genel workflow katmanında yönetilebilir. Bu yaklaşım tek dev workflow yerine sorumluluk ayrımı sağlar. Her platform ayrı ölçeklenebilir. Monitoring correlation ID ile birleştirilebilir. Fazla sistem eklemek de operasyon yükü oluşturduğu için yalnızca gerçek ihtiyaç varsa kullanılmalıdır.

Dify vs n8n vs Flowise vs LangGraph

Bu araçlar aynı kategori içinde anılsa da odakları farklıdır. Dify görsel AI uygulaması, RAG ve agent yönetimine; n8n genel iş otomasyonuna; Flowise görsel LLM akışlarına; LangGraph ise kod odaklı stateful agent ve graph geliştirmeye daha yakın yaklaşır. Birini seçerken ekibin kod yetkinliği ve production kontrol ihtiyacı belirleyici olmalıdır. Görsel prototipleme ile tam kod kontrolü aynı proje aşamalarında farklı değer sağlayabilir. Gereksiz platform çoğaltmak yerine tek kullanım senaryosu üzerinden küçük proof of concept yapmak seçim sürecini hızlandırır.

Dify

Dify model yönetimi, RAG, workflow ve uygulama yayınlama özelliklerini bir arada sunar. Self-hosted ve cloud kullanım seçenekleri bulunur. Low-code ekiplerin AI uygulaması geliştirmesini kolaylaştırır. API ve plugin desteğiyle geliştirilebilir. Production işletiminde yine Docker, database ve monitoring bilgisi gerekir.

n8n

n8n genel otomasyon ve sistem entegrasyonu odaklıdır. Çok sayıda harici servisle workflow kurmak için kullanılabilir. AI node'ları bulunsa da temel tasarım alanı yalnızca LLM uygulaması değildir. Dify ile birlikte kullanıldığında business automation katmanı olabilir. Seçim mevcut entegrasyon ihtiyacına göre yapılmalıdır.

Flowise

Flowise LLM zincirleri ve agent akışlarını görsel olarak tasarlamaya odaklanan açık kaynaklı bir araçtır. Node tabanlı yaklaşım prototip geliştirmeyi kolaylaştırabilir. Dify ile özellik örtüşmesi bulunur. Production gereksinimlerinde authentication, deployment ve observability ihtiyaçları ayrıca karşılaştırılmalıdır. Ekibin hangi arayüz ve ekosistemi daha iyi yöneteceği önemlidir.

LangGraph

LangGraph kod odaklı graph ve agent state yönetiminde güçlü yaklaşım sunar. Python veya JavaScript ekibine daha ayrıntılı kontrol verebilir. Görsel low-code deneyimi yerine geliştirme ekibi kodla state ve node mantığını yönetir. Complex agent sistemlerinde avantaj sağlar. Bunun karşılığında development ve test sorumluluğu daha fazla kod tarafına taşınır.

Low-Code vs Code-First

Low-code araçlar hızlı prototip ve domain expert katılımı sağlar. Code-first framework'ler davranış üzerinde daha ince kontrol sunar. Küçük ekipte low-code üretkenliği artırabilir. Büyük engineering ekiplerinde version control ve test gereksinimleri code-first yaklaşımı öne çıkarabilir. Dify DSL export gibi özelliklerle iki yaklaşım arasında belirli köprüler sunabilir.

RAG Yeteneği

Dify knowledge base ve retrieval yönetimini platform içinde doğrudan sunar. Diğer araçlarda RAG farklı düzeyde hazır veya harici bileşenlerle kurulabilir. Karşılaştırmada chunking, metadata, reranking ve evaluation ihtiyaçlarına bakılmalıdır. Sadece “RAG destekliyor” ifadesi yeterli değildir. Kendi doküman setinizle kısa benchmark yapmak en doğru karşılaştırmadır.

Agent Yeteneği

Dify, Flowise ve LangGraph farklı yöntemlerle agent geliştirmeyi destekler. LangGraph code-first kontrolüyle karmaşık state machine yapılarında avantaj sağlayabilir. Dify ise görsel geliştirme ve application management kolaylığı sunar. Agent kalitesi temel olarak model, tool ve instruction tasarımına bağlıdır. Framework tek başına güvenli agent oluşturmaz.

Genel İş Otomasyonu

Genel business workflow ihtiyacı AI dışındaki yüzlerce entegrasyonu kapsıyorsa n8n benzeri araçlar avantaj sağlayabilir. Dify'ın odağı AI application orchestration'dır. İki platformu tek göreve zorlamak yerine rol ayrımı yapılabilir. Ancak iki sistem işletme maliyetini artırır. Küçük projede tek platformla çözülebilen işi bölmek gereksiz olabilir.

Production Kontrolü

Production kontrolü deployment, versioning, monitoring ve access management yeteneklerini kapsar. Code-first framework repository ve CI/CD ile çok ayrıntılı kontrol sağlar. Dify low-code kullanımını kolaylaştırırken self-hosting ve DSL export gibi operasyon seçenekleri sunar. Gerçek gereksinimler listelenerek araçlar karşılaştırılmalıdır. Demo başarısı production suitability ile aynı değildir.

Hangi Senaryoda Hangisi Seçilmeli?

Hızlı self-hosted RAG ve AI workflow için Dify güçlü başlangıçtır. Geniş business automation için n8n tarzı genel workflow aracı uygun olabilir. Görsel LLM flow denemeleri için Flowise değerlendirilebilir. Çok özel stateful agent sistemi geliştiren yazılım ekibi LangGraph tercih edebilir. Kararı küçük pilot, operasyon yükü ve ekip yetkinliği birlikte belirlemelidir.

Production Dify Sunucusunda Yedekleme

Production Dify backup planı tek bir `docker compose` klasörünü kopyalamaktan ibaret değildir. PostgreSQL, upload storage, vector database, plugin verileri ve environment configuration ayrı bileşenlerdir. Hangi verinin yeniden oluşturulabileceği ve hangisinin benzersiz olduğu belirlenmelidir. Yedekler aynı sunucunun diskinde tek kopya olarak tutulmamalıdır. Backup job başarısı monitoring sistemine raporlanmalıdır.

PostgreSQL Backup

PostgreSQL Dify'ın kritik kalıcı verilerini içerir. `pg_dump` veya kurum standardı backup yöntemi kullanılabilir. Backup dosyası şifreli ve harici storage üzerinde saklanmalıdır. Retention süresi belirlenmelidir. Restore testi yapılmadan backup'ın kullanılabilir olduğu varsayılmamalıdır.

Upload Storage Backup

Kullanıcı ve knowledge base dosyaları local storage üzerindeyse ayrı yedeklenmelidir. Database backup ile dosya backup arasında zaman uyumu önemlidir. Object storage kullanılıyorsa versioning ve lifecycle policy değerlendirilebilir. Silinen dosyaların ne kadar süre geri getirilebileceği belirlenmelidir. Backup erişimi production kullanıcılarından daha sınırlı tutulmalıdır.

Vector Database Backup

Vector store verisi bazı durumlarda kaynak belgelerden yeniden üretilebilir. Bununla birlikte büyük knowledge base için yeniden embedding uzun sürebilir ve maliyet oluşturabilir. Bu nedenle vector database native backup özelliği değerlendirilmelidir. Restore sonrası index integrity test edilmelidir. Embedding model sürümü de metadata olarak saklanmalıdır.

Plugin Verileri

Plugin configuration ve ilgili storage alanları yedekleme kapsamına girebilir. Kullanılan plugin listesi ve sürümleri ayrıca kayıt altına alınmalıdır. Sadece package dosyasını değil configuration bağımlılıklarını da düşünmek gerekir. Restore sırasında aynı plugin sürümünün bulunabilirliği doğrulanmalıdır. Private plugin build artifact'ları internal repository'de tutulabilir.

.env Dosyası

`.env` deployment'ı tekrar kurmak için önemli configuration içerir. Aynı zamanda secret taşıdığı için normal dosya backup'ından daha sıkı korunmalıdır. Encryption at rest kullanılabilir. Yetkili administrator dışında erişim verilmemelidir. Secret manager kullanılıyorsa backup yaklaşımı ilgili sistemin recovery planına göre değişir.

Workflow ve Knowledge Base Verileri

Workflow configuration ve knowledge metadata büyük ölçüde application database içinde yer alabilir. Bunun yanında workflow DSL export ek recovery katmanı sağlar. Kritik workflow'lar Git repository'de saklanabilir. Knowledge source belgeleri de ayrı kurumsal kaynakta bulunmalıdır. Böylece platform kaybında yalnızca database backup'a bağımlı kalınmaz.

Otomatik Günlük Yedek

Production için düzenli otomatik backup job manuel işlemi unutmamayı sağlar. Günlük, haftalık ve aylık retention katmanları kullanılabilir. Job başarılı göründüğünde dosya boyutu ve checksum da doğrulanmalıdır. Backup başarısızlığı alarm üretmelidir. Kritik değişiklik öncesinde ayrıca manuel snapshot alınabilir.

Harici Backup Storage

Yedeklerin tamamını Dify'ın çalıştığı aynı disk üzerinde tutmak sunucu kaybına karşı koruma sağlamaz. Ayrı object storage, backup sunucusu veya başka lokasyon kullanılmalıdır. Credential minimum write veya backup scope'a sahip olmalıdır. Ransomware riskine karşı immutable storage değerlendirilebilir. Restore erişimi ve network yolu önceden test edilmelidir.

Backup Yetmez: Restore Testi Nasıl Yapılır?

Backup dosyasının varlığı kurtarma garantisi değildir. Gerçek güvence, yedeğin temiz bir test sunucusunda başarılı şekilde restore edilebilmesidir. PostgreSQL, storage ve vector store birlikte doğrulanmalıdır. Workflow'ların açılması ve knowledge retrieval'ın çalışması test edilmelidir. Ben en az periyodik olarak uçtan uca restore tatbikatı yapılmasını production AI platformlarının temel işletim kontrolü olarak görüyorum.

Test Sunucusunda Restore

Restore production üzerinde denenmemelidir. Ayrı test sunucusu veya izole environment kurulmalıdır. Production secret'lar gerekiyorsa güvenli şekilde sağlanmalıdır. Test network dış servislere gerçek işlem göndermeyecek biçimde sınırlandırılabilir. Restore süresi ölçülerek gerçek RTO hakkında veri elde edilir.

PostgreSQL Restore

Database backup temiz PostgreSQL instance'a yüklenir. Schema ve migration uyumluluğu kontrol edilir. Dify aynı uygulama sürümüyle bağlanmalıdır. Kullanıcı, workflow ve configuration kayıtları doğrulanır. Restore sırasında hata veren extension veya permission sorunları runbook'a eklenmelidir.

Dosya Storage Restore

Upload ve knowledge dosyaları doğru path veya bucket'a geri yüklenir. Dosya permission ve ownership kontrol edilir. Database referansı bulunan dosyanın gerçekten açıldığı test edilir. Eksik dosyalar application loglarında hata oluşturabilir. Checksum kullanımı data corruption tespitine yardımcı olur.

Vector Store Restore

Vector database native backup'tan geri yüklenebilir veya kaynak belgeler yeniden index edilebilir. Restore sonrası örnek retrieval soruları çalıştırılır. Sonuç sayısı ve source ID'ler beklenen değerlerle karşılaştırılır. Index schema sürüm uyumluluğu önemlidir. Büyük dataset için restore süresi DR planına eklenmelidir.

Knowledge Base Kontrolü

Knowledge base arayüzde görünmesi tek başına yeterli değildir. Gerçek sorgular üzerinden retrieval çalıştırılmalıdır. Doküman ve chunk sayıları kontrol edilebilir. Embedding model provider erişiminin çalıştığı doğrulanmalıdır. Yetki filtreleri restore sonrası tekrar test edilmelidir.

Workflow Kontrolü

Kritik workflow'lar test input'larıyla çalıştırılmalıdır. External API endpoint'leri test ortamına yönlendirilmelidir. Model provider key'leri doğru environment değerlerinden gelmelidir. Tool ve plugin bağlantıları kontrol edilmelidir. Regression suite restore doğrulamasını otomatikleştirebilir.

Disaster Recovery Runbook

DR runbook hangi yedeğin nereden alınacağını ve hangi sırayla restore edileceğini açıklar. Database, file storage ve Dify sürüm bilgisi birlikte belirtilir. DNS ve certificate adımları unutulmamalıdır. Sorumlu kişiler ve escalation bilgileri bulunmalıdır. Her tatbikat sonrası runbook gerçek deneyime göre güncellenmelidir.

Dify Nasıl Güvenli Güncellenir?

Dify update işlemi production ortamında doğrudan `git pull` ve yeniden başlatma şeklinde yapılmamalıdır. Mevcut sürüm kaydedilmeli, release notes okunmalı ve backup alınmalıdır. Yeni image'lar önceden indirilip staging ortamında test edilebilir. Database migration varsa geri dönüş etkisi özellikle incelenmelidir. Production update sonrasında smoke test ve workflow regression testleri çalıştırılmalıdır.

Mevcut Sürümü Kaydetmek

Güncelleme öncesinde aktif Dify release tag'i kaydedilmelidir. Docker image tag veya digest bilgileri de saklanabilir. Git commit ID ek doğrulama sağlar. Bu bilgi rollback sırasında kritik olur. Environment dosyalarının snapshot'ı da alınmalıdır.

Release Notes Okumak

Release notes breaking change ve migration bilgisi sağlayabilir. Plugin veya environment değişikliği varsa önceden hazırlanılır. Güvenlik düzeltmeleri önceliklendirilir. Yeni özellikleri hemen aktif etmek zorunlu değildir. Update test planı release notes'a göre hazırlanmalıdır.

Backup Almak

Database ve file storage update öncesinde yedeklenmelidir. Backup tamamlandı mesajı yeterli değildir, dosyanın varlığı ve boyutu kontrol edilir. Kritik deployment'ta snapshot alınabilir. Yedek production sunucusundan bağımsız storage'a kopyalanmalıdır. Rollback sürecinin hangi backup'ı kullanacağı açık olmalıdır.

Yeni Image'ları Önceden İndirmek

Docker image'larını bakım penceresinden önce pull etmek downtime riskini azaltır. Registry bağlantı problemi update sırasında sürpriz olmaz. Image digest doğrulanabilir. Kullanılacak tag test ortamıyla aynı olmalıdır. Diskte yeterli alan bulunduğu kontrol edilmelidir.

Database Migration'larını Kontrol Etmek

Yeni Dify sürümü schema migration çalıştırabilir. Migration geriye uyumlu değilse basit image rollback yeterli olmayabilir. Release notes ve migration script'leri bu nedenle önemlidir. Büyük database üzerinde migration süresi staging copy ile ölçülebilir. Backup restore planı hazır olmalıdır.

Staging Güncellemesi

Staging önce yeni sürüme yükseltilir. Kritik workflow ve knowledge base testleri çalıştırılır. Plugin compatibility kontrol edilir. Performance veya UI davranış değişikliği gözlemlenir. Test başarılı olmadan production update planlanmamalıdır.

Production Update

Production update planlı maintenance window içinde yapılabilir. Kullanıcılara gerekiyorsa önceden bilgi verilir. Deployment komutları runbook üzerinden uygulanır. Container health ve migration logları takip edilir. Beklenmeyen hata varsa plansız düzeltme yerine rollback kararı değerlendirilebilir.

Smoke Test

Update sonrası login, model çağrısı ve temel workflow hızlıca test edilir. Knowledge retrieval ve API endpoint de kontrol edilmelidir. Nginx ve certificate davranışı doğrulanır. Worker queue normal mi incelenir. Smoke test başarısızsa production açık bırakılmamalıdır.

Rollback Planı

Rollback hangi koşulda önceki sürüme dönüleceğini açıklar. Eski image ve configuration hazır tutulmalıdır. Migration geri dönüşü mümkün değilse database restore gerekebilir. DNS veya proxy değişikliği de geri alınmalıdır. Rollback sonrasında regression test tekrar çalıştırılmalıdır.

Dify'da Dev, Staging ve Production Ortamları

Tek Dify instance üzerinde hem deneme hem gerçek şirket kullanımını yürütmek değişiklik riskini artırır. Development geliştiricilerin rahatça deney yaptığı alan olabilir. Staging production configuration'a yakın test ortamıdır. Production ise sadece onaylanmış workflow ve plugin değişikliklerini almalıdır. Environment bazlı API key ve model credential kullanmak yanlışlıkla gerçek veri veya maliyet oluşturmayı azaltır.

Development Instance

Development ortamında yeni workflow ve plugin denemeleri yapılır. Production verisi burada kopyalanmamalıdır. Dummy veya anonimleştirilmiş test data kullanılabilir. Debug logging daha ayrıntılı olabilir. Ortamın dış sisteme write erişimi sınırlanmalıdır.

Staging Instance

Staging production'a mümkün olduğunca benzer architecture kullanmalıdır. Güncelleme ve workflow release burada test edilir. External API'ler sandbox endpoint'lerine bağlanabilir. Regression dataset otomatik çalıştırılabilir. Production'a geçiş için staging onayı şart hâline getirilebilir.

Production Instance

Production gerçek kullanıcı ve şirket verisini işler. Debug veya deneysel plugin kullanılmamalıdır. Değişiklikler approval ve rollback planıyla yapılmalıdır. Monitoring, backup ve alerting aktif olmalıdır. Administrator erişimi minimum tutulmalıdır.

Environment Bazlı API Key'ler

Her ortam ayrı model ve Dify API key kullanmalıdır. Development key'in limiti daha düşük olabilir. Production credential sadece production secret manager içinde tutulur. Key karışıklığı yanlış ortamda gerçek maliyet oluşturabilir. Provider billing raporu environment label ile ayrılabilir.

Workflow Değişikliklerini Test Etmek

Workflow önce dev ortamında hazırlanır. Export veya DSL üzerinden staging'e taşınır. Aynı regression input'ları çalıştırılır. Output quality ve latency karşılaştırılır. Test sonucu belirlenen threshold'u geçerse production release yapılır.

Sürüm Kontrolü

Workflow DSL ve ilgili configuration Git repository'de saklanabilir. Commit message change ID içerebilir. Pull request ekip review'u sağlar. Dify instance içindeki edit ile Git arasındaki kaynak doğruluğu standardize edilmelidir. Production'a yalnızca onaylı repository revision taşınmalıdır.

Production'a Kontrollü Geçiş

Release sırasında hangi workflow ve plugin'in değişeceği açıkça listelenir. Backup alınır. Staging test sonucu change kaydına eklenir. Production publish sonrası smoke test yapılır. Hata varsa önceki DSL veya release yeniden import edilebilir.

Dify Workflow'larında Versiyon Kontrolü

Low-code workflow'lar da normal yazılım kadar değişiklik geçmişine ihtiyaç duyar. Dify workflow DSL export ve import yöntemleri Git tabanlı version control için kullanılabilir. Değişiklik kimin tarafından ve neden yapıldığı commit history içinde tutulabilir. Code review modeli prompt ve node değişikliklerine de uygulanabilir. Böylece production workflow bir kişinin arayüzde yaptığı görünmez değişikliklere bağlı kalmaz.

Workflow DSL

Workflow DSL uygulamanın yapılandırılmış tanımını dışarı aktarmaya yardımcı olur. Export dosyası Git üzerinde saklanabilir. Hassas credential'ın export içinde bulunup bulunmadığı kontrol edilmelidir. Farklı Dify sürümleri arasında DSL uyumluluğu test edilmelidir. Production rollback için önceki working DSL değerli recovery seçeneğidir.

Export ve Import

Dev ortamındaki workflow export edilip staging veya production'a import edilebilir. Bu işlem manuel yeniden oluşturma hatasını azaltır. Import sonrası model provider ve environment-specific secret bağlantıları kontrol edilmelidir. Her environment aynı dış endpoint'i kullanmamalıdır. Import işlemi change record ile ilişkilendirilebilir.

Git Repository Kullanımı

Workflow DSL dosyaları ayrı repository veya uygulama koduyla birlikte saklanabilir. Branch policy production değişikliklerini review'a zorlayabilir. Secret scanning etkinleştirilebilir. Commit tag'leri release versiyonu olarak kullanılabilir. Repository erişimi minimum role ile sınırlandırılmalıdır.

Değişiklik Geçmişi

Git history hangi prompt veya node yapılandırmasının ne zaman değiştiğini gösterir. Incident sırasında önceki davranışla karşılaştırma yapılabilir. Büyük binary dosyalar yerine text DSL diff daha okunabilir olur. Commit message business reason içermelidir. History rewrite production repository'de sınırlandırılmalıdır.

Code Review

Workflow değişikliği sadece geliştirici tarafından onaylanmamalıdır. Başka ekip üyesi prompt, tool ve authorization etkisini kontrol edebilir. Security-critical write tool eklenmesi ayrıca güvenlik review gerektirebilir. Review comment'leri karar geçmişi oluşturur. Otomatik lint veya policy check gelecekte bu sürece eklenebilir.

Rollback

Yeni workflow sorun çıkarırsa önceki DSL sürümüne dönülebilir. Rollback işlemi model provider veya database migration'dan bağımsız olabilir. Önceki export'ın gerçekten import edilebildiği test edilmelidir. Rollback sonrası smoke test çalıştırılmalıdır. Olay nedeni daha sonra development ortamında analiz edilir.

Ekip İçinde Workflow Yönetimi

Birden fazla kişi aynı workflow'u düzenliyorsa owner ve review süreci gerekir. Production edit yetkisi az sayıda kullanıcıda tutulabilir. Development instance ortak çalışma alanı olabilir. Naming convention ve folder standardı ekip organizasyonunu kolaylaştırır. Workflow lifecycle oluşturma, test, yayınlama ve decommission adımlarını kapsamalıdır.

Dify Monitoring Nasıl Yapılır?

Production Dify monitoring yalnızca sunucunun “up” olup olmadığını kontrol etmekten daha kapsamlıdır. Container state, CPU, RAM, disk, PostgreSQL, Redis, worker queue ve API health birlikte izlenmelidir. Nginx ve application logları merkezi olarak toplanabilir. Threshold'lar gerçek baseline değerlerine göre belirlenmelidir. Kullanıcı şikâyetinden önce queue büyümesini veya disk dolmasını görmek monitoring sisteminin gerçek değeridir.

Docker Container Durumları

Container'ların running veya unhealthy durumu otomatik izlenebilir. Sürekli restart eden servis ciddi sorun göstergesidir. Restart count monitoring metriği hâline getirilebilir. Container health check varsa sonuç alarm üretir. Sadece Docker daemon'un çalışması uygulamanın sağlıklı olduğu anlamına gelmez.

CPU

Host ve container bazlı CPU kullanımı izlenmelidir. Uzun süre yüzde 90 üzeri kullanım worker veya indexing darboğazına işaret edebilir. Kısa spike normal olabilir. Load average ve process bilgisi birlikte değerlendirilmelidir. Autoscaling veya daha büyük instance kararı gerçek ölçüme dayanmalıdır.

RAM

RAM kullanımında available memory ve swap davranışı önemlidir. Container memory limit yoksa tek servis host'u zorlayabilir. OOM kill event'leri loglanmalıdır. Vector store ve database cache doğal olarak bellek kullanabilir. Sürekli memory pressure varsa kapasite artırımı veya servis ayrımı yapılmalıdır.

Disk

Disk doluluğu database ve upload işlemlerini tamamen durdurabilir. Yüzde 70 veya 80 gibi erken alarm eşikleri kullanılabilir. Volume bazlı kullanım ayrıca incelenmelidir. Docker image ve log birikimi düzenli temizlenebilir. Disk I/O latency de yoğun RAG indexing sırasında önemli metriktir.

PostgreSQL

Database connection count, query latency ve storage growth izlenebilir. Slow query'ler application gecikmesine yol açabilir. Backup job durumu ayrı alarm olmalıdır. Connection pool saturation API hatalarına dönüşebilir. Büyük production ortamında database için özel monitoring aracı kullanılabilir.

Redis

Redis memory usage ve connected clients izlenmelidir. Queue gecikmesi Redis problemiyle ilişkili olabilir. Eviction veya restart event'i application davranışını etkileyebilir. Persistence kullanımı architecture'a göre değerlendirilir. Harici Redis kullanılıyorsa network latency ayrıca ölçülmelidir.

Worker Queue

Worker queue uzunluğu background işlem kapasitesinin yeterli olup olmadığını gösterir. Sürekli büyüyen queue worker sayısının veya external API hızının yetersiz olduğunu gösterebilir. En eski task yaşı önemli metriktir. Hatalı job sürekli retry ediyorsa queue tıkanabilir. Alert threshold iş SLA'ına göre belirlenmelidir.

API Health

API health yalnızca TCP portu açık mı kontrolünden daha kapsamlı olmalıdır. Basit authenticated veya safe health endpoint çağrısı kullanılabilir. Response time ve error rate ölçülmelidir. 5xx artışı deployment veya dependency problemine işaret edebilir. Synthetic request gerçek kullanıcı akışını taklit edebilir.

Nginx Logları

Nginx access log request volume ve status code dağılımı sağlar. Error log upstream timeout veya connection refused gibi sorunları gösterir. Client IP ve request ID correlation için kullanılabilir. Hassas query parametreleri loglanmamalıdır. Log rotation disk dolmasını önler.

Dify Application Logları

Application logları model provider, workflow ve internal exception detaylarını içerebilir. Merkezi log platformunda searchable olması incident response'u hızlandırır. Secret masking uygulanmalıdır. Debug seviyesi sürekli açık tutulmamalıdır. Error pattern'leri alarm kuralına dönüştürülebilir.

AI Workflow Observability

Altyapı sağlıklı görünürken AI workflow yine kötü performans gösterebilir. Bu nedenle node latency, LLM latency, token kullanımı, tool sonucu ve retrieval kalitesi ayrıca izlenmelidir. Her workflow run tek correlation ID ile takip edilebilir. Maliyet ve hata oranı application KPI'larına eklenmelidir. Observability olmadan model veya prompt değişikliğinin gerçekten iyileştirme sağlayıp sağlamadığını anlamak zordur.

Workflow Run Logları

Run log her execution'ın başlangıç, sonuç ve node detaylarını gösterir. Başarısız kullanıcı isteğini yeniden analiz etmek mümkün olur. Input ve output retention hassas veri politikasına göre ayarlanmalıdır. Run ID support ticket ile ilişkilendirilebilir. Çok yüksek hacimde log sampling veya archive stratejisi gerekebilir.

Node-Level Execution

Node-level görünürlük hangi adımın hata verdiğini gösterir. Aynı workflow'da yalnızca bir HTTP node sorunlu olabilir. Input ve output schema karşılaştırılabilir. Kullanılmayan veya sürekli bypass edilen node tespit edilebilir. Bu veri workflow sadeleştirme için kullanışlıdır.

Node Latency

Her node'un çalışma süresi ölçüldüğünde toplam gecikmenin kaynağı bulunur. LLM hızlı olsa bile external API birkaç saniye sürebilir. Retrieval veya code node ayrıca darboğaz oluşturabilir. P95 latency ortalamadan daha anlamlı olabilir. Değişiklik sonrası latency regression alarmı kurulabilir.

LLM Latency

Time-to-first-token ve total generation time ayrı ölçülebilir. Cloud provider, model boyutu ve prompt uzunluğu latency'yi etkiler. Local model GPU yükü de önemli faktördür. Aynı task farklı modellerle benchmark edilebilir. Kullanıcı deneyimi açısından stream başlaması genellikle total süreden daha fazla hissedilir.

Token Kullanımı

Prompt ve completion token sayıları maliyetin ana sürücülerindendir. RAG context gereksiz uzun olduğunda prompt token artar. Conversation history de zamanla büyüyebilir. Workflow bazlı token budget belirlemek faydalıdır. Ani artış prompt veya data pipeline değişikliğinin işareti olabilir.

Maliyet

Her workflow run'ın tahmini model maliyeti hesaplanabilir. Kullanıcı veya departman bazlı rapor üretilebilir. Maliyet tek başına kalite hedefi değildir. Daha pahalı model gerçekten daha yüksek task success sağlamıyorsa değiştirilmelidir. Bütçe limiti ve alarmı production governance'ın parçası olmalıdır.

Tool Call Sonuçları

Tool call success, error ve latency değerleri izlenmelidir. Agent yanlış tool seçiyorsa seçim oranı görülebilir. Write tool çağrıları ayrı audit sınıfında tutulabilir. API response code trendleri entegrasyon problemi sinyali verir. Tool failure kullanıcıya uygun fallback ile yönetilmelidir.

Retrieval Sonuçları

Hangi chunk'ların hangi sorguda döndüğü RAG debugging için değerlidir. Score ve source metadata saklanabilir. Kullanıcı yanlış cevap bildirdiğinde önce retrieval incelenir. Alakasız source tekrar ediyorsa chunk veya embedding ayarları değiştirilebilir. Yetkisiz source görünümü security incident olarak değerlendirilmelidir.

Hata Oranı

Workflow execution error rate genel kalite göstergesidir. Error'lar model, tool, validation veya infrastructure kategorilerine ayrılabilir. Sadece toplam yüzde kök nedeni göstermez. Deployment sonrası ani artış rollback sinyali olabilir. Error budget service reliability hedeflerinde kullanılabilir.

Dify Workflow Kalitesi Nasıl Ölçülür?

AI workflow kalitesini sadece kullanıcı “cevap güzel” dediğinde ölçmek yeterli değildir. Task success, factual accuracy, groundedness, retrieval quality, tool success, latency ve maliyet birlikte değerlendirilmelidir. Aynı regression dataset her prompt veya model değişikliğinde tekrar çalıştırılabilir. Kullanıcı memnuniyeti de gerçek kullanım sinyali sağlar. Bu metrikler sayesinde daha büyük modele geçmenin gerçekten değer üretip üretmediği görülebilir.

Task Success Rate

Task success rate workflow'un kullanıcı görevini gerçekten tamamlayıp tamamlamadığını ölçer. Doğru dil üretmek ile işi tamamlamak aynı değildir. Örneğin CRM sorgusunda doğru müşteri kaydının bulunması başarı kriteridir. İnsan değerlendirmesi veya otomatik kontrol kullanılabilir. Task türleri ayrı raporlanmalıdır.

Factual Accuracy

Factual accuracy üretilen iddiaların gerçek verilerle uyumunu ölçer. RAG sistemlerinde source dokümanla karşılaştırma yapılabilir. Model cevabının akıcı olması doğruluğu garanti etmez. Kritik alanlarda human evaluator kullanılabilir. Yanlış iddia örnekleri regression dataset'e eklenmelidir.

Groundedness

Groundedness cevabın verilen kaynak context'e dayanma derecesidir. Model source'ta olmayan bilgi ekliyorsa skor düşer. RAG uygulamalarında önemli kalite ölçüsüdür. Automatic evaluator kullanılabilir, fakat örnek insan kontrolü yapılmalıdır. Groundedness düşükse retrieval ve prompt birlikte incelenir.

Retrieval Quality

Retrieval quality doğru belge veya chunk'ın ilk sonuçlarda gelip gelmediğini ölçer. Recall@K veya benzer metrikler kullanılabilir. Bu ölçüm LLM'den bağımsız yapılmalıdır. Retrieval kötü olduğunda model değişikliği sorunu çözmez. Test seti farklı belge türlerini kapsamalıdır.

Tool Success Rate

Tool success rate agent veya workflow'un tool çağrılarını ne kadar doğru tamamladığını gösterir. HTTP 200 tek başına business success olmayabilir. Doğru parametre ve doğru kayıt sonucu kontrol edilmelidir. Agent yanlış tool seçimi ayrı metric olabilir. Kritik write tool'larda başarısızlık oranı düşük tutulmalıdır.

Ortalama Latency

Ortalama latency genel fikir verir, ancak P95 ve P99 değerleri de önemlidir. Kullanıcıların küçük kısmı çok kötü deneyim yaşayabilir. Node bazlı latency kaynağı belirlemeye yardımcı olur. Streaming time-to-first-token ayrıca ölçülmelidir. SLA iş kullanımına göre belirlenmelidir.

Ortalama Token Maliyeti

Her task için ortalama token maliyeti workflow verimliliğini gösterir. Prompt veya RAG context büyüdükçe bu değer artabilir. Daha küçük model veya template kullanımının etkisi ölçülebilir. Maliyet trendi kullanıcı sayısından bağımsız normalize edilmelidir. Yüksek maliyetli edge case'ler ayrıca raporlanmalıdır.

Kullanıcı Memnuniyeti

Thumbs up/down veya kısa rating gerçek kullanıcı algısını gösterir. Tek başına kalite metriği değildir, çünkü doğru ama istenmeyen cevap düşük puan alabilir. Feedback metni kategorilere ayrılabilir. En çok şikâyet edilen soru türleri test setine eklenir. Kullanıcı davranışı model ve workflow iyileştirmesine yön verir.

Regression Test Dataset'i

Regression dataset sabit soru, input ve beklenen sonuç koleksiyonudur. Her release sonrası aynı testler çalıştırılır. RAG için beklenen source, agent için beklenen tool ve output kontrol edilebilir. Dataset production hatalarıyla büyütülmelidir. Version control altında tutulması değişiklik geçmişini korur.

Dify Performansı Nasıl Optimize Edilir?

Dify performansını artırmak için önce darboğazın nerede olduğunu ölçmek gerekir. Worker, Redis, PostgreSQL, vector search veya model latency farklı sorun kaynaklarıdır. Sunucuya daha fazla CPU eklemek dış model API'sinin yavaşlığını çözmez. Resource limit ve concurrency değerleri ölçüme göre ayarlanmalıdır. Production optimizasyonu her değişiklikten önce baseline ve sonra karşılaştırma gerektirir.

Worker Concurrency

Worker concurrency aynı anda kaç background işin işlenebileceğini etkiler. Çok düşük değer queue oluşturur. Çok yüksek değer CPU ve RAM'i tüketebilir. External embedding API rate limitleri de sınır olabilir. Load test ile uygun değer bulunmalıdır.

Redis Performansı

Redis hızlı queue ve cache işlemleri için düşük latency gerektirir. Memory pressure ve network gecikmesi worker performansını etkiler. Redis persistence ayarı kullanım senaryosuna göre seçilmelidir. Harici Redis private network üzerinde tutulmalıdır. Slow operation ve connection error alarm üretebilir.

PostgreSQL Performansı

Database query latency Dify API response süresini etkiler. Connection pool ve index kullanımı izlenmelidir. Disk I/O zayıfsa CPU artırmak sınırlı fayda sağlar. Vacuum ve backup süreçleri kurum DBA standardına göre yönetilebilir. Büyük ortamda ayrı database sunucusu düşünülebilir.

Vector Search Performansı

Vector search latency index boyutu ve backend kapasitesine bağlıdır. Çok yüksek Top-K sorguyu ağırlaştırabilir. Metadata filter doğru index'lenirse arama alanını daraltabilir. Backend-specific tuning yapılabilir. P95 retrieval latency workflow monitoring'e eklenmelidir.

RAG Indexing Performansı

Indexing text extraction, chunking ve embedding adımlarından oluşur. Embedding provider throughput önemli sınırlayıcı olabilir. Çok sayıda belgeyi kontrollü batch halinde işlemek daha stabildir. Worker concurrency provider limitine göre ayarlanmalıdır. Progress ve failure count izlenmelidir.

Model Latency

Model latency çoğu AI workflow'un en büyük süre bileşenidir. Daha küçük model veya düşük output token limiti hız sağlayabilir. Prompt kısaltma time-to-first-token değerini iyileştirebilir. Local modelde GPU ve quantization etkisi ölçülmelidir. Provider fallback yalnızca availability değil performans için de kullanılabilir.

Streaming

Streaming toplam işlem süresini azaltmaz, fakat kullanıcıya cevabın daha erken görünmesini sağlar. Chat uygulamalarında deneyimi önemli ölçüde iyileştirir. Proxy buffering kapalı olmalıdır. Client stream parse edebilmelidir. Connection kesilmesi durumunda retry davranışı açıkça tasarlanmalıdır.

Nginx Timeout

Proxy timeout çok düşükse uzun workflow 504 ile kesilebilir. Çok yüksek değer bağlantı kaynaklarını uzun süre tutar. Uygulama SLA'sına göre değer seçilmelidir. Streaming ile blocking endpoint farklı gereksinim gösterebilir. Timeout hataları access ve application loglarla birlikte incelenmelidir.

Docker Resource Limits

Container resource limit tek servisin host kaynaklarını tamamen tüketmesini önleyebilir. Çok dar limit OOM veya throttling oluşturabilir. API, worker ve database için farklı limit gerekir. Monitoring gerçek kullanım verisine göre limit tuning sağlar. Compose veya orchestrator configuration version control altında tutulmalıdır.

Dify Ne Zaman Tek Sunucudan Çıkarılmalı?

Tek Ubuntu sunucu başlangıç ve küçük production kullanımı için basit ve yönetilebilir olabilir. Kullanım arttıkça CPU saturation, memory pressure ve worker queue sorunları büyüyebilir. Daha önemlisi tek host bütün platform için single point of failure oluşturur. Yüksek erişilebilirlik veya çok sayıda eşzamanlı kullanıcı gerektiğinde servisleri ayırmak gerekir. Kubernetes'e geçiş de yalnızca popüler olduğu için değil ölçülmüş operasyon ihtiyacına göre yapılmalıdır.

CPU Saturation

CPU uzun süre yoğun saatlerde doygun çalışıyorsa execution latency artar. Worker ve API birbirinin kaynaklarını etkileyebilir. Önce hangi container'ın CPU kullandığı bulunmalıdır. Worker ayrı host'a taşınabilir. Dikey büyüme sınırına gelindiğinde yatay ölçekleme düşünülür.

RAM Baskısı

Memory pressure swap ve OOM kill olaylarına yol açabilir. Database, vector store ve worker aynı host'ta yarışabilir. Servisleri ayrı instance'lara taşımak isolation sağlar. Harici Redis ve PostgreSQL memory yükünü azaltabilir. Resource request ve limit Kubernetes geçişinde açık tanımlanmalıdır.

Worker Queue Büyümesi

Queue sürekli büyüyorsa background kapasitesi talepten düşüktür. Worker replica artırmak çözüm olabilir. Ancak darboğaz external API rate limit ise replica artırmak fayda sağlamaz. Queue age ve task duration izlenmelidir. Önce bottleneck doğrulanmalıdır.

Çok Sayıda Eşzamanlı Kullanıcı

Concurrent user artışı API ve model throughput ihtiyacını yükseltir. Reverse proxy connection sayısı ve database pool etkilenebilir. Stateless API replica load balancer arkasında çoğaltılabilir. Conversation ve shared state external servislerde tutulmalıdır. Load test kapasite planının temelidir.

High Availability Gereksinimi

Platform iş kritik hâle geldiğinde tek sunucu arızası kabul edilemeyebilir. API ve worker birden fazla replica ile çalıştırılabilir. Database ve storage da HA tasarımına dahil edilmelidir. Load balancer sağlık kontrolü yapmalıdır. DR ve HA farklı kavramlar olarak birlikte planlanmalıdır.

Single Point of Failure

Tek Dify host disk veya donanım arızasında tüm servislerin durmasına neden olur. Harici database kullanmak sadece bir SPOF'u kaldırır. Redis, storage, proxy ve inference katmanları da değerlendirilmelidir. Küçük kurum maliyet nedeniyle bu riski kabul edebilir. Karar açık RTO ve RPO hedeflerine dayanmalıdır.

Kubernetes'e Geçiş Kriterleri

Kubernetes yüksek availability, replica ve rolling update ihtiyacı oluştuğunda anlamlı olabilir. Ekibin Kubernetes işletme deneyimi yoksa platform karmaşası riski artar. Sadece bir Dify instance için cluster kurmak her zaman ekonomik değildir. Önce servis ayrımı ve harici database ile ölçekleme denenebilir. Kubernetes kararı trafik ve reliability gereksinimine göre verilmelidir.

Dify'ı Kubernetes'e Taşımak

Kubernetes'e geçiş Docker Compose dosyasını doğrudan dönüştürmekten daha kapsamlıdır. Stateful ve stateless servisler ayrılmalıdır. API ve worker replica sayıları bağımsız ölçeklenebilir. PostgreSQL, Redis ve object storage mümkün olduğunda harici veya HA servis olarak tasarlanabilir. Rolling update ve readiness probe production erişilebilirliğini artırabilir.

Docker Compose ve Kubernetes Farkı

Compose tek host üzerindeki container ilişkilerini basitçe yönetir. Kubernetes çoklu node, scheduling ve service discovery sağlar. Bunun karşılığında cluster networking, storage ve security yönetimi gerekir. Compose'ta local volume olan veri Kubernetes'te persistent storage tasarımı ister. Geçiş öncesinde her Dify servisinin state ihtiyacı çıkarılmalıdır.

API Replica

API service stateless çalışabildiği ölçüde birden fazla replica hâline getirilebilir. Load balancer request'leri dağıtır. Session veya cache bilgisi external servislerde tutulmalıdır. Readiness probe hazır olmayan pod'a trafik gitmesini önler. Replica sayısı load test verisine göre ayarlanmalıdır.

Worker Replica

Worker pod'ları queue uzunluğuna göre artırılabilir. CPU veya custom metric autoscaling kullanılabilir. Aynı task'ın iki kez işlenme davranışı queue sistemine göre kontrol edilmelidir. External API rate limit worker sayısını sınırlayabilir. Worker logları merkezi olarak toplanmalıdır.

Harici PostgreSQL

Production Kubernetes cluster içinde database işletmek ayrı uzmanlık gerektirir. Managed veya harici PostgreSQL operational yükü azaltabilir. Network policy sadece Dify namespace'inden erişime izin verebilir. TLS ve secret manager kullanılabilir. Backup ve point-in-time recovery planı kurulmalıdır.

Harici Redis

Redis cluster veya managed service queue ve cache için kullanılabilir. Dify pod'ları private endpoint üzerinden erişir. Authentication ve TLS destekleniyorsa etkinleştirilir. Redis availability workflow background işlemlerini doğrudan etkiler. Monitoring platform metric'lerini toplayabilir.

Object Storage

Birden fazla API replica local disk paylaşamaz. Upload dosyaları object storage'a taşınmalıdır. Bucket erişimi minimum service account yetkisiyle sınırlandırılır. Encryption ve versioning kullanılabilir. Lifecycle policy eski geçici dosyaları temizleyebilir.

Load Balancer

Load balancer dış HTTPS trafiğini ingress veya service'e yönlendirir. TLS termination burada yapılabilir. Sticky session ihtiyacı application behavior'a göre değerlendirilir. Health probe gerçek readiness durumuna bağlanmalıdır. WAF ve rate limit edge katmanında uygulanabilir.

Rolling Update

Rolling update yeni pod sürümünü kademeli şekilde devreye alır. Uygulama health check geçmeden eski replica kapatılmamalıdır. Database migration bu mekanizmanın dışında ayrıca planlanmalıdır. Backward-compatible schema değişiklikleri daha güvenli rollout sağlar. Hata oranı yükselirse rollout durdurulabilir.

High Availability

HA yalnızca çok sayıda API pod'u anlamına gelmez. Database, Redis, storage ve load balancer da yedekli olmalıdır. Farklı availability zone kullanımı altyapı riskini azaltabilir. Backup ve disaster recovery yine gereklidir. Chaos veya failure testleri gerçek HA davranışını doğrular.

Dify Kurulumunda Sık Karşılaşılan Hatalar

Dify kurulum hatalarının büyük kısmı port çakışması, environment değişkeni, servis bağımlılığı veya kaynak yetersizliğinden oluşur. Sorun giderirken aynı anda her ayarı değiştirmek yerine log ve bağlantı zincirini takip etmek daha etkilidir. Önce container durumuna, sonra ilgili servis loguna bakmak gerekir. Network hatasında host ve container içinden ayrı test yapılmalıdır. Her hata için çözümü rastgele forum komutlarıyla aramak yerine kullanılan release ve resmi configuration yapısını doğrulamak önemlidir.

Port 80 veya 443 Kullanımda

Nginx veya başka servis aynı portu dinliyorsa Docker container port bind edemez. `ss -tulpn` hangi process'in portu kullandığını gösterir. Mevcut reverse proxy varsa Dify'ın internal portu farklı tutulabilir. İki Nginx katmanını gereksiz yere aynı public portta çalıştırmamak gerekir. Architecture netleştirildikten sonra tek public giriş noktası seçilir.

Container Exited

Exited container önce log üzerinden incelenmelidir. Environment eksikliği, permission veya dependency hatası olabilir. `docker compose logs servis_adi` ilk hata mesajını gösterir. Restart loop'a bırakmak sorunu çözmez. Hata giderildikten sonra container yeniden başlatılır ve health kontrol edilir.

PostgreSQL Connection Refused

API database'e ulaşamıyorsa host, port veya credential yanlış olabilir. Database container'ın healthy durumu kontrol edilir. Dify container içinden DNS ve port testi yapılabilir. Public IP kullanmak yerine Compose service name tercih edilir. Harici PostgreSQL için firewall ve TLS configuration ayrıca incelenir.

Redis Connection Error

Redis hostname veya password uyumsuzluğu sık görülen nedenlerdendir. Redis container logu ve health durumu kontrol edilir. API veya worker içinden bağlantı testi yapılabilir. Public exposure açarak sorunu çözmeye çalışmak yanlış yaklaşımdır. Internal network ve doğru credential düzeltilmelidir.

502 Bad Gateway

502 genellikle Nginx'in upstream Dify servisine ulaşamadığını gösterir. API veya web container çalışıyor mu kontrol edilir. `proxy_pass` host ve port değeri doğrulanır. Container restart veya startup gecikmesi de geçici 502 oluşturabilir. Nginx error log gerçek nedeni gösterebilir.

Dify Admin Paneli Açılmıyor

Önce DNS ve HTTPS bağlantısı kontrol edilmelidir. Nginx erişiliyor ama sayfa gelmiyorsa web ve API container loglarına bakılır. Browser developer tools API request hatalarını gösterebilir. Yanlış console URL redirect problemi oluşturabilir. Internal portu doğrudan test etmek proxy ile uygulama sorununu ayırır.

Ollama Connection Refused

Dify container içindeki localhost Ollama host'unu göstermez. Reachable host IP veya Docker gateway kullanılmalıdır. Ollama servisinin hangi interface üzerinde dinlediği kontrol edilir. Firewall container network'ünden erişime izin vermelidir. Public internet açmak yerine private network çözümü tercih edilir.

Model Provider Bağlanmıyor

API key, base URL ve model adı ilk kontrol noktalarıdır. Dify host'tan provider endpoint'e `curl` yapılabilir. Proxy veya DNS problemi olabilir. Provider rate limit veya hesap yetkisi hata döndürebilir. Dify provider log ve error mesajı ayrıntılı incelenmelidir.

Knowledge Base Indexing Çok Yavaş

Embedding provider latency veya worker concurrency sınırlayıcı olabilir. Belge çok büyük veya chunk sayısı gereksiz fazla olabilir. Queue uzunluğu izlenmelidir. Local embedding modeli CPU üzerinde yavaş çalışıyor olabilir. Daha fazla worker eklemeden önce gerçek darboğaz belirlenmelidir.

Out of Memory

OOM host veya container memory limitinin aşılmasıdır. `dmesg` veya container state OOM kill gösterebilir. Worker concurrency azaltılabilir. Local LLM aynı host'taysa model belleği önemli neden olabilir. Kalıcı çözüm için memory kullanım trendi ölçülmelidir.

Disk Dolması

Docker image, log, database ve upload verileri diski doldurabilir. `df -h` ve Docker disk usage çıktıları kontrol edilir. Rastgele volume silmek veri kaybına yol açabilir. Önce hangi path'in büyüdüğü belirlenmelidir. Monitoring ve log rotation gelecekte aynı sorunu önler.

Dify Sorun Giderme Komutları

Dify troubleshooting sırasında birkaç Linux ve Docker komutu sorunun hangi katmanda olduğunu hızlıca gösterir. Container state, log, kaynak kullanımı, disk, port ve firewall birlikte incelenebilir. Komutların çıktısı birbiriyle ilişkilendirilmelidir. Örneğin 502 hatasında yalnızca Nginx loguna değil upstream container durumuna da bakmak gerekir. Production sunucusunda yıkıcı komutları kopyalayıp çalıştırmadan önce etkilerini anlamak önemlidir.

docker compose ps

`docker compose ps` aktif stack servislerinin durumunu gösterir. Exited veya unhealthy container hızlıca fark edilir. Port mapping bilgisi de görülebilir. Stack dizininde çalıştırılması gerekir. Sorunlu servis belirlendikten sonra log incelemesine geçilir.

docker compose logs

`docker compose logs` container stdout ve stderr kayıtlarını birleştirir. Servis adı verilerek output daraltılabilir. `--tail` son satırları göstermek için faydalıdır. Secret veya müşteri verisi içerebilecek loglar dışarı paylaşılmamalıdır. Zaman aralığıyla incident anına odaklanmak analizi kolaylaştırır.

docker stats

`docker stats` container bazlı CPU ve memory kullanımını canlı gösterir. Hangi servisin kaynak tükettiği hızlıca anlaşılır. Tek anlık snapshot trend yerine geçmez. Monitoring sistemi uzun süreli veri için daha uygundur. OOM öncesi memory growth araştırmasında yardımcıdır.

df -h

`df -h` dosya sistemlerinin doluluk oranını gösterir. Root disk doluysa Docker ve database yazma işlemleri başarısız olabilir. Volume mount'ları ayrıca kontrol edilmelidir. Yüzde 100'e ulaşmayı beklemeden alarm kurulmalıdır. Büyük klasörleri bulmak için ek disk kullanım araçları kullanılabilir.

free -h

`free -h` sistem memory ve swap durumunu özetler. Available memory değeri toplam free alanından daha anlamlıdır. Yüksek swap kullanımı memory pressure gösterebilir. Linux cache kullanımı normaldir. OOM loglarıyla birlikte yorumlanmalıdır.

ss -tulpn

`ss -tulpn` host üzerinde dinleyen TCP ve UDP servislerini gösterir. Public olması gerekmeyen database portları kolayca tespit edilir. Port 80 veya 443 çakışması burada görülebilir. Bind address `127.0.0.1` ile `0.0.0.0` arasındaki güvenlik farkını gösterir. Firewall kontrolüyle birlikte kullanılmalıdır.

ufw status

`ufw status` host firewall kurallarını gösterir. SSH, HTTP ve HTTPS beklenen şekilde açık mı kontrol edilir. Gereksiz port allow rule'ları kaldırılmalıdır. Docker'ın iptables davranışı bazı senaryolarda UFW beklentilerinden farklı olabilir. Gerçek dış erişim ayrıca port testiyle doğrulanmalıdır.

nginx -t

`nginx -t` configuration syntax ve temel dosya erişimini kontrol eder. Test başarılı olmadan reload yapılmamalıdır. Hata satır ve dosya bilgisini gösterir. Sertifika path problemleri de görülebilir. Başarılı test sonrası `systemctl reload nginx` kesintisiz config yenileme sağlayabilir.

curl ile Health Check

`curl` local ve public endpoint davranışını karşılaştırmak için çok kullanışlıdır. HTTP status, header ve TLS bilgisi incelenebilir. Container host'tan internal API çağrısı yapılabilir. Public domain üzerinden proxy zinciri test edilebilir. Authenticated endpoint'te token terminal history içinde görünmemelidir.

Container İçinden Bağlantı Testi

Host erişebiliyor diye container'ın da aynı servise ulaşabildiği varsayılmamalıdır. `docker exec` ile container içinde DNS veya HTTP testi yapılabilir. Ollama ve harici database sorunlarında bu yöntem özellikle faydalıdır. Container image içinde debug araçları bulunmayabilir. Production image'ı değiştirmek yerine geçici diagnostic container kullanılabilir.

Dify Güvenlik Kontrol Listesi

Dify self-hosted kurulumunda güvenlik tek seferlik kurulum adımı değildir. Host, Docker, Dify, model provider, plugin ve backup katmanlarının tamamı birlikte değerlendirilmelidir. Aşağıdaki kontroller production öncesi temel review listesi olarak kullanılabilir. Her “evet” cevabı mümkünse teknik test veya configuration kanıtıyla doğrulanmalıdır. Düzenli tekrar edilen kontrol listesi zamanla oluşan configuration drift'i yakalamaya yardımcı olur.

Root SSH Kapalı mı?

Doğrudan root SSH login günlük yönetimde kapalı tutulmalıdır. Kişisel administrator hesabı ve sudo kullanılabilir. Emergency access ayrı prosedürde korunabilir. Configuration gerçekten test edilmelidir. Cloud console recovery yolu bilinmelidir.

SSH Key Kullanılıyor mu?

Parola yerine SSH key authentication tercih edilmelidir. Private key güvenli tutulmalıdır. Shared private key kullanılmamalıdır. Çalışan ayrıldığında key kaldırılmalıdır. Mümkünse yönetim VPN üzerinden yapılmalıdır.

UFW Aktif mi?

Host firewall sadece gerekli portları izinli tutmalıdır. UFW aktif görünse bile Docker port mapping davranışı kontrol edilmelidir. Cloud security group ile tutarlı policy kullanılmalıdır. Kural değişiklikleri kayıt altına alınmalıdır. Dış port taraması gerçek sonucu doğrulamalıdır.

Sadece Gerekli Portlar Açık mı?

Public kullanımda çoğu zaman 80 ve 443 yeterlidir. SSH erişimi sınırlı kaynaklara açılabilir. PostgreSQL ve Redis internete kapalı olmalıdır. Ollama API de private network'te tutulmalıdır. `ss -tulpn` ile host exposure düzenli kontrol edilmelidir.

HTTPS Aktif mi?

Production login ve API trafiği HTTPS kullanmalıdır. Sertifika hostname ile uyumlu olmalıdır. HTTP otomatik HTTPS'e yönlendirilebilir. Renewal mekanizması test edilmelidir. Expiry alert kurulmalıdır.

Varsayılan Secret'lar Değiştirildi mi?

Örnek `.env` değerleri production secret olarak kullanılmamalıdır. Database ve internal service parolaları yenilenmelidir. SECRET_KEY güçlü random değer olmalıdır. Credential reuse yapılmamalıdır. Secret inventory tutulmalıdır.

Database İnternete Kapalı mı?

PostgreSQL public interface üzerinde gereksiz dinlememelidir. Harici database private network üzerinden erişilebilir olmalıdır. Firewall yalnızca Dify kaynaklarını izinli tutar. Strong authentication kullanılır. Connection logları izlenir.

Redis İnternete Kapalı mı?

Redis public port expose edilmemelidir. Internal Docker network en basit güvenli yapıdır. Ayrı host kullanılıyorsa private subnet tercih edilir. Authentication etkinleştirilir. Redis portunun public scan ile kapalı olduğu doğrulanır.

API Key'ler Güvenli mi?

Model ve Dify API key'leri frontend içinde bulunmamalıdır. Secret manager veya korumalı environment kullanılır. Key rotation prosedürü olmalıdır. Provider billing alert etkinleştirilir. Kullanılmayan key iptal edilir.

Plugin Kaynakları Güvenilir mi?

Production plugin listesi kontrol altında tutulmalıdır. Kaynak ve maintainer incelenmelidir. Gereksiz plugin yüklenmemelidir. Güncelleme önce staging'de test edilmelidir. Plugin network ve credential izinleri review edilmelidir.

Backup Aktif mi?

PostgreSQL ve dosya storage otomatik yedeklenmelidir. Backup aynı host'ta tek kopya olmamalıdır. Job failure alarm üretmelidir. Retention policy bulunmalıdır. Hassas yedekler şifrelenmelidir.

Restore Testi Yapıldı mı?

Backup düzenli test sunucusuna restore edilmelidir. Workflow ve knowledge retrieval gerçekten çalıştırılmalıdır. Restore süresi ölçülmelidir. Eksikler DR runbook'a eklenmelidir. Sadece backup job başarı mailine güvenilmemelidir.

Güncellemeler Takip Ediliyor mu?

Dify release ve security duyuruları izlenmelidir. Ubuntu ve Docker güncellemeleri de bakım sürecine dahil edilmelidir. Plugin update'leri unutulmamalıdır. Staging testleri update öncesi çalıştırılmalıdır. Kritik açıklar risk bazlı hızla ele alınmalıdır.

KVKK ve Şirket İçi Dify Kullanımı

Şirket içi Dify kullanımı kişisel veya hassas verinin işlenmesi durumunda veri koruma politikalarıyla birlikte tasarlanmalıdır. Hangi verinin Dify'da saklandığı ve hangi model sağlayıcısına gönderildiği açıkça çıkarılmalıdır. Prompt, conversation, knowledge base ve log verileri farklı retention ihtiyacına sahip olabilir. Local LLM bazı dış veri akışlarını azaltabilir, fakat sunucu güvenliği sorumluluğunu artırır. KVKK açısından özel hukuki yorum gerektiğinde kurumun hukuk ve veri koruma uzmanlarıyla değerlendirme yapılmalıdır.

Hangi Veriler Dify'da Saklanır?

Dify kullanım şekline bağlı olarak kullanıcı, conversation, workflow, knowledge base ve application metadata saklayabilir. Upload edilen dokümanlar storage üzerinde bulunabilir. Plugin ve tool logları ek veri oluşturabilir. Hangi tabloda veya volume'da ne tutulduğu kullanılan sürümde doğrulanmalıdır. Veri envanteri backup ve retention planıyla ilişkilendirilmelidir.

Prompt ve Conversation Verileri

Kullanıcı prompt'ları kişisel veya ticari hassas bilgi içerebilir. Conversation retention süresi iş ihtiyacına göre sınırlandırılmalıdır. Support ve debug için süresiz saklamak yerine minimizasyon uygulanabilir. Log erişimi role-based olmalıdır. Kullanıcı silme veya veri talepleri için operasyon süreci hazırlanmalıdır.

Knowledge Base Belgeleri

Knowledge base dokümanları şirket içi hassas bilgi içerebilir. Belge access group ve owner bilgisi tutulmalıdır. Kaynak sistemde silinen belgenin Dify index'inden de kaldırılması gerekir. Backup retention daha uzun olabilir ve unutulmamalıdır. Kullanıcı yetkisi olmayan chunk modele gönderilmemelidir.

API Provider'a Giden Veriler

Cloud model kullanıldığında prompt ve RAG context provider API'sine gönderilebilir. Bu veri akışı security ve privacy review kapsamında değerlendirilmelidir. Provider contract ve retention politikası incelenmelidir. Hassas field'lar prompt öncesi maskelenebilir. Hangi workflow'un hangi sağlayıcıyı kullandığı merkezi inventory'de tutulmalıdır.

Local LLM ile Veri Çıkışını Azaltmak

Local model prompt ve context'in kurum altyapısında kalmasını sağlayabilir. Bununla birlikte embedding veya reranker cloud kullanıyorsa veri yine dışarı çıkabilir. Workflow içindeki HTTP tool da harici aktarım yapabilir. Bu nedenle yalnızca chat modelin local olması yeterli değildir. Tüm node zinciri veri flow analiziyle incelenmelidir.

Veri Minimizasyonu

Model görevini yapabilmek için gerekmeyen veri prompt'a eklenmemelidir. CRM response içinden yalnızca gerekli alanlar seçilebilir. Conversation history belirli pencereyle sınırlandırılabilir. RAG Top-K gereksiz context'i azaltır. Minimizasyon aynı zamanda token maliyetini de düşürür.

Loglarda Hassas Veri

Debug ve tool logları request body veya kullanıcı girdisini kaydedebilir. Password, API key ve kişisel tanımlayıcılar maskelenmelidir. Log platformuna erişim application kullanıcılarından daha sınırlı olmalıdır. Retention süresi belirlenmelidir. Security incident dışında gereksiz full prompt logging'den kaçınılabilir.

Retention Politikası

Her veri türü için saklama süresi aynı olmak zorunda değildir. Conversation birkaç ay, security log daha uzun veya daha kısa tutulabilir. İş ve yasal gereksinim birlikte değerlendirilmelidir. Süre dolduğunda otomatik deletion mümkünse uygulanır. Backup kopyalarındaki retention da politikaya dahil edilmelidir.

Kullanıcı Erişim Kontrolü

Administrator, developer ve son kullanıcı rolleri ayrılmalıdır. Knowledge base access kullanıcının görevine göre sınırlandırılmalıdır. Shared admin account kullanılmamalıdır. Access review düzenli yapılmalıdır. Çalışan ayrıldığında hesabın kapatılması identity lifecycle sürecine bağlanmalıdır.

Open Source ve İşbirliği ile Dify Geliştirme

Dify açık kaynak ekosistemi sayesinde yalnızca kullanıcı değil katkı sağlayan geliştirici olarak da öğrenilebilir. Repository kodunu incelemek platform mimarisini anlamanın etkili yollarından biridir. Issue ve pull request süreçleri gerçek yazılım geliştirme pratiği kazandırır. Plugin geliştirmek ise Dify ile Python, API ve model entegrasyon bilgisini bir araya getirir. Topluluk projeleri için https://www.diyarbakiryazilim.com.tr/projects adresindeki çalışmaları da inceleyebilirsiniz.

Dify'ın Açık Kaynak Ekosistemi

Dify kaynak kodu ve geliştirme süreci açık repository üzerinden takip edilebilir. Yeni release ve issue'lar platformun hangi yönde geliştiğini gösterir. Katkı yapmadan önce contribution guide okunmalıdır. Küçük dokümantasyon düzeltmeleri bile iyi başlangıçtır. Açık kaynak çalışma code review kültürü kazandırır.

GitHub Repository'sini İncelemek

Repository klasör yapısını incelemek web, API ve Docker mimarisini anlamaya yardımcı olur. Compose dosyaları gerçek production servis ilişkilerini gösterir. Issue geçmişi yaygın problemler hakkında fikir verir. Kod kopyalamadan önce license ve contribution kuralları okunmalıdır. Kullandığınız release tag üzerinden inceleme yapmak main branch farklarını azaltır.

Issue Açmak

Tekrarlanabilir bug bulduğunuzda açık ve net issue oluşturabilirsiniz. Dify sürümü, deployment yöntemi ve hata logu paylaşılmalıdır. Secret ve şirket verisi logdan temizlenmelidir. Sorunun nasıl tekrarlandığı adım adım anlatılır. Daha önce aynı issue açılmış mı aramak faydalıdır.

Pull Request Göndermek

Pull request belirli issue veya geliştirmeyi kod değişikliğiyle önerir. Değişiklik küçük ve odaklı tutulursa review kolaylaşır. Test ve açıklama eklenmelidir. Projenin style ve contribution kurallarına uyulmalıdır. Review yorumları öğrenme sürecinin parçasıdır.

Dify Plugin Geliştirmek

Plugin geliştirmek platformu fork etmeden yeni entegrasyon eklemenizi sağlar. Model, tool veya trigger plugin senaryosu seçilebilir. SDK ve manifest yapısı güncel dokümantasyondan öğrenilmelidir. Secret ve network izinleri minimum tutulmalıdır. Plugin test ve release süreci Git üzerinden yönetilebilir.

Tool Plugin Paylaşmak

Genel fayda sağlayan tool plugin açık kaynak olarak paylaşılabilir. README kullanım ve permission bilgisini açıkça anlatmalıdır. Gerçek API credential örneğe eklenmemelidir. Input validation ve error handling test edilmelidir. Kullanıcıların farklı Dify sürümlerindeki uyumluluk bilgisi belirtilmelidir.

Model Provider Plugin Geliştirmek

Yeni inference servisi Dify'a model provider plugin ile bağlanabilir. Authentication, model listesi ve streaming behavior implement edilir. Chat ve embedding özellikleri ayrı değerlendirilebilir. Provider hataları kullanıcıya güvenli mesaj olarak iletilmelidir. Integration test gerçek veya mock endpoint üzerinde çalıştırılabilir.

Trigger Plugin Geliştirmek

Trigger plugin event kaynağından workflow başlatabilir. Signature verification ve replay koruması önemlidir. Payload schema açıkça tanımlanmalıdır. Duplicate event idempotent işlenmelidir. Production secret management plugin tasarımına dahil edilmelidir.

Açık Kaynak Workflow Şablonları Paylaşmak

Genel kullanım için Dify workflow DSL şablonları paylaşılabilir. Örnekler gerçek şirket verisi veya key içermemelidir. README input ve output yapısını açıklamalıdır. Test dataset veya demo document eklemek öğrenmeyi kolaylaştırır. Pull request üzerinden topluluk iyileştirmeleri alınabilir.

Dify Geliştiricisi Olmak İçin En İyi Programlama Dili Hangisi?

Dify geliştiricisi olmak için tek bir programlama dili zorunlu değildir. Python API ve AI entegrasyonu için, JavaScript ve TypeScript web uygulamaları için, Bash sistem işleri için, SQL veri katmanı için değer taşır. YAML ve Docker Compose ise self-hosted deployment çalışmalarında günlük olarak karşınıza çıkar. Dil seçimini öğrenme hedefinize göre yapmalısınız. Ben yeni başlayanlara önce Python ve Linux temeli, ardından JavaScript veya TypeScript ve Docker eklemelerini öneriyorum.

Python

Python AI ve backend entegrasyonlarında geniş ekosisteme sahiptir. Dify API çağıran servisler veya plugin geliştirmede kullanılabilir. JSON ve HTTP işlemleri kolaydır. RAG evaluation ve data processing script'leri için de uygundur. Network ve secret güvenliği kod geliştirmede unutulmamalıdır.

JavaScript ve TypeScript

Web frontend ve Node.js backend geliştirmede JavaScript veya TypeScript önemlidir. Dify API'yi şirket web uygulamasına entegre edebilirsiniz. TypeScript API contract hatalarını erken yakalamaya yardımcı olur. Streaming response browser ve server tarafında işlenebilir. API key hiçbir zaman frontend bundle içine eklenmemelidir.

Bash

Bash Ubuntu sunucu yönetiminde hızlı otomasyon sağlar. Backup script, health check veya deployment yardımcı işleri yapılabilir. Karmaşık business logic Bash içine taşınmamalıdır. Error handling açık şekilde yazılmalıdır. Script'ler Git üzerinden version control altında tutulmalıdır.

SQL

SQL veri modeli ve raporlama mantığını anlamayı sağlar. Dify'ın internal database'ine doğrudan yazma yapmak desteklenmeyen riskli yöntem olabilir. Bunun yerine resmi API veya migration mekanizması kullanılmalıdır. Şirket tool'ları için read-only sorgu servisleri geliştirilebilir. SQL injection koruması backend sorumluluğudur.

YAML ve Docker Compose

Docker Compose configuration YAML formatında tutulur. Indentation hataları deployment problemlerine yol açabilir. Environment variable interpolation mantığını öğrenmek faydalıdır. `docker compose config` final birleşik yapıyı gösterir. Configuration dosyaları Git üzerinde review edilebilir.

Programlama Dilinden Daha Önemli Olan Sistem Bilgisi

Dify self-hosting yapan geliştiricinin HTTP, DNS, TLS, Linux, Docker ve network mantığını anlaması büyük avantajdır. Uygulama açılmadığında sorun her zaman Python kodunda değildir. 502, certificate ve container network sorunları sistem bilgisi gerektirir. Database backup ve restore da production sorumluluğudur. Programlama ile sistem bilgisini birlikte geliştirmek sizi daha güçlü Dify geliştiricisi yapar.

Yazılımcı Olmak İçin Ne Yapmalı? Dify ve AI Orkestrasyonu Yol Haritası

Dify öğrenmek iyi bir hedef olabilir, fakat arkasındaki temel kavramları öğrenmek daha kalıcı beceri kazandırır. Linux, Git, Docker, HTTP ve Python ilk katmanı oluşturur. Ardından LLM, prompt, RAG ve workflow konularına geçilebilir. Agent ve production deployment daha sonra öğrenildiğinde kavramlar çok daha anlamlı hâle gelir. Her adımda küçük çalışan proje yapmak sadece video izlemekten daha hızlı ilerleme sağlar.

Linux Temelleri

Dosya sistemi, process, permission ve service yönetimini öğrenin. `systemctl`, `journalctl`, `ss` ve temel shell komutları günlük işte kullanılır. User ve group permission mantığı security için önemlidir. Paket yönetimini öğrenin. Küçük Ubuntu VM üzerinde düzenli pratik yapın.

Ubuntu Sunucu Yönetimi

SSH, UFW, kullanıcı yönetimi ve update süreçlerini öğrenin. Nginx kurup basit web servisi yayınlayın. Let's Encrypt ile HTTPS ekleyin. Backup ve restore deneyin. Bu bilgiler Dify kurulumunu çok daha anlaşılır hâle getirir.

Git

Clone, branch, commit ve pull request mantığını öğrenin. Dify repository ve workflow DSL bu beceriden faydalanır. Merge conflict çözme pratiği yapın. Secret'ları repository'ye göndermemeyi öğrenin. Küçük projelerinizi Git üzerinde düzenli tutun.

Docker

Image, container, volume ve network kavramlarını öğrenin. Basit Nginx ve PostgreSQL container çalıştırın. Container içinden başka servise bağlantı test edin. Log ve resource kullanımını inceleyin. Dify architecture bu temeller üzerinde çok daha kolay anlaşılır.

Docker Compose

Birden fazla servisi tek YAML içinde tanımlamayı öğrenin. Environment, volume ve network yapısını kullanın. `docker compose up`, `ps` ve `logs` komutlarında rahat olun. Healthcheck ve restart policy deneyin. Küçük çok servisli lab oluşturun.

HTTP ve REST API

GET, POST, header ve status code kavramlarını öğrenin. `curl` ile API çağrısı yapın. Bearer token ve JSON body kullanın. Timeout ve error handling mantığını anlayın. Dify workflow ve tool entegrasyonlarının büyük kısmı bu temele dayanır.

Python

Temel syntax, function ve data structure öğrenin. `requests` veya benzeri HTTP client kullanın. JSON parse eden küçük script geliştirin. Dify API'ye istek atan backend yazın. Error handling ve environment secret kullanımına dikkat edin.

JavaScript veya TypeScript

Dify API kullanan web uygulaması geliştirmek için faydalıdır. Fetch, async ve streaming mantığını öğrenin. TypeScript ile API response tiplerini tanımlayın. Backend ve frontend ayrımını anlayın. API key'i browser'a koymamayı alışkanlık hâline getirin.

LLM Temelleri

Token, context window, temperature ve model latency kavramlarını öğrenin. Modelin deterministik database gibi davranmadığını anlayın. Farklı modelleri aynı görev üzerinde test edin. Hallucination ve model limitation örneklerini inceleyin. Güvenlik kararını modele bırakmamanız gerektiğini pratikte görün.

Prompt Engineering

Açık görev, context ve output formatı yazmayı öğrenin. System instruction ile user input ayrımını anlayın. Structured output deneyin. Prompt injection testleri yapın. Prompt değişikliklerini regression dataset ile karşılaştırın.

RAG

Embedding, chunking ve vector search temellerini öğrenin. Küçük bir doküman koleksiyonu oluşturun. Retrieval sonuçlarını LLM cevabından bağımsız inceleyin. Top-K ve threshold deneyin. Kendi test sorularınızı hazırlayın.

AI Workflow

Bir görevi küçük adımlara ayırmayı öğrenin. Classification, retrieval, tool ve output node'ları birlikte kullanın. Deterministik işleri code veya template'e taşıyın. Hata branch'i ekleyin. Run log üzerinden workflow'u optimize edin.

Agent ve Tool Calling

Önce read-only tool ile agent geliştirin. Maximum iteration kullanın. Tool schema ve input validation uygulayın. Prompt injection örneklerini test edin. Yazma yetkisi eklemeden önce human approval tasarlayın.

Production AI Deployment

HTTPS, secret management, backup ve monitoring öğrenme yolunun son aşamalarındandır. Dev, staging ve production ortamlarını ayırın. Regression test olmadan model değişikliği yapmayın. Cost monitoring ekleyin. Restore ve rollback tatbikatı yapın.

Diyarbakır Yazılım Topluluğu ile Dify ve Yapay Zeka Orkestrasyonu

Dify ve self-hosted AI konuları bireysel çalışılabildiği gibi topluluk projeleriyle çok daha hızlı öğrenilebilir. Ubuntu, Docker, RAG, workflow ve agent gibi alanlar farklı becerileri bir araya getirir. Bir kişi Linux tarafına, başka biri frontend veya Python entegrasyonuna odaklanabilir. Ortak Git repository, code review ve demo günleri teknik öğrenmeyi daha kalıcı hâle getirir. Diyarbakır Yazılım Topluluğu hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz.

Diyarbakır Yazılım Topluluğu İçinde Self-Hosted AI Çalışmaları

Topluluk içinde küçük bir Ubuntu sunucuda Dify lab kurulabilir. Katılımcılar kurulum, SSL, model entegrasyonu ve workflow görevlerini paylaşabilir. Gerçek müşteri verisi yerine demo dataset kullanılmalıdır. Her değişiklik Git issue üzerinden takip edilebilir. Proje sonunda architecture ve öğrenilen sorunlar dokümante edilebilir.

Ubuntu ve Docker Workshopları

Workshop önce SSH ve UFW temelinden başlayabilir. Ardından Docker Engine ve Compose kurulumu yapılabilir. Katılımcılar Dify stack içindeki container'ları inceleyebilir. `docker compose logs` ve `docker stats` uygulamalı gösterilebilir. Son bölümde domain ve HTTPS kurulumu yapılabilir.

Dify Workflow Atölyeleri

Katılımcılara aynı business problemi verilip farklı workflow tasarımları oluşturulabilir. Classifier, If/Else ve HTTP node birlikte kullanılabilir. Token maliyeti ve latency karşılaştırılır. En sade çalışan tasarım tartışılır. Workflow DSL Git üzerinden paylaşılabilir.

RAG Projeleri

Türkçe açık doküman setiyle knowledge base hazırlanabilir. Farklı chunk ve embedding ayarları karşılaştırılabilir. Retrieval test seti oluşturulur. Sonuçlar tablo hâlinde raporlanır. Böyle bir proje gerçek RAG mühendisliği mantığını öğretir.

AI Agent Projeleri

Agent projesinde önce güvenli read-only tool seçilebilir. Örneğin açık veri API'sinden bilgi çekilebilir. Maximum iteration ve fallback uygulanır. Prompt injection testleri yapılır. Sonuçlar task success ve tool success metrikleriyle değerlendirilir.

Open Source ve İşbirliği Çalışmaları

Dify plugin veya workflow template geliştirilebilir. Issue ve pull request süreçleri topluluk içinde öğretilebilir. Kod review etkinliği düzenlenebilir. Dokümantasyon katkıları da proje parçası sayılmalıdır. Çalışmalar https://www.diyarbakiryazilim.com.tr/projects üzerinden paylaşılabilecek proje fikirlerine dönüştürülebilir.

Diyarbakır'daki En İyi Yazılımcılarla Bilgi Paylaşımı

Teknik gelişim yalnızca bireysel yetenek yarışı değildir. Deneyimli ve yeni başlayan geliştiricilerin aynı proje üzerinde çalışması çok daha değerli öğrenme sağlar. Linux bilen kişi Docker tarafını anlatırken frontend geliştirici API entegrasyonunu üstlenebilir. Code review iki tarafın da yeni şey öğrenmesini sağlar. Topluluk ortamında bilgi paylaşımını düzenli hâle getirmek uzun vadede şehirdeki teknik üretimi güçlendirebilir.

Yerel İşletmelere Yönelik Dify Projeleri

Yerel işletmeler için Dify projeleri gerçek iş ihtiyacına odaklanmalıdır. Sadece chatbot yapmak yerine zaman kaybettiren bilgi ve doküman süreçleri analiz edilebilir. Veri güvenliği ve kullanıcı yetkisi proje başlangıcında değerlendirilmelidir. Küçük pilot ile gerçek fayda ölçülebilir. Başarılı olduğunda workflow aşamalı biçimde genişletilebilir.

Şirket İçi Bilgi Asistanı

Şirket dokümanları RAG knowledge base'e bağlanabilir. Çalışanlar prosedür ve ürün bilgisi sorabilir. Departman bazlı erişim uygulanmalıdır. Kaynak gösterimi kullanıcı güvenini artırır. Eski dokümanların otomatik temizlenmesi gerekir.

Müşteri Destek Asistanı

Destek dokümanları ve sık sorulan sorular knowledge base'e eklenebilir. Agent müşteri hesabı için read-only tool kullanabilir. Cevap taslağı insan temsilciye sunulabilir. Otomatik gönderim ilk aşamada zorunlu değildir. Başarı çözüm süresi ve doğrulukla ölçülebilir.

Satış Agent'ı

Satış agent'ı CRM'den müşteri ve ürün bilgisi okuyabilir. Lead özeti veya görüşme hazırlığı oluşturabilir. CRM write yetkisi ilk aşamada kapalı tutulabilir. Fiyat ve teklif gibi kritik bilgi şirket API'sinden doğrulanmalıdır. Agent output satış temsilcisi onayından geçebilir.

Doküman Analiz Workflow'u

Yeni belge upload edildiğinde içerik sınıflandırılabilir. Önemli alanlar structured JSON olarak çıkarılabilir. Belirsiz değerler human review'a gönderilir. Sonuç şirket sistemine API üzerinden kaydedilebilir. Dosya ve output retention politikası belirlenmelidir.

Uçtan Uca Örnek Proje: Ubuntu Üzerinde Şirket İçi AI Asistanı

Uçtan uca örnek projede Ubuntu sunucu güvenli hâle getirilir ve Docker kurulur. Dify stabil release Docker Compose ile başlatılır. Domain ve HTTPS yapılandırılır, ardından local Ollama veya cloud model provider eklenir. Şirket dokümanları knowledge base'e alınır ve RAG workflow oluşturulur. API yayınlama, monitoring, backup ve production testleri tamamlandıktan sonra gerçek kullanıcı pilotuna geçilir.

Ubuntu Sunucuyu Hazırlama

Güncel LTS kurulumu seçilir. SSH key authentication etkinleştirilir. Root login ve gereksiz servisler kapatılır. UFW yalnızca gerekli portları açar. NTP ve hostname doğrulanır.

Docker Kurulumu

Resmî Docker repository eklenir. Engine ve Compose plugin yüklenir. `docker compose version` kontrol edilir. Basit test container çalıştırılır. Docker group erişimi sadece gerekli yöneticiye verilir.

Dify Kurulumu

Repository klonlanır ve stabil release tag seçilir. `docker` dizininde `.env.example` dosyası kopyalanır. Secret ve URL ayarları düzenlenir. `docker compose up -d` çalıştırılır. Container ve log durumu doğrulanır.

Domain ve SSL

DNS A kaydı sunucu IP'sine yönlendirilir. Host Nginx reverse proxy kurulur. Let's Encrypt sertifikası alınır. HTTP trafiği HTTPS'e yönlendirilir. Yenileme dry-run ile test edilir.

Ollama veya Cloud Model Bağlama

Veri ve kalite gereksinimine göre model kaynağı seçilir. Ollama private network üzerinden bağlanabilir. Cloud provider key'i secret olarak tutulur. Chat ve embedding modeli ayrı test edilir. Latency ve maliyet baseline'ı alınır.

Knowledge Base Oluşturma

İlk olarak küçük ve temiz doküman seti seçilir. Chunk ve embedding ayarları belirlenir. Metadata departman ve belge türünü içerir. Retrieval test seti oluşturulur. Kalite yeterli olmadan tüm şirket dokümanı eklenmez.

Workflow Oluşturma

User Input ile başlayan basit flow hazırlanır. Soru sınıflandırılır. Bilgi soruları RAG branch'ine gider. API işlemi gerekiyorsa ayrı tool branch'i kullanılır. Final output template ile standardize edilir.

RAG Node'u

Knowledge Retrieval doğru knowledge base'e bağlanır. Top-K ve threshold benchmark ile ayarlanır. User role metadata filter olarak kullanılabilir. Sonuç yoksa fallback branch çalışır. Source metadata final cevaba eklenebilir.

LLM Node'u

LLM yalnızca gerekli context'i alır. Sistem prompt'u kaynak dışı iddia üretmemesini ister. Output token limiti belirlenir. Structured format gerekiyorsa schema kullanılır. Token ve latency izlenir.

Tool Entegrasyonu

Şirket API'si read-only tool olarak eklenir. Credential backend'de tutulur. User authorization API tarafından doğrulanır. Tool input validation yapılır. Yazma yetkisi ilerleyen aşamada approval ile eklenir.

Human Approval

Tool sistem durumunu değiştirecekse kullanıcı onayı istenir. Değişiklik özeti gösterilir. Onay run ID ile loglanır. Reject seçeneği bulunur. Timeout olduğunda işlem otomatik iptal edilir.

API ile Yayınlama

Workflow production API olarak publish edilir. API key backend secret store'da tutulur. Şirket web uygulaması kendi backend'i üzerinden çağrı yapar. User ID güvenilir auth session'dan gelir. Rate limit uygulanır.

Monitoring

Container, CPU, RAM ve disk monitoring'e eklenir. API error rate ve latency izlenir. Workflow token ve tool success metric'leri toplanır. Backup job failure alarm üretir. Kritik hatalar ekip bildirim kanalına gönderilir.

Backup

PostgreSQL günlük backup alır. Upload storage ayrıca yedeklenir. Workflow DSL Git üzerinde tutulur. Harici backup storage kullanılır. Belirli aralıklarla test sunucusunda restore yapılır.

Production Testi

Pilot kullanıcılarla gerçek soru seti test edilir. Yetkisiz bilgi erişimi negative test ile kontrol edilir. Prompt injection ve tool abuse senaryoları denenir. P95 latency ve task success ölçülür. Kritik hata oranı kabul edilebilir seviyeye gelmeden genel kullanıma açılmaz.

Production Öncesi Son Kontrol Listesi

Production'a geçmeden önce yalnızca Dify ekranının açıldığını kontrol etmek yeterli değildir. Sürüm, backup, SSL, firewall, secret, workflow testleri, RAG kalitesi ve agent yetkileri birlikte gözden geçirilmelidir. Rate limit ve monitoring aktif olmalıdır. Rollback planının kim tarafından uygulanacağı bilinmelidir. Bu kontrol listesini deployment ticket içinde zorunlu alan hâline getirmek süreç disiplinini artırır.

Stable Dify Sürümü Sabitlendi mi?

Production deployment belirli release tag kullanmalıdır. Main branch veya değişken latest etiketi kullanılmamalıdır. Sürüm Git ve change kaydında bulunmalıdır. Image digest gerekiyorsa saklanabilir. Staging aynı release'i test etmiş olmalıdır.

Backup Alındı mı?

Update veya ilk production geçiş öncesi database ve storage backup alınmalıdır. Backup harici depoda olmalıdır. Dosya bütünlüğü kontrol edilmelidir. Job logu saklanmalıdır. Recovery için hangi backup kullanılacağı bilinmelidir.

Restore Test Edildi mi?

En az bir test environment restore yapılmalıdır. PostgreSQL ve dosyalar birlikte doğrulanmalıdır. Knowledge retrieval test edilmelidir. Workflow'lar çalıştırılmalıdır. DR runbook sonuçlara göre güncellenmelidir.

HTTPS Aktif mi?

Production domain geçerli TLS sertifikası kullanmalıdır. HTTP redirect çalışmalıdır. Certificate renewal test edilmelidir. TLS hostname hatası olmamalıdır. API client da HTTPS endpoint kullanmalıdır.

Firewall Doğru mu?

Public yalnızca gerekli portlar açık olmalıdır. Database ve Redis kapalı tutulmalıdır. SSH erişimi sınırlandırılmalıdır. Cloud ve host firewall policy karşılaştırılmalıdır. Dış tarama ile doğrulama yapılmalıdır.

Secret'lar Güvenli mi?

Default parolalar değiştirilmiş olmalıdır. `.env` permission sınırlandırılmalıdır. API key'ler Git içinde bulunmamalıdır. Secret rotation prosedürü olmalıdır. Production ve staging credential'ları ayrı tutulmalıdır.

Internal Portlar Kapalı mı?

Dify internal service portları public internetten erişilememelidir. Ollama API private network'te kalmalıdır. Docker port binding incelenmelidir. `ss -tulpn` host görünümünü gösterir. External network scan ek doğrulama sağlar.

Workflow Testleri Geçiyor mu?

Happy path ve error path test edilmelidir. API timeout ve boş input senaryoları çalıştırılmalıdır. Prompt injection örnekleri denenmelidir. Regression dataset belirlenen threshold'u geçmelidir. Test sonucu release kaydına eklenmelidir.

RAG Kalitesi Test Edildi mi?

Retrieval doğru kaynakları bulmalıdır. Top-K ve threshold test setiyle ayarlanmalıdır. Yetki filtresi farklı kullanıcılarla denenmelidir. Groundedness ölçülmelidir. Eski veya duplicate belge temizlenmelidir.

Agent Yetkileri Sınırlandırıldı mı?

Agent yalnızca gerekli tool'lara sahip olmalıdır. Read ve write araçları ayrılmalıdır. Kritik write işlemlerinde approval kullanılmalıdır. Maximum iteration ve maliyet limiti olmalıdır. Tool backend authorization kontrolü yapmalıdır.

Rate Limit Var mı?

Public API ve login endpoint için makul limit tanımlanmalıdır. User-based quota uygulanabilir. Burst saldırıları sınırlandırılmalıdır. Limit aşımı loglanmalıdır. Threshold normal kullanım verisiyle doğrulanmalıdır.

Monitoring Aktif mi?

CPU, RAM, disk ve container state izlenmelidir. API latency ve error rate metric olmalıdır. Worker queue alarmı bulunmalıdır. Model cost ve token usage izlenebilir. Monitoring sisteminin kendisi de health kontrolüne sahip olmalıdır.

Loglar Toplanıyor mu?

Nginx ve application logları merkezi platforma gönderilmelidir. Secret masking uygulanmalıdır. Retention policy tanımlanmalıdır. User ID ve run ID correlation mümkün olmalıdır. Log pipeline kesintisi alarm üretmelidir.

Rollback Planı Var mı?

Önceki Dify release ve configuration bilinmelidir. Database migration etkisi değerlendirilmelidir. Rollback komutları runbook içinde bulunmalıdır. Kim karar verecek ve uygulayacak belirlenmelidir. Rollback sonrası smoke test listesi hazır olmalıdır.

Sık Sorulan Sorular

Dify self-hosting, model entegrasyonu ve workflow geliştirme konuları ilk kez başlandığında birçok soruyu beraberinde getirir. En sık sorular kurulum yöntemi, RAM ihtiyacı, domain, SSL, local model ve production uygunluğu etrafında toplanır. Aşağıdaki cevaplar hızlı referans olarak kullanılabilir. Gerçek production environment için kullanılan release'in güncel resmi dokümantasyonu da mutlaka kontrol edilmelidir. Özellikle security ve plugin davranışları sürümler arasında değişebildiği için eski kurulum örneklerini doğrudan kopyalamamak gerekir.

Dify nedir?

Dify LLM tabanlı uygulamalar geliştirmek için kullanılan açık kaynaklı AI orchestration platformudur. Workflow, RAG, agent ve model management özelliklerini bir arada sunar. Cloud veya self-hosted kullanılabilir. API üzerinden mevcut uygulamalara bağlanabilir. Low-code arayüz sunmasına rağmen production işletiminde sistem bilgisi önemlidir.

Dify ücretsiz mi?

Dify açık kaynak self-hosted sürümüyle kendi altyapınızda çalıştırılabilir. Bununla birlikte sunucu ve model API kullanımı kendi maliyetlerinizi oluşturur. Cloud hizmetinin plan ve fiyatları zaman içinde değişebilir. Plugin veya harici model servislerinin ayrıca ücreti olabilir. Güncel lisans ve plan bilgisi resmi Dify kaynaklarından doğrulanmalıdır.

Dify Ubuntu'ya nasıl kurulur?

En yaygın yöntem Docker Engine ve Docker Compose kullanmaktır. Dify repository klonlanır ve `docker` dizinine geçilir. `.env.example` dosyası `.env` olarak kopyalanır. Environment değerleri düzenlenir ve `docker compose up -d` çalıştırılır. Production'da ardından domain, HTTPS, firewall ve backup ayarları yapılmalıdır.

Dify için minimum RAM ne kadar?

Resmî hızlı başlangıç gereksinimi en az 4 GiB RAM seviyesindedir. Bu değer küçük test ortamı için başlangıç noktası olarak görülmelidir. Production kullanımında PostgreSQL, Redis, vector store ve worker daha fazla bellek gerektirebilir. Local LLM aynı sunucuda çalışacaksa RAM ihtiyacı çok daha yüksektir. Gerçek boyutlandırma load test ve monitoring verisine göre yapılmalıdır.

Dify Docker olmadan kurulabilir mi?

Dify kaynak koddan çalıştırılabilir, ancak self-hosting için en kolay yöntem Docker Compose'tur. Kaynaktan kurulum daha fazla dependency ve development bilgisi gerektirir. Production operasyonunda container yöntemi tekrar üretilebilirlik sağlar. Özel geliştirme yapan ekipler source deployment tercih edebilir. Kullanım yöntemine göre resmi Dify dokümantasyonu takip edilmelidir.

Dify için domain gerekli mi?

Local test için domain zorunlu değildir. IP veya localhost üzerinden kurulum yapılabilir. Production kullanıcı erişiminde domain HTTPS ve API yönetimini kolaylaştırır. Reverse proxy ve certificate configuration daha temiz olur. Şirket içi sadece VPN erişiminde de internal DNS domain kullanılabilir.

Dify'a SSL nasıl eklenir?

Nginx reverse proxy ve Let's Encrypt Certbot yaygın yöntemdir. DNS domain'i sunucuya yönlendirilir. Sertifika alınır ve HTTPS server block yapılandırılır. HTTP trafiği HTTPS'e yönlendirilir. Renewal dry-run ile test edilmelidir.

Dify Ollama ile çalışır mı?

Evet, Dify Ollama üzerinden local modellerle çalışabilir. Ollama endpoint Dify container'ından erişilebilir olmalıdır. Model provider configuration içinde endpoint ve model adı tanımlanır. Network ve firewall ayarları private erişim sağlayacak şekilde yapılmalıdır. Model latency ve hardware kapasitesi production öncesi test edilmelidir.

Dify local LLM çalıştırabilir mi?

Dify model orchestration yapar, local model inference ise Ollama veya başka inference servisi tarafından sağlanabilir. Dify bu endpoint'e bağlanır. Model aynı veya ayrı sunucuda çalışabilir. GPU ve VRAM ihtiyacı model boyutuna göre değişir. Büyük kullanımda inference katmanını Dify host'tan ayırmak daha ölçeklenebilir olabilir.

Dify Workflow nedir?

Workflow AI ve business adımlarının node tabanlı görsel akışıdır. LLM, retrieval, HTTP, code ve condition node'ları kullanılabilir. Input node'lardan geçerek output'a ulaşır. Test run ve run log debugging sağlar. Deterministik süreçlerde agent'a göre daha kontrollü yapı sunar.

Dify Agent nedir?

Agent modele belirli araçları seçerek hedefe ulaşma esnekliği veren uygulama yapısıdır. Tool sonucu üzerinden yeni karar verebilir. Function calling veya başka strategy kullanılabilir. Maximum iteration ve permission limiti önemlidir. Kritik tool işlemleri insan onayı gerektirebilir.

Dify Workflow ile Agent arasındaki fark nedir?

Workflow adımların büyük kısmını önceden belirler. Agent ise bazı adımları model kararına bırakır. Öngörülebilir business process için workflow daha uygundur. Araştırma ve esnek tool kullanımı için agent faydalı olabilir. Bir workflow içinde sınırlı agent kullanımı hibrit yaklaşım sağlar.

Dify RAG destekliyor mu?

Evet, Dify Knowledge Base ve retrieval bileşenleriyle RAG uygulamaları geliştirebilir. Dokümanlar chunk edilir ve embedding oluşturulur. Sorguda ilgili chunk'lar bulunur. Reranking ve retrieval ayarları kaliteyi etkiler. Production RAG için retrieval test seti oluşturmak önemlidir.

Dify MCP ile kullanılabilir mi?

Dify ekosistemindeki MCP entegrasyonları üzerinden MCP araçları kullanılabilir. Özellik kapsamı Dify sürümüne göre değişebileceği için güncel dokümantasyon kontrol edilmelidir. MCP server güvenilir kaynak olmalıdır. Tool permission minimum tutulmalıdır. Critical write işlemleri approval gerektirebilir.

Dify n8n ile birlikte kullanılabilir mi?

Evet, iki platform REST API veya webhook üzerinden birlikte çalışabilir. Dify AI reasoning ve RAG katmanı olabilir. n8n genel business automation akışını yönetebilir. API key güvenli credential store'da tutulmalıdır. Correlation ID iki sistemde ortak loglanırsa troubleshooting kolaylaşır.

Dify API olarak kullanılabilir mi?

Dify uygulamaları API üzerinden mevcut backend sistemlerine bağlanabilir. Workflow veya chat uygulaması REST endpoint olarak çağrılabilir. API key frontend'de tutulmamalıdır. Backend proxy user authorization ve rate limit uygular. Streaming ve blocking response kullanım senaryosuna göre seçilebilir.

Dify production için uygun mu?

Dify production kullanımına taşınabilir, ancak sadece Docker container'larını çalıştırmak yeterli değildir. Stable release, HTTPS, backup, monitoring ve security management gerekir. Dev ve staging ortamları önerilir. Tool ve plugin access review yapılmalıdır. Kullanım arttığında database ve worker scaling planı oluşturulmalıdır.

Dify nasıl yedeklenir?

PostgreSQL, file storage ve vector store yedekleme planına alınmalıdır. `.env` ve plugin configuration ayrıca korunmalıdır. Workflow DSL Git repository'de tutulabilir. Yedekler harici storage'a gönderilmelidir. Düzenli restore testleri yapılmalıdır.

Dify nasıl güncellenir?

Yeni stabil sürüm önce release notes üzerinden incelenir. Backup alınır ve staging update yapılır. Workflow ve plugin testleri çalıştırılır. Production bakım penceresinde güncellenir. Smoke test başarısızsa rollback planı uygulanır.

Dify için en iyi programlama dili hangisidir?

Tek bir dil yoktur. Python AI ve backend entegrasyonlarında güçlü başlangıçtır. TypeScript web uygulaması ve API client için değerlidir. Bash, SQL ve YAML production işletiminde sık kullanılır. En önemli temel Linux, HTTP, Docker ve güvenlik bilgisidir.

Dify öğrenmek için yazılımcı olmak gerekir mi?

Dify low-code arayüzü sayesinde programlama bilmeden temel workflow oluşturmak mümkündür. Ancak API, security ve production deployment için teknik bilgi gerekir. Linux ve Docker temeli büyük avantaj sağlar. Kod yazmayı öğrenmek custom integration seçeneklerini artırır. En iyi yöntem küçük proje üzerinden aşamalı öğrenmektir.

Open source ve işbirliği Dify öğrenmeye nasıl katkı sağlar?

Kaynak kod ve issue'ları incelemek gerçek architecture hakkında bilgi verir. Topluluk içinde workflow ve plugin geliştirmek pratik kazandırır. Pull request review farklı yaklaşımları görmenizi sağlar. Açık örnek projeler kendi lab ortamınızda tekrar uygulanabilir. İşbirliği sadece kod değil dokümantasyon ve test becerisini de geliştirir.

Ubuntu Sunucularda Dify Kurulumu Hakkında Sık Sorulan Sorular

Ubuntu Sunucularda Dify Kurulumu ve Yapay Zeka Orkestrasyonu konusunda production'a yaklaşırken sorular daha çok güvenlik, güncelleme ve entegrasyon tarafında yoğunlaşır. Dify Docker Compose ile Ubuntu kurulumu ve yapılandırması hızlı başlayabilir, fakat güvenli işletim daha kapsamlıdır. Ollama, cloud API, SSL ve backup birlikte düşünülmelidir. Kurumsal ekipler için model ve workflow kadar veri akışını belgelemek de önemlidir. Aşağıdaki cevaplar sahada en sık karşılaştığım uygulama sorularını özetler.

Ubuntu sunucularda Dify kurulumu nasıl yapılır?

Önce desteklenen Ubuntu LTS sunucu hazırlanır ve SSH erişimi key tabanlı hâle getirilir. Docker Engine ile güncel Docker Compose plugin kurulur. Dify repository içinden stabil release seçilir, `docker` dizinindeki `.env.example` dosyası `.env` olarak kopyalanır ve production secret'ları düzenlenir. `docker compose up -d` sonrasında container durumları ve loglar doğrulanır. Son aşamada domain, Nginx, HTTPS, firewall, backup ve monitoring yapılandırılarak sistem production kullanımına hazırlanır.

Dify Docker Compose ile Ubuntu sunucuda nasıl yapılandırılır ve güncellenir?

Dify Docker Compose ile Ubuntu kurulumu ve yapılandırması için Compose dosyaları ve environment ayarları aynı release ile birlikte yönetilmelidir. Production'da `latest` yerine belirli release tag kullanmak daha kontrollüdür. Güncelleme öncesi release notes okunur, PostgreSQL ve storage backup alınır ve yeni sürüm staging ortamında test edilir. Production update sonrasında container health, workflow, knowledge retrieval ve API smoke testleri çalıştırılır. Sorun görülürse önceden hazırlanmış image, configuration ve database rollback planı uygulanır.

Dify üzerinde OpenAI, Ollama, Llama ve Qwen gibi yapay zeka modelleri nasıl entegre edilip orkestre edilir?

Dify içinde model provider katmanı üzerinden cloud API veya local inference endpoint'i tanımlanabilir. Ollama kullanıldığında Llama veya Qwen ailesindeki desteklenen modeller local sunucuda çalıştırılıp Dify'a private network üzerinden sunulabilir. Chat modeli, embedding modeli ve reranker ayrı seçilebilir. Workflow içinde classifier ve If/Else node ile farklı görevleri farklı modellere yönlendirmek mümkündür. Model seçimi yapılırken yalnızca kalite değil latency, token maliyeti, veri gizliliği ve GPU kapasitesi birlikte değerlendirilmelidir.

Şirket içi Dify kurulumunda SSL, kullanıcı yetkilendirmesi, veri güvenliği ve yedekleme nasıl yapılandırılmalıdır?

Dify self-hosted kurulumunda Ollama API SSL veritabanı ve güvenlik ayarları tek security architecture içinde değerlendirilmelidir. Public erişimde HTTPS zorunlu tutulmalı, PostgreSQL ve Redis internetten kapalı olmalıdır. Administrator erişimi VPN, IP allowlist ve güçlü kimlik doğrulama ile sınırlandırılabilir. Knowledge base erişimleri kullanıcı veya departman yetkisine göre filtrelenmeli, model API key'leri frontend'e verilmemelidir. PostgreSQL, file storage ve gerekiyorsa vector store düzenli yedeklenmeli ve bu yedekler bağımsız test sunucusunda restore edilerek doğrulanmalıdır.

Ubuntu sunucuda Dify kurulumu ve yapay zeka orkestrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Dify kurulumu ve yapay zeka entegrasyon danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca Dify ekranını kurabilen değil Linux, Docker, güvenlik, RAG ve workflow tarafını birlikte ele alabilen bir yaklaşım aramak faydalıdır. Diyarbakır'da bu konuları uygulamalı proje, workshop ve açık kaynak çalışmaları üzerinden öğrenmek isteyenler Diyarbakır Yazılım Topluluğu'nu takip edebilir. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresini kullanabilirsiniz. Geliştirilen veya geliştirilebilecek topluluk projeleri için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz. Küçük bir Ubuntu ve Dify lab kurup gerçek workflow, RAG ve backup senaryoları üzerinde çalışmak yalnızca teorik eğitim almaktan çok daha hızlı deneyim kazandırır.

Sonuç: Ubuntu Üzerinde Production-Ready Dify Mimarisi

Ubuntu Sunucularda Dify Kurulumu ve Yapay Zeka Orkestrasyonu sürecini başarılı kılan şey tek bir kurulum komutu değildir. Stabil Dify release, Docker Compose, güvenli Ubuntu host, HTTPS, güçlü secret yönetimi, kontrollü model erişimi, ölçülebilir RAG ve sınırlandırılmış agent yetkileri birlikte çalışmalıdır. Production operasyonunda backup, restore testi, monitoring ve workflow evaluation en az model seçimi kadar önem taşır. Sistem kullanımı arttıkça worker, database, vector store ve model inference katmanları ayrı ölçeklenebilir. Başlangıçta sade ama doğru sınırları olan architecture kurmak, daha sonra büyük sistemi yeniden tasarlamak zorunda kalmaktan çok daha kolaydır.

Stabil Sürümle Başlayın

Production ortamında belirli release tag sabitleyin. Main branch'i canlı sistem için varsayılan kaynak yapmayın. Release notes ve security duyurularını takip edin. Staging üzerinde yeni sürümü test edin. Rollback için önceki sürüm bilgisini saklayın.

Docker Compose ile Kontrollü Kurulum Yapın

Resmî Docker Compose configuration başlangıç için en yönetilebilir yöntemlerden biridir. `.env.example` üzerinden kendi environment dosyanızı oluşturun. Default secret'ları değiştirin. Public port mapping'lerini kontrol edin. Compose dosyası ve sürüm bilgisini deployment dokümantasyonunda tutun.

Nginx ve HTTPS ile Güvenli Yayınlayın

Dify internal servisini doğrudan internete açmayın. Nginx reverse proxy üzerinden HTTPS yayın yapın. Sertifika yenilemesini otomatikleştirin. Rate limit ve gerekli proxy header'larını düzenleyin. Admin erişimini mümkünse VPN veya allowlist ile sınırlandırın.

Cloud ve Local Modelleri Gereksinime Göre Orkestre Edin

Her görev için aynı modeli kullanmak zorunda değilsiniz. Hassas veya tekrarlı işler local modelde çalışabilir. Zor reasoning görevleri gerektiğinde cloud model kullanabilir. Routing workflow ile kontrol edilebilir. Kalite, maliyet ve veri çıkışı düzenli ölçülmelidir.

Workflow, RAG ve Agent Katmanlarını Doğru Ayırın

Deterministik business rule için Workflow kullanın. Kurumsal bilgiye ihtiyaç varsa RAG ekleyin. Sadece gerçekten dinamik tool seçimi gereken yerde Agent kullanın. Her şeyi tek agent'a vermek bakım ve güvenlik sorunlarını artırır. Katmanları açık sorumluluklarla ayırmak production davranışını daha anlaşılır hâle getirir.

Tool Yetkilerini Minimumda Tutun

Agent ve workflow tool'ları yalnızca gereken backend işlemlerine erişmelidir. Read ve write yetkileri ayrı tutulmalıdır. Critical write tool insan onayı istemelidir. API credential'ı model tarafından görülmemelidir. Tool usage ve error logları düzenli izlenmelidir.

Backup, Monitoring ve Evals'i Kurulumun Bir Parçası Yapın

Backup'ı proje bittikten sonra eklenen özellik olarak görmeyin. PostgreSQL ve storage ilk production gününden itibaren yedeklenmelidir. Restore testi belirli aralıklarla yapılmalıdır. Workflow quality için regression dataset ve evaluation metrikleri oluşturulmalıdır. Monitoring olmadan kullanıcıların fark ettiği sorunları proaktif şekilde yönetmek mümkün olmaz.

İhtiyaç Arttıkça Tek Sunucudan Ölçeklenebilir Mimarilere Geçin

İlk proje için sade Ubuntu ve Docker Compose kurulumu çoğu zaman yeterlidir. Kullanım büyüdükçe önce gerçek darboğazı ölçün. Database, Redis, worker veya model inference katmanını gerektiğinde ayırın. Yüksek availability ihtiyacı oluştuğunda Kubernetes veya başka orchestration seçeneklerini değerlendirin. Dify, RAG, agent ve self-hosted AI projeleri hakkında toplulukla birlikte üretmek ve yeni projelere katılmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.