n8n Kurulumu: Docker, Sunucu ve Domain ile Adım Adım Self-Hosted Rehber (2026)

n8n, iş süreçlerini otomatikleştirmek için kullanılan açık kaynak bir otomasyon aracı. Zapier ve Make’e benzer bir mantıkla çalışır ama iki temel farkı var: kendi sunucunuzda barındırabilirsiniz ve çalıştırma sayısına göre değil, kullandığınız altyapıya göre maliyet üretir.

Bu rehber, n8n kurulumunu baştan sona ele alıyor: Cloud ile self-hosted arasındaki karar, Docker ile kurulum, PostgreSQL’e geçiş, domain ve SSL, webhook’ların doğru çalışması, güvenlik ayarları, yedekleme, güncelleme ve yük arttığında ölçekleme.

Sürüm notu: Bu yazı n8n 2.x sürümü esas alınarak yazıldı. n8n hızlı geliştirilen bir proje; ortam değişkenlerinde ve varsayılanlarda sürümler arası değişiklikler olabiliyor. Kurulumdan önce kullandığınız sürümün dokümantasyonunu kontrol etmenizi öneririm.

n8n Nedir, Neden Self-Hosted?

n8n, görsel bir arayüzde düğümleri (node) birbirine bağlayarak otomasyon akışları kurmanızı sağlar. 400’ün üzerinde hazır entegrasyonu, HTTP isteği düğümü ve yapay zeka ajanı kurmaya yarayan AI Agent düğümü var.

Rakiplerinden ayrıştığı nokta lisans modeli: n8n fair-code lisanslıdır. Kendi sunucunuzda, kendi işiniz için ücretsiz çalıştırabilirsiniz. Kısıt, n8n’i bir servis olarak başkalarına satmanızla ilgilidir — kendi şirketinizin otomasyonları için bir sınır yoktur.

Cloud mu, self-hosted mu?

Self-hosted’ı seçin, eğer: Yüksek hacimli otomasyon çalıştıracaksanız (maliyet avantajı burada oluşur), verinin kendi altyapınızda kalması gerekiyorsa (KVKK, iç politika), iç sistemlerinize (yerel veritabanı, ERP) doğrudan erişim gerekiyorsa.

Cloud’u seçin, eğer: Sunucu yönetmek istemiyorsanız, ekipte Linux bilen kimse yoksa, ya da önce n8n’in işinize yarayıp yaramadığını hızlıca test etmek istiyorsanız.

Pratik tavsiye: Önce Cloud’un ücretsiz deneme süresiyle veya bilgisayarınızda yerel kurulumla bir hafta çalışın. n8n’in işinizi çözdüğünü gördükten sonra sunucu kurulumuna geçin. Ters sırada ilerlemek, henüz ihtiyaç duymadığınız bir altyapıyı yönetmek anlamına gelir.

Kurulum Yöntemleri: Hangisi Sizin İçin?

n8n’in kendi dokümantasyonu da çoğu senaryo için Docker’ı öneriyor: işletim sistemi uyumsuzluklarını ortadan kaldırır, veritabanı ve ortam yönetimini basitleştirir.

Hızlı Deneme: Bilgisayarınızda 2 Dakikada

Sunucu kurmadan önce n8n’i tanımak için:

npx n8n

Komut çalıştıktan sonra tarayıcıdan http://localhost:5678 adresine gidin. İlk açılışta bir sahip (owner) hesabı oluşturmanız istenir.

Docker ile denemek isterseniz:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="Europe/Istanbul" \
  -e TZ="Europe/Istanbul" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Buradaki kritik parça -v n8n_data:/home/node/.n8n satırı. Bu volume, akışlarınızın ve kimlik bilgilerinizin saklandığı yerdir. Onu vermezseniz konteyner silindiğinde her şey gider.

--rm bayrağı, konteyner durunca kendisini siler. Deneme için uygun, kalıcı kurulumda kullanılmaz.

Üretim Kurulumu: Sunucu Hazırlığı

Sunucu gereksinimleri

Küçük–orta ölçekli bir kurulum için başlangıç noktası:

RAM, n8n’de en çok darboğaz yaratan kaynaktır. Özellikle büyük dosya işleyen veya çok sayıda kaydı belleğe alan akışlarda 2 GB hızla yetersiz kalır.

Sunucuyu hazırlayın

Ubuntu tabanlı bir sunucuda:

# Sistem güncellemesi
sudo apt update && sudo apt upgrade -y

# Docker kurulumu
curl -fsSL https://get.docker.com | sudo sh

# Kullanıcıyı docker grubuna ekleyin (sudo'suz çalıştırmak için)
sudo usermod -aG docker $USER
# Bu değişikliğin geçerli olması için oturumu kapatıp açın

# Güvenlik duvarı
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

Dikkat: 5678 portunu güvenlik duvarında açmayın. n8n’e dışarıdan erişim, 443 üzerinden ters proxy ile sağlanacak. 5678’i dışarı açmak, n8n’i şifresiz HTTP üzerinden internete koymak demektir.

Domain yönlendirmesi

Alan adı sağlayıcınızın DNS panelinde bir A kaydı oluşturun:

Tip: A    İsim: n8n    Değer: <sunucu_ip_adresi>

DNS yayılması genellikle birkaç dakika sürer. ping n8n.alanadiniz.com komutuyla sunucu IP’sinin dönüp dönmediğini kontrol edin — SSL adımına geçmeden önce bunun çalışıyor olması şart.

Docker Compose ile Üretim Kurulumu

Bu bölüm, önerilen kurulumu içeriyor: n8n + PostgreSQL + otomatik SSL sağlayan bir ters proxy (Caddy).

Klasör yapısı

mkdir -p ~/n8n && cd ~/n8n

.env dosyası

Önce bir encryption key üretin — bu, kimlik bilgilerinizi şifrelemek için kullanılır:

openssl rand -hex 32

Sonra .env dosyasını oluşturun:

# --- Domain ---
DOMAIN_NAME=n8n.alanadiniz.com

# --- n8n temel ayarları ---
N8N_HOST=n8n.alanadiniz.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.alanadiniz.com/
N8N_EDITOR_BASE_URL=https://n8n.alanadiniz.com/

# --- Saat dilimi ---
GENERIC_TIMEZONE=Europe/Istanbul
TZ=Europe/Istanbul

# --- Güvenlik ---
N8N_ENCRYPTION_KEY=<openssl_ile_urettiginiz_deger>
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true

# --- Veritabanı ---
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=<guclu_bir_parola>

# --- Çalıştırma verisi temizliği ---
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336

.env dosyasını asla git deposuna eklemeyin. İçinde veritabanı parolası ve encryption key var. .gitignore dosyanıza ekleyin.

docker-compose.yml

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${DB_POSTGRESDB_DATABASE}
      - POSTGRES_USER=${DB_POSTGRESDB_USER}
      - POSTGRES_PASSWORD=${DB_POSTGRESDB_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U ${DB_POSTGRESDB_USER} -d ${DB_POSTGRESDB_DATABASE}']
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=${N8N_PORT}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${TZ}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=${N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS}
      - N8N_PROXY_HOPS=1
      - DB_TYPE=${DB_TYPE}
      - DB_POSTGRESDB_HOST=${DB_POSTGRESDB_HOST}
      - DB_POSTGRESDB_PORT=${DB_POSTGRESDB_PORT}
      - DB_POSTGRESDB_DATABASE=${DB_POSTGRESDB_DATABASE}
      - DB_POSTGRESDB_USER=${DB_POSTGRESDB_USER}
      - DB_POSTGRESDB_PASSWORD=${DB_POSTGRESDB_PASSWORD}
      - EXECUTIONS_DATA_PRUNE=${EXECUTIONS_DATA_PRUNE}
      - EXECUTIONS_DATA_MAX_AGE=${EXECUTIONS_DATA_MAX_AGE}
    volumes:
      - n8n_data:/home/node/.n8n
      - ./local-files:/files
    depends_on:
      postgres:
        condition: service_healthy

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n

volumes:
  postgres_data:
  n8n_data:
  caddy_data:
  caddy_config:

Caddyfile

Caddy’nin en büyük avantajı, Let’s Encrypt sertifikasını otomatik alması ve yenilemesi. Üç satırlık bir dosya yeterli:

n8n.alanadiniz.com {
    reverse_proxy n8n:5678
}

Başlatma

docker compose up -d

Logları izleyin:

docker compose logs -f n8n

Birkaç saniye sonra https://n8n.alanadiniz.com adresinden arayüze ulaşabilirsiniz. İlk açılışta sahip hesabınızı oluşturun — bu hesap yönetici yetkisine sahiptir ve n8n’in kimlik doğrulaması buradan yönetilir.

Kritik Ayarların Anlamı

Kurulumu kopyalayıp geçmek yerine, üç ayarın ne yaptığını bilmek uzun vadede çok zaman kazandırır.

N8N_ENCRYPTION_KEY

n8n, entegrasyonlarınızın kimlik bilgilerini (API anahtarları, parolalar) veritabanına şifreli yazar. Bu şifrelemenin anahtarı encryption key’dir.

Elle belirlemezseniz n8n ilk açılışta rastgele bir anahtar üretir ve ~/.n8n klasörüne kaydeder. Sorun şu: o klasörü kaybederseniz veya farklı bir anahtarla yeni bir kurulum yaparsanız, veritabanındaki tüm kimlik bilgileri okunamaz hale gelir. Akışlarınız durur ve her entegrasyonu tek tek yeniden bağlamanız gerekir.

Bu yüzden anahtarı baştan kendiniz belirleyin ve veritabanı yedeğinden ayrı, güvenli bir yerde saklayın. Sunucu taşıma, yedekten dönme ve worker ekleme senaryolarının hepsinde bu anahtara ihtiyacınız olacak.

WEBHOOK_URL

n8n webhook adreslerini N8N_PROTOCOL, N8N_HOST ve N8N_PORT değerlerini birleştirerek üretir. Ters proxy arkasında çalıştığınızda bu hesap yanlış çıkar — n8n kendi iç portunu (5678) bilir ama dışarıdaki gerçek adresi bilmez.

Sonuç: arayüzde webhook adresi http://localhost:5678/webhook/... gibi görünür ve dış servisler bu adrese ulaşamaz. WEBHOOK_URL değişkeni tam olarak bunu düzeltir.

EXECUTIONS_DATA_PRUNE

n8n her akış çalıştırmasının verisini veritabanına yazar. Temizlik açılmazsa bu veri sürekli birikir; birkaç ay sonra veritabanı şişer ve arayüz belirgin şekilde yavaşlar.

EXECUTIONS_DATA_PRUNE=true eski kayıtları otomatik siler, EXECUTIONS_DATA_MAX_AGE ise kaç saat sonra silineceğini belirler (varsayılan 336 saat, yani 14 gün). Uzun geçmişe ihtiyacınız yoksa bu değeri düşürmek, veritabanını küçük ve hızlı tutar.

Kurulum Sonrası: İlk 30 Dakika

1. Kullanıcıları ekleyin

Ayarlar → Users bölümünden ekip üyelerini davet edin. Herkesin aynı hesabı paylaşması, kimin neyi değiştirdiğini takip edilemez hale getirir.

2. İki faktörlü doğrulamayı açın

n8n’e erişimi olan biri, bağladığınız tüm sistemlere (CRM, e-posta, veritabanı) erişimi olan kişidir. 2FA’yı en azından yönetici hesabı için açın.

3. İlk akışınızı kurun

Basit bir testle başlayın: Manual Trigger → HTTP Request → sonucu görüntüle. Bu, ağ bağlantısının ve dış erişimin çalıştığını doğrular.

4. Webhook’u test edin

Yeni bir akış oluşturup Webhook düğümü ekleyin. Üretilen adres https://n8n.alanadiniz.com/webhook-test/... biçiminde olmalı. localhost veya :5678 görüyorsanız WEBHOOK_URL ayarınız devreye girmemiştir.

5. Yedekleme kurun

Bunu “sonra yaparım” listesine koymayın. Alt bölümdeki komutları bugün kurun.

Yedekleme ve Geri Yükleme

Yedeklenmesi gereken üç şey var:

1. PostgreSQL veritabanı — akışlar, kimlik bilgileri, çalıştırma geçmişi
2. n8n_data volume — ayar dosyaları
3. Encryption key — bu olmadan yedekteki kimlik bilgileri açılamaz

Günlük veritabanı yedeği

#!/bin/bash
# ~/n8n/backup.sh
YEDEK_DIZIN=~/n8n-yedek
mkdir -p $YEDEK_DIZIN

TARIH=$(date +%F)
docker compose -f ~/n8n/docker-compose.yml exec -T postgres \
  pg_dump -U n8n n8n | gzip > $YEDEK_DIZIN/n8n-$TARIH.sql.gz

# 14 günden eski yedekleri sil
find $YEDEK_DIZIN -name "n8n-*.sql.gz" -mtime +14 -delete

Çalıştırılabilir yapıp zamanlanmış göreve ekleyin:

chmod +x ~/n8n/backup.sh
crontab -e
# Şu satırı ekleyin — her gece 03:00'te çalışır:
0 3 * * * /home/kullanici/n8n/backup.sh

Yedeği test etmediyseniz yedeğiniz yok. Ayda bir, yedek dosyasını boş bir veritabanına geri yükleyerek çalıştığını doğrulayın. Bozuk yedeğin fark edildiği an, genellikle ona en çok ihtiyaç duyulan andır.

Yedekleri ayrıca sunucu dışına (S3, başka bir sunucu) kopyalayın. Sunucu tamamen kaybolduğunda, aynı sunucudaki yedek de kaybolur.

Güncelleme

n8n sık güncellenir. Docker Compose kurulumunda güncelleme üç komuttur:

cd ~/n8n

# Önce yedek alın
./backup.sh

# Yeni imajı çekin ve yeniden başlatın
docker compose pull
docker compose up -d

Güncellemeden önce iki şey:

• Yedek alın. Veritabanı şeması değişebilir ve geri dönüş her zaman kolay olmaz.
• Sürüm notlarını okuyun. Ana sürüm atlamalarında (1.x → 2.x gibi) davranış değişiklikleri olabilir.

Ana sürüm atlarken doğrudan üretimde denemeyin: yedeği ayrı bir test kurulumuna yükleyin, orada güncelleyin, akışlarınızın çalıştığını doğrulayın, sonra üretime geçin.

Ölçekleme: Queue Mode

Varsayılan kurulumda n8n tüm akışları tek bir süreç içinde çalıştırır. Küçük ve orta hacim için yeterlidir. Şu belirtiler görünüyorsa queue mode zamanı gelmiştir:

• Akışlar sırada bekliyor, gecikmeler artıyor
• Uzun süren bir akış diğerlerini bloke ediyor
• CPU sürekli tepede
• Kesintisiz çalışması gereken kritik akışlarınız var

Queue mode’da mimari şöyle değişir: ana örnek (main) arayüzü sunar ve işleri sıraya atar, Redis sırayı tutar, worker’lar işleri çeker ve çalıştırır. Yük arttığında worker sayısını artırırsınız.

Compose’a eklemeler

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    command: worker --concurrency=5
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=${DB_TYPE}
      - DB_POSTGRESDB_HOST=${DB_POSTGRESDB_HOST}
      - DB_POSTGRESDB_DATABASE=${DB_POSTGRESDB_DATABASE}
      - DB_POSTGRESDB_USER=${DB_POSTGRESDB_USER}
      - DB_POSTGRESDB_PASSWORD=${DB_POSTGRESDB_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${TZ}
    depends_on:
      - redis
      - postgres
    deploy:
      replicas: 2

Ana n8n servisine de EXECUTIONS_MODE=queue ve QUEUE_BULL_REDIS_HOST=redis değişkenlerini ekleyin.

Queue mode’un üç kuralı:

1. Encryption key her yerde aynı olmalı. Ana örnek ve tüm worker’lar aynı anahtarı paylaşmazsa worker’lar kimlik bilgilerini çözemez.
2. SQLite ile queue mode kullanmayın. PostgreSQL şart.
3. Concurrency değerini ölçerek seçin. --concurrency=5, bir worker’ın aynı anda 5 iş çalıştırması demektir. Yüksek değer RAM tüketir; sunucunuzu izleyerek ayarlayın.

Yüksek erişilebilirlik için birden fazla ana örnek de çalıştırılabilir (N8N_MULTI_MAIN_SETUP_ENABLED). Bu, çoğu kurulum için gereğinden fazladır — worker eklemek genellikle yeterli olur.

Sık Karşılaşılan Hatalar ve Çözümleri

1. ”Webhook adresi localhost:5678 görünüyor.” WEBHOOK_URL ve N8N_EDITOR_BASE_URL ayarlanmamış veya konteyner yeniden başlatılmamış. .env dosyasına ekleyip docker compose up -d çalıştırın. Bu, ters proxy arkasında kurulum yapan yeni kullanıcıların en sık karşılaştığı sorundur çünkü n8n dışarıdaki gerçek adresi kendi başına bilemez.

2. ”Kimlik bilgileri çözülemiyor / entegrasyonlar bozuldu.” Encryption key değişmiş. Eski anahtarı bulup geri koyun. Bulunamıyorsa tek çözüm, tüm kimlik bilgilerini yeniden girmektir — bu yüzden anahtarı ayrı saklamak kritik. Bu hata genellikle sunucu taşıma veya yedekten dönme sırasında, encryption key’in yedeğe dahil edilmemesi durumunda ortaya çıkar.

3. ”Sertifika alınamıyor / SSL hatası.” Üç şeyi kontrol edin: DNS A kaydı sunucuya çözümleniyor mu, 80 ve 443 portları güvenlik duvarında açık mı, Caddyfile’daki domain .env dosyasındakiyle birebir aynı mı. Let’s Encrypt doğrulaması 80 portu üzerinden yapılır; o kapalıysa sertifika alınamaz. DNS yayılmasını beklemeden SSL adımına geçmek de bu hatanın yaygın bir sebebidir.

4. ”Arayüz çok yavaşladı.” Neredeyse her zaman şişmiş çalıştırma verisi. EXECUTIONS_DATA_PRUNE=true ayarını açın ve EXECUTIONS_DATA_MAX_AGE değerini düşürün. Veritabanı boyutunu kontrol edin. Aylarca temizlik yapılmadan biriken çalıştırma kayıtları, orta ölçekli bir kurulumda bile veritabanını gigabaytlarca büyütebiliyor.

5. ”Konteyner sürekli yeniden başlıyor.” Logları okuyun: docker compose logs n8n. En sık iki sebep — PostgreSQL bağlantı bilgileri hatalı veya ~/.n8n klasörünün izinleri yanlış. .env dosyasındaki veritabanı parolasının docker-compose.yml ile birebir eşleştiğinden emin olun.

6. ”Akış elle çalışıyor ama otomatik tetiklenmiyor.” Akışın sağ üstteki Active anahtarı açık mı? n8n’de bir akış aktif edilmeden zamanlanmış ve webhook tetikleyicileri çalışmaz. Yeni başlayanların en sık takıldığı nokta budur — akış düzgün kurulmuş olsa bile bu tek anahtar unutulduğunda hiçbir otomatik tetikleme gerçekleşmez.

7. ”Belleğe sığmıyor / konteyner çöküyor.” Büyük veri işleyen akışlarda yaygındır. Çözümler: kayıtları toplu değil parça parça işlemek (batch), büyük dosyaları bellek yerine diske/S3’e almak (N8N_DEFAULT_BINARY_DATA_MODE), ya da sunucu RAM’ini artırmak. Binlerce satırlık bir tabloyu tek seferde işlemeye çalışan akışlar bu hatayı en sık tetikleyen senaryodur.

8. ”Docker Compose başlamıyor / servisler birbirini bulamıyor.” Servis adlarının docker-compose.yml içinde ortam değişkenleriyle (DB_POSTGRESDB_HOST=postgres gibi) birebir eşleştiğinden emin olun. Konteynerler arası iletişim servis adı üzerinden çalışır, localhost üzerinden değil — bu ayrımı gözden kaçırmak yeni başlayanlarda sık görülen bir hatadır.

Kurulum Öncesi Kontrol Listesi

Sunucuya geçmeden önce aşağıdaki maddeleri netleştirmek, kurulum sırasında geri dönüp düzeltme yapmanızı önlüyor.

1. Cloud mu self-hosted mı sorusuna net bir cevabınız var mı? (Hacim, veri yerelliği ve teknik kapasite kriterlerine göre karar verin.)
2. Domain adınız hazır mı ve DNS paneline erişiminiz var mı?
3. Sunucu sağlayıcınızı seçtiniz mi ve RAM ihtiyacınızı beklenen akış hacmine göre belirlediniz mi?
4. Encryption key’i nerede saklayacağınızı (parola yöneticisi, secret servisi) önceden planladınız mı?
5. Yedekleme hedefinizi (S3, ayrı sunucu) belirlediniz mi — yedekler sunucunun kendisinde kalmamalı?
6. Ekipte kim yönetici (owner) hesabını alacak ve 2FA kimler için zorunlu olacak?
7. n8n’e bağlayacağınız entegrasyonların API anahtarlarını minimum yetkiyle üretmeyi planladınız mı?

Bu yedi maddeyi kurulum öncesinde netleştirmek, özellikle encryption key ve yedekleme kararlarını sonradan almaktan çok daha güvenli — çünkü bu ikisi, sonradan düzeltilmesi en maliyetli olan kararlar.

Vaka Kurgusu: Encryption Key Kaybının Maliyeti

Aşağıdaki senaryo, sektörde sık görülen bir örüntüyü göstermek için oluşturulmuş kurgusal bir örnektir; gerçek bir şirkete ait değildir.

Başlangıç durumu: Küçük bir dijital pazarlama ajansı, müşteri raporlama sürecini otomatikleştirmek için n8n’i tek konteynerli Docker kurulumuyla devreye alıyor. Encryption key’i elle belirlemek yerine n8n’in ilk açılışta ürettiği rastgele anahtara güveniliyor ve bu anahtar yalnızca sunucudaki ~/.n8n klasöründe saklı kalıyor.

Sorunun ortaya çıkışı: Altı ay sonra ekip, sunucu sağlayıcısını değiştirmeye karar veriyor. Veritabanı yedeği yeni sunucuya taşınıyor, ama ~/.n8n klasörü taşıma sürecinde atlanıyor — çünkü ekip bu klasörün önemini fark etmemiş. Yeni sunucuda n8n ilk açıldığında kendi rastgele anahtarını üretiyor.

Karşılaşılan durum: Akışlar arayüzde görünüyor ama hiçbiri çalışmıyor. Google Sheets, e-posta ve CRM entegrasyonlarının kimlik bilgileri “çözülemiyor” hatası veriyor. 15’in üzerinde akışta kullanılan API anahtarları, OAuth bağlantıları ve webhook kimlik doğrulamaları tek tek yeniden girilmesi gerekiyor.

Uygulama: Ekip, kaybı telafi etmek için üç gün harcayarak her entegrasyonu manuel olarak yeniden bağlıyor. Bu süreçte iki müşteri raporu gecikiyor. Olay sonrası ekip, encryption key’i elle üretip parola yöneticisinde saklamaya, ayrıca sunucu taşıma sürecine “n8n_data volume ve encryption key kontrolü” adımını standart prosedüre eklemeye karar veriyor.

Sonuç penceresi: Yeni prosedür sonrası yapılan bir sonraki sunucu taşımasında (10 ay sonra), encryption key kontrol listesinin ilk maddesi olduğu için sorun hiç yaşanmıyor ve geçiş kesintisiz tamamlanıyor.

Çıkarılan ders: Encryption key, n8n kurulumunun en az görünür ama en yüksek riskli bileşeni. Kurulumun ilk gününde beş dakikalık bir adımla önlenebilecek bu risk, göz ardı edildiğinde günler süren manuel bir kurtarma operasyonuna dönüşebiliyor.

(Vaka temsilidir.)

Güvenlik Kontrol Listesi

n8n, tüm sistemlerinize erişimi olan bir merkez haline gelir. Bu yüzden güvenliği bir otomasyon aracından fazlasını hak eder.

• 5678 portu dışarı kapalı — erişim yalnızca 443 üzerinden ters proxy ile
• HTTPS zorunlu — HTTP üzerinden asla çalıştırmayın
• Güçlü sahip hesabı parolası + 2FA
• Encryption key ayrı ve güvenli saklanıyor (parola yöneticisi veya secret servisi)
• .env dosyası git deposunda değil
• Kullanıcı bazlı hesaplar — ortak hesap paylaşımı yok
• Düzenli güncelleme — güvenlik yamaları için
• Yedekler sunucu dışında ve test edilmiş
• Entegrasyon anahtarları minimum yetkiyle — n8n’e verdiğiniz API anahtarı yalnızca ihtiyacı olan yetkilere sahip olsun
• SSH erişimi anahtar tabanlı, parola ile giriş kapalı

Son madde özellikle önemli: n8n’e verdiğiniz her API anahtarı, n8n’e erişen herkesin eline geçebilecek bir anahtardır. “Tam yetkili” anahtar vermek yerine, akışın gerçekten ihtiyaç duyduğu yetkiyle sınırlı bir anahtar üretin.

Türkiye’den Sunucu Seçimi ve Gecikme

Sunucu konumu, hem n8n’in kendi performansını hem de bağlandığı servislerle olan gecikme süresini etkiliyor. İki temel yaklaşım var.

Türkiye içi barındırma: Yerli bulut sağlayıcıları veya Türkiye’de veri merkezi bulunan uluslararası sağlayıcılar, ekip Türkiye’den erişiyorsa arayüz gecikmesini azaltıyor. Kişisel verinin yurt içinde kalması gereken durumlarda (KVKK kapsamındaki bazı veri türleri) bu tercih önem kazanıyor.

Avrupa merkezli barındırma: Almanya veya Hollanda gibi Avrupa veri merkezleri, hem Türkiye’ye makul bir gecikme mesafesinde hem de çoğu SaaS entegrasyonunun (Google, Microsoft, Stripe gibi) Avrupa sunucularına daha yakın. Çoğu self-hosted n8n kurulumu için pratik bir orta nokta oluşturuyor.

Karar kriteri: Akışlarınızın çoğu Türkiye içi servislerle (yerel bankacılık API’leri, yerli e-ticaret altyapıları, yerel SMS sağlayıcıları) çalışıyorsa Türkiye içi barındırma gecikmeyi azaltır. Akışlarınız ağırlıklı olarak uluslararası SaaS araçlarıyla (Google Workspace, Slack, HubSpot) çalışıyorsa sunucu konumunun etkisi daha sınırlı kalır — bu durumda maliyet ve destek kalitesi daha belirleyici kriterler haline gelir.

Sık Sorulan Sorular

Kurulum Sonrası: Hangi Akışla Başlamalı?

İlk akışınızı seçerken karmaşık bir süreç yerine düşük riskli, hızlı doğrulanabilir bir örnekle başlamak, kurulumun doğru çalıştığından emin olmanızı sağlıyor.

Bu sırayı izlemek, sorun çıktığında hangi bileşenin hatalı olduğunu hızlıca ayırt etmenizi sağlıyor. Karmaşık bir akışı ilk denemede kurup hata aldığınızda, sorunun ağ erişiminde mi, kimlik doğrulamada mı, yoksa akış mantığında mı olduğunu ayırt etmek çok daha zor oluyor.

Sonuç

n8n kurulumunun teknik kısmı, Docker Compose ile bir öğleden sonrada tamamlanır. Kurulumu uzun vadede sorunsuz kılan şey ise ilk gün yapılan dört tercihtir:

1. PostgreSQL ile başlamak — sonradan geçiş her zaman daha zahmetlidir
2. Encryption key’i kendiniz belirleyip ayrı saklamak — kaybı en pahalı hatadır
3. Yedeklemeyi ilk gün kurmak ve test etmek — test edilmemiş yedek, yedek değildir
4. Çalıştırma verisi temizliğini açmak — birkaç ay sonra yavaşlamanın bir numaralı sebebi budur

Bu dört madde, kurulumun geri kalanına kıyasla çok az zaman alır ama gelecekte karşılaşabileceğiniz en maliyetli sorunların büyük kısmını baştan engeller. Deneyimli n8n kullanıcılarının ortak gözlemi şu: kurulumla ilgili yaşanan ciddi sorunların büyük çoğunluğu, teknik bilgi eksikliğinden değil, bu dört adımdan birinin atlanmasından kaynaklanıyor.

Ölçekleme, izleme ve queue mode gibi konuları ihtiyaç doğduğunda ele alın. Baştan büyük kurulan altyapılar, çözülmemiş bir problemi yönetmek anlamına gelir.

Kurulumdan sonra en çok değer, otomasyonu genişlettikçe ortaya çıkıyor. İlk akışınızı doğruladıktan sonra ekip içindeki tekrar eden, kural bazlı işleri listeleyin — rapor gönderimi, veri senkronizasyonu, form işleme, bildirim akışları. Her biri, aynı sağlam altyapı üzerine eklenen küçük bir kazanım oluyor. Zamanla n8n, tek bir otomasyon aracından çok, şirketin iç sistemlerini birbirine bağlayan bir orkestrasyon katmanına dönüşebiliyor — bu dönüşüm, sağlam kurulan temel (PostgreSQL, encryption key yönetimi, yedekleme) üzerine güvenle inşa edilebiliyor.

n8n ile hangi süreçlerinizi otomatikleştirebileceğinizi konuşmak isterseniz yapay zeka otomasyon hizmetleri sayfasına bakabilir veya iletişime geçebilirsiniz.