n8n Cloud paralel çalıştırmaları sınırlar: Starter 5, Pro 20, Enterprise 200+. Bunun toplu işlemeye etkisi ve batching'in nasıl yardımcı olduğu.
n8n Cloud'da her plan, kaç workflow çalıştırmasının aynı anda çalışabileceğini sınırlar: Starter plan 5 paralel çalıştırmaya izin verir, Pro plan 20'ye, ve Enterprise seviyesi n8n fiyatlandırma genel bakışına göre 200 veya daha fazla paralel çalıştırma seviyesindedir. Limit aşıldığında n8n, ek çalıştırmaları otomatik olarak bir kuyruğa alır ve tekrar kapasite boşaldığında bunları FIFO prensibine göre işler. Düzenli olarak büyük veri hacimleri işleyen şirketler için, örneğin toplu içe aktarmalar, toplu e-posta gönderimleri veya webhook tetikleyicileri üzerinden uzun listelerin işlenmesi gibi durumlarda, bu limit bir workflow oluşturulmadan önce bilinmesi gereken bir faktördür, aksi takdirde çalıştırmalar fark edilmeden kuyrukta birikebilir. Durum: Temmuz 2026.
Sınırlama, n8n'in Cloud concurrency ile ilgili dokümantasyonuna göre yalnızca üretim (production) çalıştırmaları için geçerlidir, yani bir webhook veya bir tetikleyici düğüm tarafından başlatılanlar için. Manuel test çalıştırmaları, alt workflow'lar (sub-workflow) ve hata workflow'ları buna dahil değildir ve limitten bağımsız olarak çalışmaya devam eder. Eşzamanlı üretim çalıştırmalarının sayısı plan değerini aşarsa, ek çalıştırmalar reddedilmez, bunun yerine bir kuyrukta bekler. Pratikte önemli olan: bekleyen çalıştırmalar yeniden denenemez (retry yoktur) ve bekleyen bir çalıştırmayı iptal eden kişi onu kuyruktan tamamen kaldırır. Bir instance yeniden başlatıldıktan sonra n8n, bekleyen çalıştırmaları kapasite sınırına kadar yeniden devam ettirir ve geri kalanını tekrar kuyruğa alır. Güncel doluluk durumu, bir projenin veya workflow'un çalıştırmalar sekmesinde doğrudan görülebilir.
Örneğin, bir webhook üzerinden 500 kaydı tek tek ayrı çalıştırmalar olarak tetikleyen biri, n8n'in kendisi herhangi bir hata mesajı göstermese bile, Starter planında ilk 5 eşzamanlı çalıştırmadan sonra otomatik olarak bir kuyrukla karşılaşır. Bu, genel işlemeyi geciktirir ancak kimse bekleyen çalıştırmaları iptal etmediği sürece veri kaybına yol açmaz. Bu durum, örneğin harici bir sistemin hızlı bir yanıt beklediği ve kuyruğun yanıt süresini öngörülemez şekilde uzattığı zaman kritik süreçlerde daha kritik hale gelir. Instance yeniden başlatmalarında da (örneğin bakım pencereleri nedeniyle) kuyruk, işlenmeden önce kısa süreliğine daha da büyüyebilir.
Birçok tekil üretim çalıştırmasını paralel olarak tetiklemek yerine, yük tek bir workflow içinde kontrol edilebilir. Pratikte yaygın yaklaşımlar:
Dürüst olmak gerekirse, bu püf noktalarından hiçbiri, kalıcı olarak daha fazla gerçek paralellik gerektiğinde daha yüksek bir plan seviyesinin yerini tutmaz. Batching yükü zaman içinde kaydırır ancak ek kapasite yaratmaz.
n8n'i kendisi işleten kişinin daha fazla esnekliği vardır: n8n'in concurrency kontrolüyle ilgili dokümantasyonuna göre, self-hosting'de sınırlama varsayılan olarak devre dışıdır ve kuyruk modunda dahil olmak üzere N8N_CONCURRENCY_PRODUCTION_LIMIT ortam değişkeni üzerinden özel olarak ayarlanabilir. Bu, kendi altyapısı üzerinde daha fazla kontrol anlamına gelir, ancak aynı zamanda daha fazla kişisel sorumluluk da getirir: bilinçli olarak belirlenmiş bir limit olmadan, bir instance ani bir yük artışında aşırı yüklenebilir. Tam olarak bu noktada, örneğin bir Cloud planının mı yoksa kendi altyapısının mı bir şirketin gerçek veri hacmine ve kontrol gereksinimlerine uygun olduğuna karar verirken, sağlam bir konsept devreye girer. NordFlux, tam olarak bu değerlendirme konusunda n8n danışmanlığı kapsamında destek sağlar.
Reddedilmezler, bunun yerine otomatik olarak bir kuyruğa alınırlar ve kapasite tekrar boşaldığında geliş sırasına göre (FIFO) işlenirler.
Hayır. Dokümantasyona göre, n8n Cloud'daki concurrency limiti yalnızca webhook veya tetikleyici düğüm üzerinden yapılan üretim çalıştırmalarını etkiler. Manuel çalıştırmalar, alt workflow'lar ve hata workflow'ları bunun dışındadır.
Hayır, bekleyen çalıştırmalar yeniden denenemez (retry). Onları iptal eden kişi, onları kuyruktan tamamen kaldırır ve bunların yeniden tetiklenmesi gerekir.
Bu, gerçek işlem hacmine bağlıdır. Düzenli olarak 5'ten belirgin şekilde daha fazla eşzamanlı üretim çalıştırmasına ihtiyaç duyan kişi, Starter planında kuyruk kaynaklı gecikmeleri daha sık yaşar. Batching bunu hafifletebilir, ancak kalıcı olarak yüksek hacimde daha yüksek bir plan seviyesinin yerini tutmaz.
NordFlux'un kurucusu. Webden ve SEO'dan grup ölçeğindeki otomasyona kadar yedi yıllık deneyim, bugün KOBİ'ler için pragmatik biçimde ve Alman veri egemenliğiyle.
Sertifikalar
n8n'in Self-hosted AI Starter Kit'i, bulut API'leri olmadan yerel YZ iş akışları için Docker Compose üzerinden n8n, Ollama, Qdrant ve PostgreSQL'i başlatır.
Community sürümü ücretsiz ve sınırsızdır, Business ayda 667 EUR'ya mal olur. Planları gerçekten neyin ayırdığı ve bir KOBİ'nin ne zaman Enterprise'a ihtiyaç duyduğu.
n8n workflow çalıştırması başına, Zapier ise eylem adımı başına ücretlendirir. Bu fark, otomasyonunuz için hangi planın gerçekten uygun olduğunu belirler.
n8n Cloud'da kuyruk büyümeye başlayınca batching yalnızca bir noktaya kadar yardımcı olur. Kendi barındırdığınız kurulumda concurrency, queue mode ve worker sayısını siz belirlersiniz; kurulumu ve günlük işletimi NordFlux üstlenir. Böylece kurulumunuz toplu işleri bile birikme olmadan işler.
