2026'da n8n'i Self-Host Etme: Deploy, TLS, Webhook'lar ve Yedekler

Bir n8n container'ı başarılı durumda görünürken kullanıcıların asıl ihtiyaç duyduğu iş bozuk olabilir. n8n'de bu gizli hata genellikle webhook linklerinin hâlâ localhost'u göstermesi veya proxy header'larının HTTP bildirmesidir. Bu rehberde “production webhook'lu bir workflow'u etkinleştirmek, bu webhook'u sunucu dışından çağırmak ve execution'ın son node'a ulaştığını doğrulamak” kabul testidir; deployment'ı da bu sonuçtan geriye doğru tasarlıyoruz.

n8n'in stack'teki rolü nettir: 400'den fazla integration ve genişletilebilir bir node sistemi sunan workflow automation platformu. Bu nedenle production'daki soru, 5678 portunun bir kez yanıt verip vermediği değil; restart, update ve restore sonrasında state'in, dependency'lerin ve public address'in uyumlu kalıp kalmadığıdır.

Değiştirilebilir container'ları kalıcı verilerden ayırın

n8n için recovery point ve recovery time hedeflerini database ile .n8n encryption ve configuration verileri üzerinden tanımlayın. Bootstrap işleminden önce /home/node/.n8n yolunu mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Named volume, redeploy sonrasında kalıcılığı çözer; ancak compromise veya sunucu kaybını çözmez.

Temiz bir restore ortamı oluşturun, aynı sabitlenmiş application version'ı kullanın ve restore edilen credential'ların hâlâ decrypt edilebildiğini, restore edilen workflow'un da aynı public webhook URL'sini aldığını kanıtlayın. Komutları, ownership düzeltmelerini ve geçen süreyi kaydedin. Yedekleme rehberi yararlı bir standarttır: Bir backup, upload edildikten sonra değil restore edildikten sonra güvenilir kabul edilir.

n8n başlangıcını tekrarlanabilir hâle getirin

Minimal bir komut, platformun ileride neyi yöneteceğini açıkça gösterdiğinde faydalıdır.

docker run -d \
  --name n8n \
  --restart unless-stopped \
  -p 127.0.0.1:5678:5678 \
  -v n8n-data:/home/node/.n8n \
  -e N8N_ENCRYPTION_KEY=replace-with-a-long-random-value \
  docker.n8n.io/n8nio/n8n

Burada 5678 portu host'a özel kalır ve gerekli tüm yollar açıkça tanımlanır. Kalıcı, çok kullanıcılı bir production kurulumu için Postgres bağlantı ayarlarını gözden geçirip ekleyin; private servisler için private isimler kullanın. Başlangıcı hem log'larla hem de uygulamaya özgü kanıtla doğrulayın: production webhook'lu bir workflow'u etkinleştirin, bu webhook'u sunucu dışından çağırın ve execution'ın son node'a ulaştığını doğrulayın. Doğrulama tamamlandıktan sonra image version'ı sabitleyin; böylece rutin bir replacement davranışı sessizce değiştirmez.

Portlar, process'ler ve private servisler

n8n'in network namespace'i ile başlayın: Web listener'ı 5678 portudur; bu, bir laptop tutorial'ından kopyalanmış host portu değildir. n8n için network contract, kalıcı ve çok kullanıcılı bir production kurulumu adına Postgres'tir. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve n8n'e kapsamı sınırlandırılmış bir service credential verin.

Gereksinim karşılandıktan sonra tüm senaryoyu çalıştırın — production webhook'lu bir workflow'u etkinleştirin, bu webhook'u sunucu dışından çağırın ve execution'ın son node'a ulaştığını doğrulayın. Editor page view'ları yerine execution concurrency, queue depth, binary payload size ve long-running node'lar için log'ları ve ölçümleri kaydedin. Bu kanıt, ilk known-good architecture'ı oluşturur ve Dockup compute ile bağlı bir sunucu arasındaki sonraki geçişleri test edilebilir hâle getirir.

Proxy başarısının application failure'ı gizlemesini önleyin

n8n için public boundary, tek bir canonical hostname, automatic TLS ve 5678 üzerindeki tek bir internal target olmalıdır. WEBHOOK_URL değerini tam external HTTPS URL olarak ayarlayın; böylece client'lar servisin tanıdığı bir adrese geri döner.

Kabul transaction'ı başarısız olursa ilk hatayı sınıflandırın. DNS, certificate ve 502 sorunları TLS doğrulama checklist'ine girer. “Webhook linkleri hâlâ localhost'u gösteriyor veya proxy header'ları HTTP bildiriyor” koşulu ise bir request n8n'e başarıyla ulaştıktan sonraki application side'a aittir.

Gerçek n8n verileri gelmeden önce geçmesi gerekenler

n8n smoke test'ini tekrarlanabilir bir release command'ına veya kısa bir runbook'a dönüştürün. Çıktı şu sonucu kanıtlamalıdır: production webhook'lu bir workflow'u etkinleştirin, bu webhook'u sunucu dışından çağırın ve execution'ın son node'a ulaştığını doğrulayın. Sonuçla birlikte application version, container digest, route hostname ve test-data identifier bilgilerini kaydedin.

Aynı kontrolü rutin bir container swap sonrasında ve database ile .n8n encryption ve configuration verilerini başka bir yerde restore ettikten sonra çalıştırın. Restore, restore edilen credential'lar hâlâ decrypt edilebildiğinde ve restore edilen workflow aynı public webhook URL'sini aldığında başarılıdır. Editor page view'ları yerine execution concurrency, queue depth, binary payload size ve long-running node'larla ilgili timing ve consumption değerlerini karşılaştırın; final action hâlâ başarılı olsa bile büyük bir değişiklik incelenmeye değerdir.

Ardından güvenli bir failure senaryosunu test edin: Test identity'nin kalıcı ve çok kullanıcılı bir production kurulumu için Postgres'e erişimini geçici olarak engelleyin. n8n'in hatayı görünür kıldığını ve destructive manual edit'ler olmadan normale döndüğünü doğrulayın. Yalnızca gerekli, redakte edilmiş log bölümünü saklayın. Bu dört parçalı gate; startup, persistence, recovery ve failure handling süreçlerini kapsar.

Capacity ve upgrade kontrolleri

Dashboard'ları editor page view'ları yerine execution concurrency, queue depth, binary payload size ve long-running node'lar etrafında oluşturun. Bu workload context olmadan CPU grafiği, n8n'in neden yavaş olduğunu açıklayamaz. Zararsız test verileri kullanarak production webhook'lu bir workflow'u etkinleştirmeyi, bu webhook'u sunucu dışından çağırmayı ve execution'ın son node'a ulaştığını doğrulamayı deneyen synthetic veya scheduled bir kontrol ekleyin.

Upgrade işleminden önce uygulamaya özgü şu riski hesaba katın: Database migration'ları, credential encryption ve kurulu community node'lar hedef n8n release'iyle uyumlu kalmalıdır. Güncel bir backup'ı isolated deployment'a restore edin, migration'ları orada çalıştırın ve davranışı karşılaştırın. Webhook linkleri hâlâ localhost'u gösteriyor veya proxy header'ları HTTP bildiriyorsa, ilgisiz ayarlara dokunmadan önce ilgili boundary'yi — public origin, storage veya dependency — inceleyin.

Bootstrap sonrasında n8n'i güvenlik altına alın

Güvenlik varsayımlarını local bir tutorial'dan devralmayın. n8n'e özgü kritik nokta, credential'lar kaydedildikten sonra N8N_ENCRYPTION_KEY'in rotate edilmesidir. Bu nedenle production ortamında editor authenticated tutulmalı ve yalnızca integration'ların gerçekten ihtiyaç duyduğu webhook path'leri dışarı açılmalıdır.

N8N_ENCRYPTION_KEY'i bir kez generate edin, Git dışında tutun ve recovery manifest ile birlikte saklayın; çünkü bu değeri değiştirmek encrypted veya signed application state'i geçersiz kılabilir. Filesystem ve network erişimini scope'layın, setup endpoint'lerini koruyun ve upload, request veya execution limit'lerini editor page view'ları yerine execution concurrency, queue depth, binary payload size ve long-running node'lar etrafında tanımlayın.

Dockup routing'i yönetirken n8n'i açıkça yapılandırılmış tutun

Dockup'ın one-click n8n deployment'ı replacement işlemini güvenli hâle getirmelidir: Route 5678'i hedeflemeye devam eder, secret'lar image içine gömülmez ve persistent path'ler yeni container'da yeniden kullanılabilir. Aynı deployment, Dockup compute üzerinde veya bağlı bir makinede çalışabilir.

Postgres'i kalıcı ve çok kullanıcılı bir production kurulumu için bağlayıp test ederek, canonical public address'i uygulayarak ve şu kabul kontrolünü çalıştırarak uygulamaya özgü işlemleri tamamlayın: production webhook'lu bir workflow'u etkinleştirin, bu webhook'u sunucu dışından çağırın ve execution'ın son node'a ulaştığını doğrulayın. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.

Sık sorulan sorular

Production deployment için n8n'in neye ihtiyacı vardır?

n8n container'ını tek bir HTTPS origin üzerinden 5678 portuna route edin. Destekleyici network gereksinimi, kalıcı ve çok kullanıcılı bir production kurulumu için Postgres'tir. Production webhook'lu bir workflow'u etkinleştiremiyor, bu webhook'u sunucu dışından çağıramıyor ve execution'ın son node'a ulaştığını doğrulayamıyorsanız n8n'i hazır kabul etmeyin.

Hangi n8n verileri backup'a dahil edilmelidir?

/home/node/.n8n yolunu kalıcı hâle getirin ve database ile .n8n encryption ve configuration verilerini aynı recovery manifest'e dahil edin. Temiz bir n8n restore işlemi, yalnızca restore edilen credential'lar hâlâ decrypt edilebildiğinde ve restore edilen workflow aynı public webhook URL'sini aldığında başarılıdır.

n8n reverse proxy arkasında HTTPS gerektirir mi?

Public n8n origin için HTTPS kullanın ve 5678 portunu internal route üzerinde tutun. n8n ayarını doğru uygulayın: WEBHOOK_URL değerini tam external HTTPS URL olarak ayarlayın. n8n için HTTPS, credential'ları veya kullanıcı içeriğini transit sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Bir n8n upgrade'i nasıl test edilmelidir?

Güncel n8n state'ini isolated deployment'a restore edin, candidate version'ı uygulayın ve kabul transaction'ını tekrarlayın. Database migration'ları, credential encryption ve kurulu community node'ların hedef n8n release'iyle uyumlu kalması gerektiğinden bu noktaya özellikle dikkat edin. Data-migration ve rollback sınırları anlaşılana kadar önceki n8n image'ını saklayın.