Open WebUI ve Ollama ile Kurumsal Yerel AI Arayüzü Kurmak
Yerel model denemeleri komut satırında başarılı olduğunda sıradaki doğal beklenti, çalışanların tarayıcıdan kullanabileceği sade bir arayüz oluyor. Bir pilotta Open WebUI kısa sürede kullanılabilir hale gelmişti; fakat sohbetlerin nerede tutulduğu, modele hangi ağ yolundan erişildiği ve güncellemede verinin korunup korunmayacağı sonradan soruldu. Teknik demo ile kurumsal servis arasındaki fark tam burada ortaya çıktı.
20 Temmuz 2026 tarihinde ele aldığımız mimaride Ollama model çalışma zamanı, Open WebUI kullanıcı katmanı ve Docker işletimi ayrı sorumluluk alanları olarak tasarlandı. Amaç internete açık bir deneme servisi oluşturmak değil; sınırlı kullanıcı grubuna, anonim test verileriyle başlayan ve güvenlik kontrolleri doğrulandıkça gelişen yönetilebilir bir yerel AI platformu kurmaktı.
Sorunun ortaya çıkışı
Windows iş istasyonunda Ollama modelleri çalışıyordu, ancak her kullanıcının komut satırı öğrenmesi ve model adlarını bilmesi beklenemezdi. Merkezi sohbet geçmişi, model seçimi ve belge yükleme gibi ihtiyaçlar doğdu. Docker Desktop üzerinde Open WebUI mantıklı bir arayüz seçeneğiydi. Buna karşın pilotun hangi kullanıcıya, hangi veriye ve hangi hizmet seviyesine sunulacağı tanımlanmadan yalnızca port yayınlamak riskliydi.
İlk tasarım görüşmesinde model sunucusu ile web konteyneri tek uygulama gibi konuşuluyordu. Oysa Ollama ağırlıkları yükleyip çıkarım yaparken Open WebUI kimlik, oturum, sohbet ve kullanıcı deneyimini yönetir. Docker ise paketleme ve çalışma ortamını sağlar. Sorun çıktığında hangi katmanın sorumlu olduğunu ayırabilmek için bile bu mimari sınırların açık yazılması gerekiyordu.
İlk belirtiler ve yanlış varsayımlar
İlk yanlış varsayım, servis yerel bilgisayarda çalıştığı için yalnızca o bilgisayardan erişilebileceğiydi. Konteyner portunun tüm arayüzlere bağlanması veya güvenlik duvarı kuralı, hizmeti beklenenden geniş bir ağa açabilir. İkinci varsayım konteyner silinince yalnızca uygulamanın silineceğiydi; kalıcı volume tanımlanmamışsa kullanıcı ayarları ve sohbet kayıtları da kaybolabilir.
Bağlantı hatalarında da modelin bozuk olduğu düşünüldü. Asıl neden bazen konteyner içindeki “localhost” kavramının ana bilgisayarı değil konteynerin kendisini göstermesiydi. Windows, Docker ağı ve Ollama dinleme ayarı birlikte incelenmeden rastgele adres ve port değişiklikleri yapmak sorunu büyütebilirdi. Model listesi, servis sağlığı ve ağ yolu katman katman doğrulanmalıydı.
Teknik analiz
Akışı tarayıcıdan Open WebUI konteynerine, oradan Ollama API katmanına ve seçili modele kadar izledik. Her adım için dinlenen arayüz, ad çözümleme, güvenlik duvarı ve hata kaydı kontrol edildi. Sohbet verisi ile model dosyalarının aynı yerde tutulmadığı belirlendi. Bu ayrım yedekleme, kapasite ve silme taleplerinin doğru bileşende yönetilmesini sağladı.
Konteyner imajı sürümle sabitlendi, kalıcı veri için isimlendirilmiş volume kullanıldı ve yeniden başlatma davranışı belirlendi. Sağlık kontrolü yalnızca web sayfasının açılmasına değil, arayüzün model kataloğuna ulaşmasına göre düşünüldü. GPU ve RAM tüketimi Open WebUI’dan çok Ollama iş yüküyle ilişkili olduğundan kapasite ölçümleri model, context ve eş zamanlı oturum bazında kaydedildi.
# Örnek yalnızca yerel pilot içindir; güçlü kimlik ve ağ kısıtı ayrıca uygulanmalıdır.
docker volume create open-webui-data
docker run -d --name open-webui
--restart unless-stopped
-p 127.0.0.1:3000:8080
-v open-webui-data:/app/backend/data
ghcr.io/open-webui/open-webui:<onayli-surum>
# İmaj etiketini test edilmiş gerçek sürümle değiştirin; latest kullanmayın.
Uygulanan çözüm veya önerilen mimari
Pilot aşamada arayüz yalnızca ana bilgisayara bağlandı ve küçük bir kullanıcı grubuna kontrollü erişim sağlandı. Kurumsal yaygınlaştırma için TLS sonlandıran ters proxy, merkezi kimlik, rol bazlı model erişimi ve ağ segmentasyonu ayrı katman olarak önerildi. Ollama servisi doğrudan son kullanıcılara yayınlanmadı; yalnızca uygulama katmanının gerekli yoldan erişmesi hedeflendi.
Veri yaşam döngüsü ayrıca tasarlandı. Sohbet geçmişinin varsayılan saklama süresi, kullanıcı silme yöntemi, yönetici erişimi, yedekleme kapsamı ve belge yükleme kuralları açıklandı. Model güncellemesi kalite regresyonu yaratabileceği için onaylı model kataloğu tutuldu. Kullanıcı eğitiminde sistemin sınırları, doğrulama ihtiyacı ve hangi veri sınıflarının isteme yazılamayacağı anlatıldı.
Alternatifler ve karar gerekçesi
Komut satırı en az bileşenli yöntemdir ve teknik kullanıcıların kişisel denemeleri için uygundur; fakat kimlik, kullanım kolaylığı ve ortak yönetişim sınırlıdır. Masaüstü uygulamaları hızlı deneyim sunabilir, ancak merkezi politika ve sürüm yönetimi ürüne göre değişir. Open WebUI seçimi açık bir web katmanı ve çoklu model deneyimi sağladığı için yapıldı; her ortam için tek doğru olduğu iddia edilmedi.
Docker Desktop pilot için hızlı ve taşınabilir oldu. Sürekli, çok kullanıcılı hizmette Linux sunucu veya orkestrasyon platformu daha öngörülebilir işletim sağlayabilir; bunun karşılığında ek uzmanlık ve bakım gerekir. Bulut tabanlı arayüzler ölçek avantajı sunar, fakat veri yerleşimi ve sağlayıcı koşulları farklıdır. Karar, kullanıcı sayısı, veri sınıfı ve destek hedefiyle birlikte verilmelidir.
Güvenlik ve operasyonel riskler
En önemli risk, arayüzün kontrolsüz ağda yayınlanması ve kullanıcıların hassas doküman yüklemesidir. Varsayılan hesaplar kullanılmamalı, kayıt açma politikası sınırlandırılmalı ve yönetici rolleri ayrılmalıdır. Eklenti, araç ve dış web erişimi varsayılan olarak kapalı tutulmalı; etkinleştirilecekse veri çıkışı ile komut yetkileri ayrıca incelenmelidir. İmajlar güvenilir kaynaktan ve sabit sürümle alınmalıdır.
Operasyonda disk büyümesi, eski sohbetler, model indirmeleri ve loglar izlenmelidir. Ana bilgisayar yeniden başladığında servis sırası, Ollama erişimi ve sağlık alarmı test edilmelidir. Yedek yalnızca volume kopyalamak değildir; geri yükleme denenmeli ve kişisel veri saklama kuralları korunmalıdır. Arayüzün açılması hizmetin sağlıklı olduğu anlamına gelmediğinden örnek çıkarım testi izlemeye eklenmelidir.
Çıkarılan Dersler
- Ollama, Open WebUI ve Docker farklı sorumluluklara sahip katmanlardır.
- Port yayınlamak kurumsal erişim mimarisi kurmak anlamına gelmez.
- Kalıcı volume veri kaybını azaltır, fakat güvenli yedek ve saklama politikasının yerini tutmaz.
- Model ve uygulama sürümleri test edilip sabitlenmelidir.
- Yerel AI kullanımında veri sınıflandırması ve kullanıcı eğitimi zorunludur.
Kontrol Listesi
- Ağ erişimi yalnızca gerekli kullanıcı ve bileşenlerle sınırlı mı?
- Kimlik doğrulama, roller ve kayıt politikası tanımlı mı?
- Sohbet verisi için saklama, yedek ve silme yöntemi var mı?
- İmaj ile model güncellemeleri geri dönüş planıyla test ediliyor mu?
- Servis sağlığı uçtan uca çıkarım testiyle izleniyor mu?