n8n Sunucu Gereksinimleri: Kaç GB RAM ve CPU Gerekir?

Kendi sunucunuzda n8n çalıştırırken kesinti yaşamamak için doğru n8n sunucu gereksinimleri tespiti yapmak kritik önem taşır. Hafif otomasyonlar için 2 GB RAM ve 2 vCPU yeterli olurken, yoğun veri aktaran süreçlerde tepe bellek ihtiyacına bağlı olarak 4 GB ya da 8 GB RAM gerekir. Donanım kapasitesi yetersiz kaldığında bellek tükenmesi sebebiyle süreçler işletim sistemi tarafından sonlandırılabilir ve veri kaybı oluşabilir.

Kısa cevap:

• Hafif zamanlanmış görevler ve seyrek API çağrıları için 2 GB RAM ile 2 vCPU dengeli bir başlangıçtır.
• Yoğun webhook trafiği, büyük veri dizileri ve yapay zeka adımları için 4 GB veya 8 GB RAM başlangıç önerisi olarak değerlendirilmeli, gerçek gereksinim temsilî iş yükü altında ölçülmelidir.
• Eşzamanlı çalışan ağır görevleri yönetmek için Queue Mode mimarisi planlanmalı ve kaynaklar buna göre artırılmalıdır.

Altyapı kurulum hazırlıklarıyla vakit kaybetmeden otomasyon projelerinizi hayata geçirmek isterseniz, Büyükweb tarafından sunulan hazır kurulu n8n VDS sunucu paketleri ile doğrudan iş akışlarınızı tasarlamaya başlayabilirsiniz.

n8n Otomasyonlarında RAM Tüketimini Artıran Faktörler (Büyük JSON, Webhook, AI Agent)

n8n, JavaScript tabanlı Node.js çalışma ortamında görev yapar. Node.js mimarisinin çalışma prensibi gereği yürütülen her akıştaki veri nesneleri, diziler ve değişkenler öncelikle sunucunun ana belleğinde tutulur. Düşük boyutlu metin aktarımlarında bellek tüketimi düşük seyreder. Ancak veri hacmi genişledikçe sunucu gereksinimleri doğrudan bellek kullanımına bağlı olarak artış gösterir. Node.js bellek sınırı aşıldığında uygulamanın çökmesi kaçınılmaz hale gelir.

Bellek kullanımını yükselten etkenlerin başında büyük JSON veri kümeleri ve ikili (binary) dosyalar gelir. Bir veritabanından, CRM yazılımından veya harici bir REST API ucundan tek seferde binlerce satırlık veri çekildiğinde, bu veri bloğu belleğe bütünüyle açılır. Akış içerisindeki her bir düğüm veriyi işlerken kendi bellek kopyasını oluşturabilir. Bu durum onlarca megabayt boyutundaki bir verinin akış boyunca katlanarak yüksek RAM harcamasına yol açar. Dosya aktarımlarında belleğin aşırı şişmesini engellemek amacıyla tekil kurulumlarda disk önbelleklemesi devreye alınabilir:

# Tekil kurulumlarda bellek kullanımını dengeleyen disk tabanlı ikili veri kipi
N8N_DEFAULT_BINARY_DATA_MODE=filesystem
N8N_BINARY_DATA_STORAGE_PATH=/home/node/.n8n/binaryData

Bu yapılandırmanın yalnızca tekil n8n kurulumlarında geçerli olduğunu unutmamak gerekir. İlerleyen süreçte iş yükünü dağıtmak amacıyla Queue Mode mimarisine geçildiğinde, ayrık sunucu veya konteynerlerde çalışan worker süreçleri ana sunucunun yerel diskine erişemez. Bu nedenle Queue Mode mimarisinde yerel dosya sistemi yerine n8n tarafından desteklenen paylaşımlı nesne depolama yöntemleri tercih edilmelidir.

İkinci önemli etken ise eşzamanlı gelen webhook çağrılarıdır. E-ticaret platformlarından gelen sipariş bildirimleri kısa zaman dilimlerinde yoğunlaşabilir. n8n, gelen her bir çağrı için ayrı bir yürütme (execution) bağlamı oluşturur. Tek bir iş akışı bellekte belirli bir alan kaplarken, aynı saniyede sisteme ulaşan onlarca webhook isteği anlık bellek ihtiyacını yukarı çeker. Sunucuda bu ani talebi karşılayacak boş alan bulunmadığında işletim sisteminin bellek yönetim servisi n8n sürecini durdurabilir.

Yapay zeka (AI) ve büyük dil modelleri (LLM) ile kurgulanan akışlar da bellek ihtiyacını yukarı taşır. AI Agent düğümleri, vektör veritabanı sorguları ve sohbet geçmişi kayıtları uzun metin dizilerini bellekte tutar. Dil modellerine gönderilen ve modelden dönen veriler yapılandırılmış nesnelere dönüştürülürken işlemci döngülerini de uzatır. Donanım dağılımı planlanırken VDS RAM ve CPU seçimi rehberi içeriğinde açıklanan işlemci ve bellek dengesini inceleyebilirsiniz.

Sistem kaynaklarının veritabanı şişmesi nedeniyle dolmasını önlemek için yürütme kayıt politikaları düzenlenebilir. Bu parametreler çalışan akışların o andaki bellek tüketimini doğrudan azaltmaz; ancak tamamlanan görevlerin loglarını sınırlandırarak disk üzerindeki yükü hafifletir:

# Başarılı kayıtları kapatan ve eski yürütmeleri budayan yapılandırma
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168

Bu ayarlar uygulanırken operasyonel etkiler dikkate alınmalıdır. Başarılı yürütme verilerinin saklanması kapatıldığında, başarıyla tamamlanan akışların detayları ve girdi-çıktı verileri arayüz üzerinden geriye dönük incelenemez. Hata ayıklama süreçlerinde yalnızca başarısız olan kayıtlar görünür olacağı için denetim ihtiyacı dikkatle değerlendirilmelidir.

Günlük Çalışma (Execution) Sayısına Göre n8n VDS Seçim Tablosu (2GB, 4GB, 8GB RAM)

n8n altyapısı için sunucu seçerken yalnızca 24 saatlik toplam yürütme sayısı tek başına yeterli bir ölçüt değildir. Gün içine dengeli dağılmış görevler ile kısa bir zaman aralığında tetiklenen anlık yoğunluklar sisteme tamamen farklı yükler bindirir. Sağlıklı bir sunucu boyutlandırması yapabilmek için temsilî iş akışlarının tepe anlardaki bellek kullanımı ve eşzamanlılık seviyesi ölçülmelidir.

Aşağıdaki tablo, iş yükü karmaşıklığı ve eşzamanlılık profillerine göre planlama yapmanıza yardımcı olacak genel kapasite göstergelerini özetlemektedir:

İş Yükü ve Profil Tipi	Tavsiye Edilen RAM	Tavsiye Edilen vCPU	Depolama Alanı	Senaryo Özellikleri
Düşük Eşzamanlılık / Hafif	2 GB	2 vCPU	30 GB NVMe	Basit API tetikleyicileri, periyodik veri çekme, tekil e-posta bildirimleri
Orta Hacimli / Karma Akışlar	4 GB	2 - 4 vCPU	50 GB NVMe	CRM veri eşitleme, sipariş akışları, düzenli webhook istekleri
Yüksek Tepe Bellek / AI Akışları	8 GB	4 vCPU	80 GB NVMe	Büyük veri ayrıştırma, AI Agent zincirleri, yoğun webhook trafiği
Dağıtık İş Yükü (Kuyruk Mimarisi)	16 GB ve üzeri	8 vCPU	120 GB NVMe	Queue Mode mimarisi, ayrık worker süreçleri, kurumsal otomasyonlar

Giriş düzeyindeki 2 GB RAM kapasitesine sahip bir sanal sunucu, kişisel projeler ve hafif görevler için dengeli bir ortam sağlar. Ancak işletim sistemi ve arka plan konteyner servislerinin de belirli bir bellek payına ihtiyaç duyduğu unutulmamalıdır. Düşük hacimli periyodik işlerde bu kapasite yeterli olurken, birden fazla ağır akış aynı anda çalıştığında bellek yetersizliği riski doğabilir.

Düzenli veri transferlerinin gerçekleştiği senaryolarda 4 GB RAM ve 2 ya da 4 vCPU içeren konfigürasyonlar operasyonel rahatlık sağlar. Eşzamanlı isteklerin fazlalaştığı ve bellek gereksinimi yüksek düğümlerin devreye girdiği projelerde ise 8 GB RAM seviyesi hedeflenmelidir. Yürütme geçmişinin diske yazılması ve okunmasında gecikme yaşamamak adına NVMe depolama birimleri tercih edilmelidir. Otomasyon maliyetlerini değerlendirmek için n8n mi Zapier mi maliyet karşılaştırması yazımızı inceleyebilirsiniz.

Donanım seçiminde zamanlanmış görevlerin dağılımı da rol oynar. Gece saatlerinde aynı dakikaya ayarlanan çok sayıda senkronizasyon görevi işlemciyi tepe noktaya ulaştırabilir. Görevlerin başlangıç dakikalarını günün farklı anlarına yaymak sunucu kaynaklarının dengeli kullanılmasını mümkün kılar.

SQLite vs PostgreSQL: Ne Zaman Veritabanını Ayırmalısınız?

n8n varsayılan kurulumunda gömülü SQLite veritabanı motorunu kullanır. SQLite, tüm tabloları tek bir dosya içinde tuttuğu için harici bir veritabanı servisi yapılandırma gereksinimini ortadan kaldırır. İlk testleri gerçekleştirmek veya hafif ölçekli otomasyonları yürütmek adına pratik bir çözümdür. Ancak eşzamanlı işlem yükü arttığında SQLite mimarisinin dosya kilitleme yapısı darboğaza yol açabilir.

SQLite, veritabanına yazma işlemi yaparken dosya düzeyinde kilitleme (database-level locking) uygular. Aynı anda birden fazla webhook çağrısı veri yazmaya çalıştığında veya arka arkaya yürütme logları kaydedilmek istendiğinde diğer yazma istekleri kilit açılana kadar bekletilir. Bekleme süresi aşıldığında sistemde kilitlenme hataları görülmeye başlar:

# SQLite eşzamanlı yazma kilitlenme hatası örneği
Error: SQLITE_BUSY: database is locked
    at Database.run (/usr/local/lib/node_modules/n8n/node_modules/sqlite3/...)

Harici bir konuma yedek almak veya geçmiş kayıtları uzun süre tutmak kendi başına SQLite kullanımını imkansız kılmaz. Ancak aşağıdaki operasyonel koşullar oluştuğunda PostgreSQL veritabanına geçiş yapılmalıdır:

1. Eşzamanlı yazma trafiği nedeniyle kilitlenme hataları sıklaştığında,
2. Anlık olarak sisteme ulaşan webhook sayısı artıp yürütme kayıtları geciktiğinde,
3. İş yükünü birden fazla worker sürecine dağıtacak Queue Mode mimarisine geçiş planlandığında,
4. Veritabanı kaynak tahsisinin ve indeksleme performansının bağımsız yönetilmesi istendiğinde.

PostgreSQL, satır düzeyinde kilitleme (row-level locking) ve bellek havuzu yönetimi sayesinde aynı anda gelen çok sayıda yazma isteğini rahatça işler. SQLite'tan geçişte yalnızca ortam değişkenlerini değiştirmek mevcut iş akışlarını ve kimlik bilgilerini aktarmayacağı için öncelikle tam yedek alınıp desteklenen veri taşıma adımları tamamlanmalı, ardından Docker ortamında PostgreSQL bağlantı değişkenleri n8n konteynerine tanımlanmalıdır:

# PostgreSQL bağlantı parametreleri
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_user
DB_POSTGRESDB_PASSWORD=[GIZLENDI]

Bu veri mimarisini kendi ortamınızda yapılandırmak için n8n self-host Docker Compose rehberi içerisindeki adımları uygulayabilirsiniz. PostgreSQL servisinin çalışması sunucu genelinde ilave bellek tüketeceğinden, veritabanı ayrımı planlanan sistemlerde sunucu RAM kapasitesi buna göre belirlenmelidir.

Queue Mode (Redis + Worker) Kurulumu Ne Zaman Gerekir?

Standart n8n kurulumunda tüm bileşenler tek bir süreç içerisinde çalışır. Kullanıcı arayüzü, tetikleyiciler, webhook dinleyicileri ve iş akışı adımları aynı çekirdek süreç tarafından yönetilir. Bu yapı "Single Instance" olarak tanımlanır. Görev hacmi sınırlı olduğunda tekil yapı yeterli yanıt süresi sunar. Ancak iş akışları karmaşıklaştığında işlemler birbirini sıraya sokabilir. Bu aşamada n8n Kuyruk Modu (Queue Mode) devreye alınmalıdır.

Queue Mode mimarisi iş akışlarının yürütülmesini bağımsız parçalara ayırır:

• Main (Ana Süreç): Kullanıcı arayüzünü, iş akışı tanımlarını, zamanlanmış tetikleyicileri ve varsayılan olarak webhook çağrılarını karşılayarak işleri kuyruğa aktarır.
• Webhook Instance (İsteğe Bağlı): Yoğun webhook trafiği alan yapılarda ana sürece yük bindirmemek adına çağrıları karşılamak için müstakil bir webhook süreci konumlandırılabilir.
• Worker (İşçi Süreçler): Redis üzerinde biriken görev kuyruğundaki işleri sırayla çeker, akış adımlarını yürütür ve sonuçları doğrudan PostgreSQL veritabanına kaydeder.

Bu mimariye geçiş kararında ana gösterge, görevlerin bekleme süreleri ve sistem yanıtlarındaki gecikmelerdir. Tetiklenen bir akışın başlaması gecikiyorsa veya arayüz yoğun işlemler sırasında yavaşlıyorsa Queue Mode değerlendirilmelidir. Kuyruk yapısını etkinleştirmek için n8n üzerinde Redis parametreleri tanımlanır:

# Queue Mode yapılandırması için kullanılan ortam değişkenleri
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

Node.js, JavaScript kodlarını temel olarak tek bir ana olay döngüsü (event loop) üzerinde yürütür; dosya ve bazı şifreleme işlemleri iş parçacığı havuzunu kullanırken, ağ soketi işlemleri işletim sisteminin engellemesiz G/Ç mekanizmalarıyla yönetilir ve ağ G/Ç'si kendiliğinden diğer CPU çekirdeklerine dağıtılmaz. Ağır JavaScript hesaplamaları içeren akışlarda işlemci çekirdeklerinden dengeli biçimde yararlanabilmek için birden fazla worker süreci çalıştırılabilir. Yine de her işlemci çekirdeği için ayrı bir worker açmak zorunlu değildir; iş yükünün niteliği analiz edilerek tek bir worker ile de dengeli bir çalışma ortamı sağlanabilir.

Uzun süren dosya dönüşümleri veya harici API beklemeleri içeren senaryolarda worker süreçlerinin aynı anda işleyeceği görev sayısını sınırlamak bellek taşmalarını engeller:

# Worker başına eşzamanlı yürütülecek iş sayısı sınırı
N8N_CONCURRENCY_PRODUCTION_LIMIT=5

Sunucu sanallaştırma mimarisi ve tahsis edilen kaynakların izolasyonu hakkında teknik ayrıntılar için VDS nedir rehberi başlıklı makalemize göz atabilirsiniz.

Docker Kurulumuyla Uğraşmadan Hazır n8n Sunucu Kullanmanın Avantajı

Kendi n8n sunucunuzu sıfırdan kurmak tam denetim sağlasa da işletim sistemi bakımı, konteyner dizinlerinin hazırlanması, ağ kurallarının tanımlanması ve ortam parametrelerinin yapılandırılması gibi teknik süreçleri beraberinde getirir. Yapılandırma hataları veya eksik bırakılan dosya izinleri otomasyon servislerinin duraksamasına neden olabilir.

Hazır n8n sunucu şablonları tercih edildiğinde uygulama ortamı sunucuda kullanıma hazır teslim edilir. Kullanıcılar komut satırı üzerinde Docker Compose dosyalarıyla veya ortam değişkenleriyle vakit kaybetmeden doğrudan yönetim paneline bağlanabilir. Böylece sunucu altyapısıyla ilgili hazırlık adımları hızla geçilerek iş akışlarının geliştirilmesine odaklanılabilir.

Donanım katmanında NVMe disk kullanan ve Intel Xeon işlemcilerle desteklenen sanal sunucular, veritabanı okuma-yazma hızını yüksek seviyede tutar. Ağ gecikmelerini düşük seviyede tutmak ve yerel servislerle hızlı haberleşmek adına veri merkezinin konumu da önem taşır. Konuyla ilgili kriterleri değerlendirmek için Türkiye'de VDS satın alma rehberi içeriğini inceleyebilirsiniz.

İş akışlarınızın karmaşıklığına, tepe anlardaki bellek kullanımına ve eşzamanlılık hedeflerinize uygun donanım profilini belirledikten sonra bir sonraki adıma geçebilirsiniz. Teknik detaylarla zaman kaybetmeden projelerinizi devreye almak için Büyükweb'in n8n VDS çözümlerini inceleyebilir, ihtiyaçlarınıza uygun yapılandırmayı seçerek otomasyonlarınızı hemen çalıştırmaya başlayabilirsiniz.

Sık Sorulan Sorular

n8n için 1 GB RAM yeterli olur mu?

1 GB RAM, hafif iş akışlarında yeterli olabilir. 2 GB RAM zorunlu bir alt sınır olmamakla birlikte, işletim sistemi ve temsilî iş yükünün bellek tüketimi dikkate alındığında kararlı bir çalışma için önerilen bir başlangıç seviyesidir.

n8n disk alanını neden hızlı tüketir?

n8n varsayılan yapılandırmada tamamlanan veya hata veren tüm akışların girdi, çıktı ve yürütme kayıtlarını veritabanına yazar. Yoğun veri aktaran süreçlerde bu kayıtlar ve ikili dosya artıkları zamanla depolama alanını doldurur. Ortam değişkenlerinden otomatik veri budama yapılandırılarak ve gereksiz başarılı kayıtlar kapatılarak disk kullanımı dengede tutulmalıdır.

n8n neden tüm CPU çekirdeklerini kullanmıyor?

Node.js platformu JavaScript kodlarını tek bir ana olay döngüsü üzerinde çalıştırır; ağ işlemleri çoğunlukla işletim sisteminin engellemesiz G/Ç mekanizmalarıyla, dosya işlemleri gibi bazı işler ise iş parçacığı havuzuyla yürütülse de yoğun hesaplamalar tek çekirdekte toplanabilir. Çok çekirdekli sistemlerde işlem gücünden yüksek verim almak için Redis tabanlı Queue Mode mimarisine geçilerek iş yükü bağımsız worker süreçlerine paylaştırılabilir.

n8n güncellemesi sırasında verilerim silinir mi?

Docker kalıcı veri alanı bağlantıları yapılandırma dosyalarınızı korusa da yeni n8n sürümleri ilk açılışta otomatik veritabanı şema geçişleri uygular. Bu şema güncellemeleri veri yapısını kalıcı olarak değiştirebilir. Olası uyumsuzluklara karşı güncelleme öncesinde çalışan veritabanının ve n8n şifreleme anahtarının geri yüklenebilir bir yedeği alınmalıdır.