n8n ile İş Akışı Otomasyonu: Nasıl Çalışır, Nerede Sınırı Var

Otomasyon araçlarının hepsi aynı vaadi verir: tekrarlayan işi sen yapma, sistem yapsın. n8n bunu teknik ekiplere göre kurar. Akışın her adımına kod yazabilirsin, tamamını kendi sunucunda çalıştırabilirsin. Fark buradan başlar, entegrasyon sayısından değil.

Bir iş akışı aslında nedir

Kavramı sıfırdan kuralım. n8n'de her akış bir tetikleyiciyle başlar: gelen bir webhook isteği, saat başı çalışan bir zamanlayıcı, bir tabloya eklenen yeni satır. Tetikleyici bir veri paketi üretir ve bu paket düğümden düğüme geçer. Her düğüm gelen veriyi alır, üzerinde bir şey yapar, çıktısını sonrakine verir.

Mantık Unix borusuna benziyor. Aradaki fark, parçaların JSON taşıması ve her adımın büyük ihtimalle bir ağ çağrısı olması. Yani bir akış tasarlarken düşünmen gereken şey, hangi kutuyu nereye sürükleyeceğin değil, verinin hangi biçimde girip hangi biçimde çıkacağı.

Yeni başlayanların en sık takıldığı nokta şu: n8n düğümler arasında tek bir nesne değil, bir öğe listesi taşır. Bir düğüm elli kayıt döndürdüyse sonraki düğüm elli kez çalışır. Bu davranışı fark etmeden kurulan akışlar, test verisinde kusursuz görünüp gerçek veride elli e-posta gönderir.

n8n'i ayıran şey entegrasyon sayısı değil

Karşılaştırma tablolarında n8n'in 1200'den fazla entegrasyonu olduğu yazar. Aynı tabloda Zapier'ın 3000'den fazlası vardır. Yani entegrasyon sayısını üstünlük argümanı olarak kullanmak, n8n'in kendi aleyhine çalışır.

Özellik	n8n	Zapier	Make
Kod yazma	JavaScript / Python	Sınırlı	Sınırlı
Barındırma	Kendi sunucun veya bulut	Sadece bulut	Sadece bulut
Kaynak koda erişim	Var	Yok	Yok
Hazır entegrasyon	1200+	3000+	1000+

Asıl fark, listede olmayan servisi ne kadar kolay bağlayabildiğin. n8n'de HTTP Request düğümü ve Code düğümü var; bir servisin hazır entegrasyonu yoksa API dokümanını açıp isteği kendin kurarsın, dönen veriyi birkaç satır JavaScript ile şekle sokarsın. Bu yüzden hazır entegrasyon listesi bir tavan değil, taban. Kapalı platformlarda ise listede olmayan servis çoğu zaman gerçekten yok demektir.

Kod düğümünün ikinci faydası hata ayıklamada ortaya çıkıyor. Akışın tamamını baştan çalıştırmadan tek bir düğümü yeniden koşturabiliyorsun, o düğümün girdi ve çıktısını ham JSON olarak görebiliyorsun. On adımlık bir akışta yedinci adım patladığında bunun ne kadar zaman kazandırdığını ilk denemende anlarsın.

"Açık kaynak" burada ne anlama geliyor

n8n çoğu yerde açık kaynak diye anılır ama tam olarak öyle değil. Sustainable Use License adı verilen, geliştiricilerin fair-code dediği bir lisansla dağıtılıyor. Kaynak kodun tamamı GitHub'da, kendi sunucunda çalıştırabiliyorsun, şirket içi kullanımda bir kısıt yok. Kısıt şurada: n8n'i barındırıp müşterilerine hizmet olarak satamazsın.

Ekiplerin büyük çoğunluğu için bu ayrımın pratik bir sonucu yok. Ama otomasyonu kendi ürününün bir parçası olarak müşteriye sunmayı düşünüyorsan, mimariye başlamadan önce lisans metnini okumak gerekiyor. OSI onaylı bir lisansın verdiği garantileri buradan bekleme.

Kurulum ve ilk akış

Kurulumu genelde Docker Compose ile, ayrı bir Postgres konteynerine bağlayarak yaparım. Varsayılan SQLite tek kullanıcılık denemelerde sorunsuz çalışır, ama paralel çalışan akışlar arttığında kilitlenme hatalarıyla tanışırsın. Veritabanını baştan ayırmanın maliyeti on satır YAML, sonradan taşımanın maliyeti bundan çok daha fazla.

Kurulumda atlanan bir ayar var: N8N_ENCRYPTION_KEY. n8n, servislere ait API anahtarlarını ve parolaları bu anahtarla şifreleyip veritabanına yazar. Ortam değişkeni olarak belirtmezsen ilk açılışta rastgele üretilir ve konteynerin içinde kalır. O dosyayı kaybettiğin gün veritabanın duruyor olsa bile bütün kimlik bilgilerini elle yeniden girmen gerekir. Anahtarı kendin belirle ve yedekle.

İlk akış için tek bir tekrarlayan işi seç. Günde beş dakika süren, herkesin unuttuğu, sırası geldiğinde canını sıkan cinsten bir iş. Onu çalıştır, iki hafta gözle, sonra ikincisine geç. Otomasyon projelerinin çoğu, ilk denemede yirmi düğümlük bir canavar kurulmaya çalışıldığı için yarım kalıyor.

Vaka çalışmalarındaki rakamları nasıl okumalı

n8n'in kendi vaka çalışmalarında Delivery Hero'nun tek bir IT operasyonu akışıyla ayda 200 saatin üzerinde tasarruf ettiği, StepStone'da iki hafta süren bir işin iki saate indiği anlatılır. Rakamlar etkileyici ama neyi ölçtüklerine dikkat etmek gerekiyor.

İki haftadan iki saate inen bir iş, muhtemelen iki hafta boyunca birilerinin gelen kutusunda sıra beklediği için iki haftaydı. Kazancın büyük kısmı aracın hızından değil, elden ele dolaşan bekleme süresinin ortadan kalkmasından geliyor. Bu, otomasyonun değerini azaltmaz; nereden geldiğini doğru gösterir. Kendi süreçlerine bakarken de aynı soruyu sor: bu iş gerçekten uzun sürüyor mu, yoksa sadece uzun mu bekliyor? İkincisiyse otomasyondan büyük kazanç çıkar. Birincisiyse önce işin kendisini sadeleştirmen gerekiyor.

Ne zaman n8n, ne zaman başka bir şey

n8n, birden fazla servisin arasında duran, sık değişen, iş biriminin de görebilmesi gereken akışlar için iyi bir seçim. Görsel şema burada gerçek bir işlev görüyor: akışa altı ay sonra bakan kişi, kodu okumadan verinin nereden gelip nereye gittiğini anlıyor.

Buna karşılık tek bir sistemin içinde kalan, dışarıyla konuşmayan, mantığı karmaşık bir iş için görsel araç fayda değil yük getirir. Otuz satırlık bir betiği zamanlanmış göreve bağlamak hem daha hızlı hem de sürüm kontrolüne girdiği için daha izlenebilir. Aracı seçerken sorulacak soru şu: bu işin zor kısmı entegrasyon mu, yoksa mantık mı? Entegrasyonsa n8n, mantıksa editörün.