Ubuntu 24.04 VPS Üzerinde Komple Self-Hosted AI Stack: Docker + Portainer + Ollama + Open WebUI + n8n A’dan Z’ye Resimli Rehber

Bu pillar rehber, tek bir gerçek Ubuntu VPS üzerinde baştan sona kurduğumuz altyapının tamamını bir araya getirir: Ubuntu 24.04 LTS, Docker Engine + Compose, Portainer, Ollama, qwen3:4b, Open WebUI, n8n, Nginx ve Let’s Encrypt. Uygulama servisleri ayrı Docker containerlarında çalışır ve eka-ai isimli private bridge ağında birbirleriyle konuşur.

Public internete doğrudan yalnız Nginx üzerinden 80/443 açılır. Portainer 9443, Ollama 11434, Open WebUI 3000 ve n8n 5678 host tarafında 127.0.0.1 ile sınırlandırılır. Böylece yönetim ve AI servisleri doğrudan internete açık olmaz; domain bazlı erişim reverse proxy ve TLS üzerinden sağlanır.

Internet :443
  ↓
Nginx + Let's Encrypt
  ├─ portainer.ekasunucu.com → 127.0.0.1:9443
  ├─ openwebui.ekasunucu.com → 127.0.0.1:3000
  └─ n8n.ekasunucu.com → 127.0.0.1:5678

Docker eka-ai
  ├─ Portainer
  ├─ Ollama → qwen3:4b
  ├─ Open WebUI → ollama:11434
  └─ n8n AI Agent → ollama:11434

Gerçek test VPS’imiz 8 vCPU, yaklaşık 31 GiB RAM ve 99 GB root disk ile çalıştı. CPU AMD Ryzen 9 7950X olarak görünüyordu; dedicated NVIDIA veya ROCm GPU passthrough bulunmadığı için Ollama CPU modunda kullanıldı. qwen3:4b modeli bu ortamda işlevsel şekilde çalıştı fakat cevap süresi GPU’lu bir sisteme göre daha uzundu.

Kullanacağınız model boyutu büyüdükçe RAM, disk ve gerekirse VRAM ihtiyacı artar. Open WebUI ilk açılışta embedding/cache dosyaları da indirebildiği için yalnız LLM model boyutunu değil Docker image, volume, execution ve cache alanlarını da hesaba katın.

lscpu | grep -E 'Model name|CPU\(s\)'
free -h
df -h /
nvidia-smi || true
ls -la /dev/dri 2>/dev/null || true

Mevcut VPS Ubuntu 22.04 kullanıyorsa önce normal paket güncellemelerini tamamlayıp yedek/snapshot alın. Ubuntu Server için ana sürüm yükseltme aracı do-release-upgrade komutudur ve süreç interaktiftir. Gerçek yükseltmemizde bağlantı kopmasına karşı recovery SSH 1022 portu, paket planı, openssh-server yapılandırma sorusu, obsolete paket temizliği ve final reboot adımlarını gördük.

Yükseltme tamamlanmış sayılmadan önce yeniden başlatın ve /etc/os-release, kernel, apt durumu ve systemd failed servislerini kontrol edin. Bizim final testimiz Ubuntu 24.04.4 LTS, Noble ve 6.8.0-137-generic kernel ile tamamlandı.

apt update
apt full-upgrade -y
reboot

do-release-upgrade

cat /etc/os-release
uname -r
apt update
systemctl --failed

Docker’ı Ubuntu’nun rastgele üçüncü taraf paketlerinden veya eski scriptlerden değil resmî Docker APT deposundan kurmak sürüm ve Compose plugin yönetimini daha öngörülebilir hale getirir. Gerçek testte Docker Engine 29.7.2 ve Docker Compose v5.4.0 kullanıldı; bu değerler yalnız test anındaki sürümlerdir.

İlk otomasyon scriptimiz set -o pipefail ile apt-cache policy çıktısını head komutuna bağladığı için SIGPIPE ve exit code 141 ile sonlandı. Kurulum bozuk değildi; pipeline davranışı scripti durdurmuştu. head yerine sed ile sınırlandırınca akış sorunsuz devam etti. Son kontrol için hello-world containerını çalıştırdık.

docker --version
docker compose version
systemctl is-active docker

docker run --rm hello-world

Portainer için portainer_data named volume oluşturup Docker socket’i container içine bağladık. Portainer yönetim ekranı container içinde HTTPS 9443 kullanır. İlk kurulum sırasında güvenlik zaman aşımı ve setup token akışıyla karşılaştık; container yeniden başlatılıp admin hesabı tamamlandı.

Üretim yapısında 9443 portunu doğrudan 0.0.0.0 üzerinden yayınlamak yerine host tarafında 127.0.0.1:9443 olarak sınırlandırdık. Dış kullanıcı yalnız portainer.ekasunucu.com üzerinden Nginx + HTTPS ile ulaşır.

docker volume create portainer_data

docker run -d --name portainer --restart=always -p 127.0.0.1:9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

docker ps --filter name='^/portainer$'

Portainer domainini ilk açtığımızda reverse proxy henüz hazır olmadığı için Cloudflare 521 hatası aldık. Nginx site tanımı oluşturulup upstream 127.0.0.1:9443’e bağlandıktan sonra origin erişimi düzeldi. Sertifika aşamasında Certbot snap kurulumu core24 indirme timeoutu verdi; ağ erişimi düzeldikten sonra yeniden denemede sertifika başarıyla oluşturuldu.

Aynı yaklaşımı Open WebUI ve n8n için de kullandık. WebSocket kullanan uygulamalarda Upgrade ve Connection başlıklarını proxy konfigürasyonunda koruyun. Sertifikaları kurduktan sonra certbot renew --dry-run ile otomatik yenileme akışını test edin.

nginx -t
systemctl reload nginx

certbot --nginx -d portainer.ekasunucu.com

certbot renew --dry-run

Containerlar birbirlerine host localhost adresiyle değil Docker DNS isimleriyle ulaşmalıdır. Bu nedenle eka-ai adında user-defined bridge network oluşturduk. Ollama container adı ollama olduğu için Open WebUI ve n8n içinden http://ollama:11434 adresi kullanılabilir.

Aynı zamanda ollama_data, openwebui_data ve n8n_data gibi named volume’lar container yaşam döngüsünden bağımsız kalıcı veri sağlar. Image güncellemesi veya container yeniden oluşturma öncesinde bu volume’ların yedeğini planlayın.

docker network create eka-ai 2>/dev/null || true

docker volume create ollama_data
docker volume create openwebui_data
docker volume create n8n_data

docker network inspect eka-ai

Ollama image’ını Docker üzerinden çalıştırdık ve /root/.ollama verisini ollama_data volume’ına bağladık. Test VPS’inde GPU passthrough algılanmadığı için Ollama CPU backend ile başladı. Container içindeki servis 0.0.0.0:11434 dinlese de host mapping 127.0.0.1:11434:11434 olduğu için public internete açılmadı.

İlk health doğrulamasında /api/tags HTTP 200 döndürdü. Model listesi başta boştu; bu servis problemleri ile model indirme problemlerini birbirinden ayırmak için önemli bir kontrol noktasıdır.

docker pull ollama/ollama:latest

docker run -d --name ollama --restart=always --network eka-ai -p 127.0.0.1:11434:11434 -v ollama_data:/root/.ollama ollama/ollama:latest

curl -sS http://127.0.0.1:11434/api/tags

Gerçek kurulumda qwen3:4b modeli yaklaşık 2.5 GB olarak indirildi. Ollama model metadata çıktısında 4.0B parametre sınıfı, Q4_K_M quantization ve tools/thinking yetenekleri görüldü. CPU ortamında modelin yüklenmiş belleği yaklaşık 3 GiB seviyesine çıktı.

Sadece ollama list görmek yeterli değildir. /api/chat ile gerçek bir prompt göndererek inference zincirini test ettik ve EKA-OLLAMA-TEST-BASARILI yanıtını aldık. Bu test daha sonra Open WebUI ve n8n sorunlarını model runtime probleminden ayırmamızı sağladı.

docker exec ollama ollama pull qwen3:4b

docker exec ollama ollama list

curl -sS http://127.0.0.1:11434/api/chat -H 'Content-Type: application/json' -d '{"model":"qwen3:4b","messages":[{"role":"user","content":"Sadece EKA-OLLAMA-TEST-BASARILI yaz"}],"stream":false}'

Ollama’nın varsayılan yerel API’si tek başına public internet erişimi için tasarlanmış bir kullanıcı kimlik doğrulama katmanı değildir. Bu yüzden test mimarisinde 11434 host portu yalnız 127.0.0.1 üzerinde dinledi. Open WebUI ve n8n ise aynı Docker ağı üzerinden container DNS’iyle Ollama’ya ulaştı.

Harici makinelere Ollama API vermeniz gerekiyorsa doğrudan 11434 açmak yerine kimlik doğrulama, TLS, reverse proxy, VPN veya private network tasarlayın. ss çıktısında 11434’ün 0.0.0.0 yerine 127.0.0.1 üzerinde olduğunu doğrulayın.

ss -lntp | grep 11434

docker network inspect eka-ai --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Open WebUI containerını openwebui_data kalıcı volume, sabit WEBUI_SECRET_KEY ve eka-ai ağıyla başlattık. Host portu 127.0.0.1:3000 olarak sınırlandırıldı ve Ollama bağlantısı container içinden http://ollama:11434 adresine yönlendirildi.

İlk açılışta /health hemen 200 dönmedi; container veritabanı migrationları yapıyor ve sentence-transformers/all-MiniLM-L6-v2 dosyalarını Hugging Face üzerinden indiriyordu. Yaklaşık birkaç dakikalık ilk hazırlık sonunda health 200 ve container healthy oldu. Bu nedenle ilk startup sırasında kısa health timeoutlarını doğrudan başarısız kurulum saymayın.

docker run -d --name open-webui --restart=always --network eka-ai -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -v openwebui_data:/app/backend/data ghcr.io/open-webui/open-webui:main

curl -sS http://127.0.0.1:3000/health

Open WebUI hazır olduktan sonra Nginx reverse proxy ile openwebui.ekasunucu.com alan adını localhost 3000 upstream’ine bağladık. WebSocket başlıkları korundu ve Let’s Encrypt sertifikası başarıyla deploy edildi. Origin HTTPS ve domain HTTPS testleri 200 döndürdü.

İlk oluşturulan Open WebUI hesabı administrator yetkisi aldı ve qwen3:4b modelinin panelde görünmesiyle Ollama bağlantısı görsel olarak da doğrulandı. Bu noktada tarayıcı tabanlı tamamen yerel model arayüzü hazırdır.

nginx -t
systemctl reload nginx

certbot --nginx -d openwebui.ekasunucu.com

curl -I https://openwebui.ekasunucu.com

n8n için n8n_data volume ve sabit N8N_ENCRYPTION_KEY kullandık. Container eka-ai ağına bağlandı ve hostta yalnız 127.0.0.1:5678 üzerinden yayınlandı. Reverse proxy için host, protocol, editor base URL, webhook/proxy ve timezone ayarlarını environment dosyasında tuttuk.

Gerçek testte n8n 2.33.7 çalıştı ve /healthz endpointi status ok döndürdü. Başlangıç loglarında Python task runner ve gelecekteki bazı environment varsayılanlarıyla ilgili uyarılar vardı; kullandığımız Chat Trigger + AI Agent akışını engellemedi.

docker volume create n8n_data

openssl rand -hex 32

docker run -d --name n8n --restart=always --network eka-ai --env-file /root/n8n.env -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n:latest

curl -sS http://127.0.0.1:5678/healthz

n8n editörü doğrudan 5678 üzerinden public açılmadı. Nginx n8n.ekasunucu.com domainini localhost:5678 upstream’ine proxy etti ve WebSocket/forwarded başlıkları eklendi. Let’s Encrypt sertifikası kurulduktan sonra domain HTTPS 200 ile doğrulandı.

5678, 11434, 3000 ve 9443 gibi servis portlarının yalnız loopback üzerinde kaldığını ss ile kontrol etmek mimariyi gerçekten güvenli yapan adımdır. Public olarak yalnız Nginx 80/443 dinlemelidir.

certbot --nginx -d n8n.ekasunucu.com

ss -lntp | grep -E ':80 |:443 |:9443 |:11434 |:3000 |:5678 '

n8n ve Ollama ayrı containerlarda olduğundan n8n içindeki localhost:11434 Ollama’yı göstermez. Her iki container eka-ai ağına bağlı olduğu için credential Base URL olarak http://ollama:11434 kullandık. n8n containerından /api/tags çağrısı HTTP 200 döndü ve qwen3:4b modeli bulundu.

İlk import edilen workflow JSON’unda Ollama credential referansı olmadığı için Ollama Qwen3 4B sub-node hata verdi. Credential oluşturulup doğru Docker DNS adresi kaydedildiğinde aynı workflow başarılı çalıştı.

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

Workflow’un ana akışı Chat Trigger’dan AI Agent’a gider. AI Agent Chat Model girişinde Ollama qwen3:4b, Memory girişinde Simple Memory kullanıldı. System message içinde kullanılan gerçek model adı qwen3:4b olarak açıkça belirtildi; böylece modelin kendine uydurma bir runtime/model adı vermesi önlendi.

Final testte Chat Trigger, AI Agent, Ollama Chat Model ve Memory node’larının tamamı yeşil tamamlandı. Agent altyapısının Ollama olduğunu ve qwen3:4b üzerinde çalıştığını doğru şekilde yanıtladı.

Prompt: {{ $json.chatInput }}

Ollama Base URL: http://ollama:11434
Model: qwen3:4b

AI Agent Tool girişine Calculator bağlandı. 3478 × 129 sorusunda model aracı çağırdı ve Calculator node’u 448662 sonucunu döndürdü. Bu, modelin sonucu kafadan üretmesi yerine gerektiğinde deterministik aracı kullanabildiğini gösterdi.

HTTP API denemesinde ilk olarak eski @n8n/n8n-nodes-langchain.toolHttpRequest node tipi kullanıldığı için “supplyData method but no execute method” hatası aldık. Güncel n8n HTTP Request Tool node’una geçildiğinde JSONPlaceholder API çağrısı başarılı oldu ve agent gerçek TODO JSON verisini Türkçe özetledi.

3478 × 129 kaç eder? Hesap makinesini kullan.

OrnekAPIVeriGetir aracını kullan ve gelen API verisini Türkçe açıkla.

Kurulumun son testi yalnız tarayıcı ekranına bakmak değildir. Docker container durumları, health endpointleri, public domain HTTP kodları, loopback port bindingleri, named volume’lar, systemd failed servisleri ve Certbot renewal testini birlikte kontrol edin. Bir VPS reboot sonrası tüm containerların restart policy ile yeniden geldiğini de doğrulayın.

Yedekleme tarafında portainer_data, ollama_data, openwebui_data ve n8n_data volume’larını; ayrıca Nginx site dosyaları, Let’s Encrypt dizini ve n8n encryption key gibi yapılandırma verilerini planlı şekilde koruyun. Model dosyaları yeniden indirilebilir olsa da n8n credential/workflow ve Open WebUI kullanıcı verileri daha kritiktir.

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

curl -fsS http://127.0.0.1:11434/api/tags >/dev/null && echo OLLAMA_OK
curl -fsS http://127.0.0.1:3000/health >/dev/null && echo WEBUI_OK
curl -fsS http://127.0.0.1:5678/healthz >/dev/null && echo N8N_OK

certbot renew --dry-run

systemctl --failed

Bu pillar rehberin sonunda altyapı katmanı hazırdır: container yönetimi Portainer’da, yerel LLM Ollama’da, kullanıcı chat arayüzü Open WebUI’da ve otomasyon/agent katmanı n8n’dedir. Bir sonraki mantıklı adım, Qdrant gibi bir vector database ve embedding modeli ekleyerek kendi dokümanlarınızdan cevap veren RAG mimarisi kurmaktır.

RAG katmanında doküman yükleme, chunking, embedding, vector store, retrieval ve kaynak gösterme adımlarını ayrı tutacağız. Böylece qwen3:4b yalnız genel model bilgisine değil, sizin eklediğiniz güncel özel veri setine de kontrollü biçimde erişebilir.

Docker / eka-ai
  ├─ Ollama → qwen3:4b
  ├─ Open WebUI
  ├─ n8n AI Agent
  └─ Qdrant + Embeddings + RAG  ← sonraki rehber