n8n Sunucu Kiralama

n8n Güncelleme ve Bakım

n8n açık kaynak projesi olarak sık aralıklarla yeni sürüm yayınlar: yeni node'lar, güvenlik yamaları, performans iyileştirmeleri ve bazen de mevcut node davranışını değiştiren "breaking change"ler. Self-hosted çalıştırdığınız için güncelleme sorumluluğu size aittir; ancak Docker Compose ile kurulmuş bir yapı üzerinde bu işlem birkaç dakikada tamamlanır.

Güncelleme akışı üç adımdan oluşur: önce yeni imajı indirin, ardından konteynerleri yeniden oluşturup başlatın, son olarak log çıktısından hatasız açıldığını doğrulayın.

# 1. Güncel n8n imajını indir
docker compose pull

# 2. Konteynerleri yeni imaj ile yeniden oluştur
docker compose up -d

# 3. Başlatma loglarını izle, hata var mı kontrol et
docker compose logs -f n8n

# 4. (Opsiyonel) Kullanılmayan eski imajları temizle
docker image prune -f

Güncellemeden hemen önce PostgreSQL veritabanınızın anlık bir dökümünü almanız kritik önemdedir; bir sorun çıkarsa pg_dump ile aldığınız yedekten dakikalar içinde geri dönebilirsiniz. Aynı şekilde şifreleme anahtarınızı ve credential verilerinizi barındıran ~/.n8n klasörünü de ayrıca yedeklemeyi ihmal etmeyin — bu klasör kaybolursa kayıtlı API anahtarlarınızı yeniden girmeniz gerekir.

Otomatik güncellemeyi (örneğin bir cron job ile her gece docker compose pull && docker compose up -d çalıştırmak) kurmadan önce iki kez düşünün: n8n her sürümde geriye dönük uyumluluğu hedefler, ancak node davranışında ince değişiklikler nadiren de olsa yaşanabilir. Bu yüzden çoğu ekip için önerilen yaklaşım, sürüm notlarını elle gözden geçirip haftada veya iki haftada bir manuel güncelleme yapmaktır; kritik iş süreçleri çalıştıran production sunucularda otomatik güncelleme genellikle tercih edilmez.

Güvenlik: Webhook ve API Anahtarı Yönetimi

n8n workflow'larınız genellikle hassas bilgi taşır: dışarıdan tetiklenen webhook URL'leri, OpenAI/Claude/Gemini gibi AI servislerinin API anahtarları, Stripe veya Telegram bot token'ları, müşteri e-posta ve sipariş verileri. Self-hosted bir kurulumda bu verilerin korunması tamamen sunucu yapılandırmanıza bağlıdır; aşağıdaki beş önlem çoğu senaryo için yeterli bir güvenlik tabanı oluşturur.

VDS seviyesinde güvenlik duvarı yapılandırması da en az uygulama seviyesindeki önlemler kadar önemlidir. Sadece gerçekten dışarıdan erişilmesi gereken portları açık bırakın; n8n'in kendi varsayılan portu (5678) doğrudan internete açık olmamalı, yalnızca Traefik/Nginx reverse proxy'nin arkasında, sunucu içi ağda erişilebilir kalmalıdır.

# Sadece SSH, HTTP ve HTTPS portlarını dışa aç
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp

# n8n'in dahili portunu dışarıya kapat
ufw deny 5678/tcp

# Firewall'u etkinleştir
ufw enable

Yönetim arayüzünü ekstra korumak isteyenler için ek bir öneri: n8n editörünü doğrudan herkese açık bir domain üzerinden değil, bir SSH tüneli veya VPN arkasından erişilebilir hale getirmek mümkündür. Bu durumda yalnızca /webhook ve /webhook-test gibi dışarıdan tetiklenmesi gereken uç noktalar Traefik üzerinden dışa açılır; editör arayüzü ise sadece belirli IP adreslerinden veya tünel üzerinden erişilebilir kalır. Küçük ekiplerde basic auth genelde yeterlidir, ancak çok kişili veya kurumsal kullanımda bu ek katman saldırı yüzeyini daha da daraltır.

Performans ve Ölçeklendirme: Queue Mode

Varsayılan çalışma modunda tek bir n8n process'i hem yönetim arayüzünü, hem webhook isteklerini karşılamayı, hem de workflow çalıştırmayı aynı anda üstlenir. Az sayıda workflow ve düşük trafik için bu yeterlidir; ancak çok sayıda paralel webhook tetiklemesi, uzun süren işlemler (büyük dosya dönüştürme, uzun API bekleme süreleri, toplu veri işleme) veya yüksek eşzamanlı kullanım söz konusu olduğunda tek process darboğaz haline gelir: yeni istekler kuyrukta bekler, yönetim arayüzü yavaşlar, bazı webhook'lar zaman aşımına uğrar.

Bu noktada n8n'in queue mode mimarisine geçilir. Mimari üç bileşenden oluşur: kullanıcı arayüzünü sunan ve webhook isteklerini karşılayan bir main process, işleri sıraya alan bir Redis kuyruk sunucusu ve bu kuyruktan işleri çekip gerçekten çalıştıran bir veya daha fazla worker process. EXECUTIONS_MODE=queue ortam değişkeni ile etkinleştirilir; worker sayısı arttıkça sistem paralel olarak daha fazla workflow çalıştırabilir hale gelir.

Queue mode'a geçince kaynak ihtiyacı da orantılı şekilde büyür: her worker container'ı kendi CPU ve RAM payını gerektirir, Redis kuyruğu için ek bellek ayrılmalı, PostgreSQL tarafında ise her worker ayrı bir veritabanı bağlantısı açtığı için max_connections ayarının da gözden geçirilmesi gerekir. Tek instance'tan queue mode'a geçiş planlıyorsanız daha fazla çekirdek ve RAM sunan E5-V4 VDS Pro paketlerine geçmenizi öneririz.

Pratikte geçiş kademeli yapılır: önce mevcut tek instance'ı normal modda izleyip yönetim panelindeki "Executions" geçmişinden gecikme ve kuyruklanma belirtilerini gözlemleyin. Ortalama çalıştırma süresi uzuyor, webhook yanıtları gecikiyor veya CPU sürekli yüksek seyrediyorsa queue mode'a geçiş zamanı gelmiş demektir. Başlangıçta tek bir worker container ile başlayıp trafiğe göre worker sayısını kademeli artırmak, gereksiz kaynak israfını önler.