· kaynak dev.to (home feed)
n8n 2.0 task runner'ları varsayılan olarak etkinleştiriyor ve Code node ortam değişkeni erişimini engelliyor
n8n 2.0, Code node'ları, Python yürütme, komut node'ları, dosya erişimi ve veritabanı arka uçları için varsayılanları değiştiriyor; bu nedenle değiştirilmeyen iş akışları yükseltmeden sonra farklı davranabilir.

n8n 2.0 bir özellik paketi değil, varsayılanları değiştiren bir sürüm ve bu ayrım, iş akışı otomasyon platformunu üretimde çalıştıran herkes için önemli. dev.to'da yayımlanan bir inceleme, gerçek yükseltme sorusunun mevcut iş akışlarının hâlâ açılıp açılmadığı değil; aynı girdiler, izinler, yan etkiler ve çıktılarla çalışmaya devam edip etmediği olduğunu savunuyor.
Task runner'lar artık varsayılan olarak açık
Öne çıkan değişiklik, task runner'ların etkin olarak gelmesi ve Code node yürütmelerinin bunlardan geçmesi. Bunun sağladığı yalıtım bir güvenlik iyileştirmesi, ancak 1.x altında çalışan kodun yükseltmeden sonra farklı davranabileceği anlamına da geliyor. dev.to yazarı, uyumluluk sorunlarının sürüm atlamasından önce ortaya çıkması için güncel bir 1.x kurulumunda önce N8N_RUNNERS_ENABLED=true ayarının yapılmasını öneriyor.
Code node'lar ortam değişkeni erişimini kaybediyor
N8N_BLOCK_ENV_ACCESS_IN_NODE artık varsayılan olarak true; bu nedenle process.env.MY_API_KEY okuyan bir Code node, ayar gevşetilmedikçe başarısız olacak. Önerilen çözüm yapısal: Code node'ları sır saklama yeri olarak kullanmayı bırakmak ve bunları n8n credential'ları üzerinden yönlendirmek — örneğin, bir HTTP Request node'unu ortamdan çekilen bir anahtarla beslemek yerine bir credential ile beslemek. Makale, bu kalıbın ayrıca bakımının da daha kolay olduğunu belirtiyor.
$evaluateExpression Code node'lar içinde kırılıyor
Güvenli task-runner modeli altında $evaluateExpression() eskisi gibi Code node içinde çalışmıyor ve n8n bunu bir breaking change olarak belgeliyor. Önerilen alternatifler, ifadeyi Edit Fields gibi önceki bir node'da değerlendirip sonucu Code node'a aktarmak ya da mantığı düz JavaScript olarak yeniden yazmak. n8n ayrıca güvenli olmayan mod için bir geçici çözüm belgeliyor, ancak makale bunu üretim çözümü değil, geçici bir uyumluluk seçeneği olarak çerçeveliyor.
Python yürütmesi Pyodide'den ayrılıyor
Pyodide tabanlı Python uygulaması kaldırıldı ve Python Code node'ları artık task-runner modeli altında çalışıyor; bu da task runner'ların harici modda olmasını gerektiriyor. Yeni ortam, Pyodide sürümünün sunduğu aynı yerleşik değişkenleri desteklemiyor ve _input'a dayanan kodun gözden geçirilmesi gerekiyor. Node hâlâ Python adını taşıdığı için hiçbir şeyin değişmediğini varsaymak cazip; makale buna karşı uyarıyor ve Python kodu, Code node'ları ve Python araçlarına sahip AI agent'lar içeren her iş akışını denetleyip her birini test etmeyi öneriyor.
Komut ve dosya tetikleyici node'ları devre dışı
Komut çalıştırabilen veya dosya sistemiyle etkileşime girebilen ExecuteCommand ve LocalFileTrigger varsayılan olarak kapatıldı. Bir webhook'u ExecuteCommand'a bağlayan bir iş akışı, yükseltmeden sonra otomatik olarak çalışmaya devam etmeyecek. Makale, bu node'lardan hangilerinin gerçekten gerekli olduğunu gözden geçirmeyi ve bunları NODES_EXCLUDE gibi node-availability yapılandırmasıyla yeniden etkinleştirmeyi, eski bir kurulumdan taşınan bir şey değil, bilinçli bir altyapı kararı olarak ele almayı tavsiye ediyor.
Yerel dosya erişimi kapsamlandı
Dosya işlemleri artık varsayılan olarak kısıtlanmış durumda; ilgili işlemler için izin verilen konum ~/.n8n-files. PDF, görsel, CSV, belge, üretilen raporlar veya yüklenen dosyalar işleyen self-hosted kurulumlar, dosya sistemi node'ları kullanan her iş akışını belirlemeli ve yükseltmeden önce yollarını kontrol etmeli.
Veritabanı hikâyesi iki kez değişiyor
MySQL ve MariaDB, n8n'ın kendi deposu için kullandığı veritabanı olarak artık desteklenmiyor; uzun vadeli uyumluluk için PostgreSQL öneriliyor. Makale yararlı bir ayrım yapıyor: uygulama veritabanlarına bağlanmak için kullanılan MySQL node'u hâlâ çalışıyor ve değişiklik yalnızca n8n'ın dahili veritabanını ilgilendiriyor. n8n'ı MySQL veya MariaDB üzerinde çalıştıran herkesin yükseltmeden önce geçiş yapması gerekiyor.
SQLite da bir sürücü değişikliği yaşıyor: eski sürücü, WAL modu, bir yazma bağlantısı ve okuma bağlantılarından oluşan bir pool kullanan pooled bir sürücüyle değiştirildi. Makaleye göre n8n'ın kıyaslamaları, pooled kurulumu önceki hâlinden 10 kata kadar hızlı gösteriyor; ancak gerçek performans iş yüküne bağlı. DB_SQLITE_POOL_SIZE=2 ayarı, pooled davranışı yükseltmeden önce denemenizi sağlıyor.
dev.to yazısı ayrıca OAuth, ikili veri (binary data) ve iş akışı yayımlama çevresindeki değişikliklere de dikkat çekiyor, ancak ayrıntılı rehberi yukarıdaki alanları kapsıyor.
Neden önemli
n8n 2.0, platformu izin verici varsayılanlardan güvenli varsayılanlara taşıyor: yalıtılmış kod yürütme, engellenmiş ortam erişimi, devre dışı komut node'ları ve kapsamlandırılmış dosya erişimi. Bu doğru bir uzun vadeli duruş, ama maliyeti yükseltme gününde ortaya çıkıyor; çünkü kimsenin düzenlemediği iş akışları, izinler ve yürütme hakkındaki varsayımları geçersiz olduğunda kırılabiliyor. Geçiş kontrol listesi doğrudan değişikliklerden kaynaklanıyor: task runner'ları 1.x'te test edin, Code node'larda process.env ve $evaluateExpression arayın, Python kullanımını denetleyin, komut ve dosya sistemi node'larını tek tek sayın ve n8n'ın hangi veritabanı üzerinde çalıştığını doğrulayın. Bu ödevi yapan ekipler güvenlik iyileştirmelerini kazanır; 2.0'ı sıradan bir sürüm güncellemesi olarak gören ekip ise breaking change'lerle büyük olasılıkla çalışma ortasında karşılaşacak olanlar olacak.
- #n8n
- #workflow-automation
- #self-hosted
- #release-notes
- #security