Sosyal medya planlayıcımı kendi barındırdığım bir n8n iş akışıyla değiştirdim

Kanal başına ayda beş dolar. Yenileme ekranında sürekli baktığım sayı buydu, çünkü kaç yerde paylaşım yapabileceğime sessizce o karar veriyordu. Dört kanal, dört kere beş demekti. Sonradan ikinci bir marka eklersem fatura yine yükselecekti; hem de zaten kendi yazdığım aynı planlı gönderiler için.

n8n zaten iki alakasız otomasyon için bir VPS üzerinde çalışıyordu, ben de X, LinkedIn, Instagram ve Facebook için bunu bir n8n sosyal medya planlayıcısına dönüştürebilir miyim diye kendime bir hafta sonu verdim. Dört aydır çalışıyor. İşte bu değişimin bana gerçekte neye mal olduğu, nelerin bozulduğu ve hâlâ önermediğim durumlar.

Kısa Versiyon

• X, LinkedIn, Facebook ve Instagram'a aynı iş akışından paylaşım yapmayı başardım, ama dört dal aynı miktarda emek gerektirmedi.
• Sorun Instagram'dı: profesyonel hesap zorunluluğu, medya kuralları, yayınlama limitleri ve token yaşam döngüsü, Buffer'da hiç olmayan bir bakım yükü çıkardı.
• TikTok'u dışarıda bıraktım, çünkü n8n'in yerleşik uygulama düğümü kataloğunda yer almıyor ve özel ya da topluluk kaynaklı bir entegrasyonu paylaşım takvimimin parçası yapmaya niyetim yoktu.
• Community Edition yazılım ücretini kaldırdı, maliyeti değil. Barındırmayı yine ben ödedim; güncellemeler, kimlik bilgileri, yedekler, izleme ve başarısız gönderilerin kurtarılması bana kaldı.
• Kararım şu: geçiş buna değdi, çünkü yazma ile yayınlamayı tek bir hatta istiyordum. Sadece görsel bir takvim ve güvenilir kuyruklar isteseydim, olduğum yerde kalırdım.

Neye para ödüyordum ve terazi sonunda neyle döndü

Buffer'ın güncel fiyatlandırması yıllık faturalandırmada Essentials'ı kanal başına ayda 5 $ olarak listeliyor; ücretsiz plan ise üç kanala ve kanal başına on planlı gönderiye kadar destek veriyor. Dolayısıyla dört ücretli kanalım yıllık faturalandırmada ayda 20 $ ediyordu. Cilalı bir planlayıcıyı satmanın makul bir yolu bu, ama tam da genişletmek istediğim şeyi faturalandırıyordu: tek bir fikri aynı anda birkaç yer için yeniden biçimlendirmeyi.

Sonunda beni ikna eden fiyat olmadı. Gönderileri zaten ayrı bir pencerede bir modelle yazıyor, sonra elle planlayıcıya yapıştırıyordum. İki araç, apaçık tek bir hattı yürütüyordu. İstediğim iş akışını bir kez gördükten sonra, yazma ile yayınlamayı iki ayrı yarıda tutmak için abonelik ödemek bana anlamlı gelmez oldu.

İş akışım ne yapıyor

İş akışım bilerek sıkıcı. Bir Schedule Trigger günde birkaç kez tetikleniyor, Google Sheet'imdeki onaylı bir sonraki satırı okuyor, metni her platform için uyarlıyor, her sürümü kendi yayınlama dalına gönderiyor ve sonucu kaydediyor. Onay durumunu tabloda kendim tutuyorum ve yalnızca onayladığım satırları yayımlıyorum. Başarısız dallar n8n dışında bir uyarı tetikliyor, böylece bozuk bir kimlik bilgisi bir çalıştırma günlüğünün içinde kaybolamıyor.

Yazma adımı barındırılan bir modelin API'sini çağırıyor. Kısa bir süre aynı makinede model çalıştırmayı düşündüm, ama ayda birkaç düzine gönderide bir modeli kendi sunucunuzda barındırmanın maliyet unsurları maliyet unsurları API faturamdan büyüktü. Kullanım hacmi, gizlilik ya da gecikme bu kararı değiştirebilir, ama sırf sosyal medya gönderilerini yeniden yazmak için fazladan altyapı işletmemi gerektiren bir sebep yoktu. İş akışı zekice değil; ona güvenmemin bir nedeni de bu.

Platform platform gerçek durum (sorun Instagram)

Dört dalımın üçü büyük ölçüde olaysız geçti. Instagram, projenin geri kalanının tamamından daha fazla zamanımı yedi ve kaçan paylaşımları görmezden gelmenin benim için en zor olduğu platform oydu. Tablo, kullandığım ya da değerlendirdiğim yolları gösteriyor; altındaki ayrıntılar ise kurulumumu asıl etkileyen kısımlar.

LinkedIn tarafında, LinkedIn düğümü dokümantasyonu kişiler ve kurumlar için gönderi oluşturmayı kapsıyor, ayrıca n8n'in LinkedIn kimlik bilgileri kılavuzu kurum adına paylaşımın uygulamanızı LinkedIn'in Community Management App Review sürecinden geçirmek anlamına geldiğini belirtiyor. Bu, ihtiyacımı karşılıyordu. X kimlik bilgileri dokümantasyonu X'in geliştirici erişim planınızın seviyesine göre uç nokta başına zamana dayalı hız sınırları uyguladığını söylüyor. Benim paylaşım hacmimde tavana çarpmadım, ama bunu hâlâ n8n'in bir taahhüdü değil, X'in değiştirebileceği bir sınır olarak görüyorum.

Meta'nın içerik yayınlama kılavuzu belgelenen yol için JPEG'i desteklenen tek görsel formatı ve kayan 24 saatlik pencerede API üzerinden yayımlanan 100 gönderi sınırını belgeliyor. JPEG kuralı bana bir akşamıma mal oldu, çünkü dışa aktarımlarım varsayılan olarak PNG'ydi ve hata n8n'in içinden görünmüyordu. Bu yayınlama sınırını kalıcı saymak yerine güncel API yoluna ve sürümüne bağlı olarak değerlendiriyorum.

Dört ayda iki kez bozuldu. İki seferinde de Instagram. Uzun ömürlü erişim token'ları kalıcı değildir ve Meta'nın token yenileme referansı bir token'ın yalnızca süresi dolmamışken ve en az 24 saatlikken yenilenebileceğini söylüyor. O pencereyi kaçırırsanız yenileme artık kurtuluş yolu olmaktan çıkar. Benim hatam, kimlik doğrulamayı süregelen bakım değil de kurulum işi saymaktı. Bir yayınlama iş akışına süre dolumu izleme, erken yenileme ve yenileme başarısız olduğunda uyarı gerekir.

TikTok, kurduğum yeni düzenin parçası olmadı, bu kadar basit. Yerleşik uygulama düğümü kataloğu onu listelemiyor. HTTP Request düğümünü, özel bir düğümü ya da topluluk düğümünü kullanabilirdim, ama bu beni daha fazla kimlik bilgisi yönetiminden ve daha fazla arızadan sorumlu kılardı. Ben bir planlayıcıyı değiştiriyordum, bir platform entegrasyonunu daha sürdürmeye gönüllü olmuyordum.

Maliyet hesabı, kendi zamanım dahil

Referans olarak dört kanallı Buffer Essentials'ı aldım. Aşağıdaki yayımlanmış fiyatlar yıllık faturalandırmaya göredir ve Ağustos 2026'da doğrulanmıştır; dolar ve euro tutarlarını, doğrudan birbirine eşitmiş gibi göstermek yerine yayımlandıkları para biriminde bıraktım.

n8n'in bulut fiyatlandırması Starter'ı, dört Buffer Essentials kanalımla kabaca aynı giriş fiyat aralığına koyuyor. Bu, benim kullanım senaryomda yönetilen seçeneği bitirdi: bir iş akışı motoru için benzer bir aylık tutar ödeyecek, üstelik daha güzel yayınlama arayüzünü kaybedecektim. Community Edition karşılaştırması temel, kendi barındırdığım sürümü yazılım ücreti ödemeden kullanabileceğimi doğruladı; ama bu ne sunucuyu ne de zamanımı bedava yaptı.

Kendi makinemin boyutunu, 4 GB RAM ve 2 vCPU'luk evrensel bir üretim tabanına dönüştürmem de. n8n'in dağıtım ön koşulları geniş bir kaynak aralığı veriyor. Benim yüküm küçük, ama başka bir kurulum eşzamanlı çalıştırmalar, medya yükleri, kod adımları, veritabanı yükü ve daha uzun çalıştırma geçmişiyle hızla değişebilir. Dürüst cevap şu: iş yükünden başlayın ve belleği ile CPU'yu izleyin.

SQLite, n8n'in varsayılanıdır ve düşük hacimli, tek örnekli bir kurulum için gayet uygun olabilir. Yine de yürütme geçmişi önem kazandığında ya da dağıtımın büyümesi bekleniyorsa PostgreSQL'i tercih ediyorum. Dağıtık bir kuyruk modu kurulumu un ihtiyaç duyduğu şey de budur, çünkü n8n bu mimariyi SQLite üzerinde desteklemiyor. Bu kararı, iş akışı önem kazandıktan sonra veritabanı taşımaktansa kurulum aşamasında vermeyi tercih ederim.

Pahalı olan asla VPS değildi. Hafta sonumdu. Sonra JPEG yüzünden kaybettiğim akşam, token arızaları ve gönderilerin gerçekten çıkıp çıkmadığını sürekli kontrol etme işi geldi. Kendi saatlerime en ufak bir fiyat biçersem, tasarruf hızla erir ve eksiye dönebilir. İşte tam bu noktada kendi kendine barındırmak ucuz olmaktan çıkar. Geçişin buna değdiğini hâlâ düşünüyorum, ama ilk haftada bunu söyleyemezdim.

OKU

Indie Hacker'lar İçin Kendi Sunucunda Barındırılan Yığın: Devasa SaaS faturanızı değiştirmenin en iyi yolu

Neler bozuldu ve neyi değiştirdim

Görünen iki arıza Instagram token hatalarıydı, ama asıl derindeki sorun sessizlikti. Abonelikli bir planlayıcı bana hesap sorunlarını göstermek üzere tasarlanmış bir ürün yüzeyi sunuyor. İlk iş akışım n8n'in içinde çökebiliyordu ve dışarıdan görünen tek belirti, o gün hiç paylaşım olmamasıydı. Bu bana şunu öğretti: kendi barındırdığınız bir yayıncı yüksek sesle hata vermeli ve kopya üretmeden toparlanmalı.

• Hata uyarılarını n8n dışındaki bir kanala gönderiyorum ve platform yanıtı ile iş akışı çalıştırma kimliğini de ekliyorum; böylece bozuk olduğunu bana söylemesi için aynı sisteme muhtaç kalmıyorum.
• Token bitiş tarihlerini ve uygulama inceleme durumunu takip ediyorum; yenilemeyi de, planlı bir gönderi ilk uyarı hâline gelmeden önce yeniden yetkilendirmeye yetecek kadar erken test ediyorum.
• Yayımlamadan önce benzersiz bir içerik kimliği kaydediyorum; böylece başarısız olan platform dalı, zaten başarılı olan dallara yeniden göndermeden tekrar deneyebiliyor.
• n8n veri birimini ve veritabanını yedekliyorum ve geri yükleme testini yedeğin bir parçası sayıyorum; kopyalanmış dosyaların beni kurtaracağını varsaymıyorum.
• Sağlayıcının izin verdiği yerlerde API sürümlerini sabitliyorum, değişiklik günlüklerini okuyorum ve n8n ya da sağlayıcı tarafındaki her değişiklikten sonra tüm platform dallarını test ediyorum.
• Çalıştırma geçmişini ve medya dosyalarını gerçekten ihtiyacım olan saklama süresine göre buduyorum, çünkü sosyal medya görselleri minicik bir otomasyonu gereksiz yere kocaman bir yedeğe dönüştürebiliyor.

Bunu evimdeki bir makineden çalıştırmazdım. Sabah 9'a planlanmış bir gönderi, iş akışının 9'da ayakta olmasını gerektirir; ev elektriği, bağlantı, NAT ve gelen geri çağrılar ise bir içerik takviminde istemediğim değişkenler ekler. Bir VPS bu ev ağı değişkenlerini ortadan kaldırır; TLS, yedekler, izleme, güncellemeler ya da kurtarma konusundaki sorumluluğumu kaldırmaz.

Kimin buna girmemesi gerekir

İstediğiniz şey bir planlayıcıysa, ücretli planlayıcıda kalın. Bu bir teselli ödülü değil. Takvim, önizlemeler, basit onaylar, geniş kanal kapsamı ve asgari bakım sizin için aboneliğe değiyorsa, bunları satın almak doğru karardır. Özel otomasyona ihtiyaç yoksa, o arayüzü bir iş akışı tuvaliyle değiştirmek fazladan adımlarla gelen bir geriye gidiştir.

Buffer biçiminde ama size ait bir ürün istiyorsanız, n8n'den önce Postiz Postiz'e bakardım. Açık kaynak sürümü kendi sunucunuzda çalışabiliyor ve platform listesi, desteklenen 30'dan fazla kanal arasında TikTok'u da içeriyor. Bir iş akışı tuvali değil, bir yayın takvimi; bu da onu, ücretli bir planlayıcıdan ayrılan pek çok kişi için daha doğal bir varış noktası yapıyor.

Bunu yalnızca araştırma, yazma, onay, yayın ve kayıt tutmayı tek bir hatta istediğim için tekrar yapardım. Kabul ettiğim takas bu: bedava planlama değil, dikkatle ödenmiş denetim. İhtiyacım olan tek şey planlama olsaydı, aboneliğe geri dönerdim.

Aynı kendi barındırma yolunu izlemek isterseniz, tek tıkla n8n kurulumumuz ilk sunucu kurulumu adımını ortadan kaldırıyor. Benim daha önemli bulduğum işi kaldırmıyor: iş akışı kimlik bilgileri, platform onayları, güncellemeler, yedekler, izleme ve başarısız gönderilerin kurtarılması.

Sıkça Sorulan Sorular

Buffer yetkilendirmeleri n8n'e taşınır mı?

Hayır. Buffer'a verdiğim platform bağlantıları, Buffer'ın uygulamasına ve yetkilendirme akışına aitti. n8n iş akışımın kendi kimlik bilgilerine, token'larına, kapsamlarına ve hesap ya da yayınlama yolu için gereken her platform incelemesine ihtiyacı vardı.

Her sosyal platformun kendi dalı olmalı mı?

Genelde evet. Metni, medyayı, kimlik bilgilerini ve hata yönetimini her platform için ayrı ayrı uyarlayabilmek adına ayrı dallar kullandım. Bu sayede başarısız bir Instagram isteği, X ya da LinkedIn'de zaten başarılı olmuş bir gönderiyi yeniden yayımlamadan tekrar deneyebiliyordu.

Tek bir n8n iş akışı birden fazla müşteri için yayın yapabilir mi?

Evet, ama kimlik bilgilerini, içerik kaynaklarını, onay durumlarını ve günlükleri müşteri bazında ayırırdım. Platform izinleri ve kotaları hâlâ ilgili uygulama ve hesap için geçerli; dolayısıyla başarılı tek bir bağlantı asla evrensel erişim sayılmamalı.

Bir iş akışı kaçan gönderileri nasıl telafi etmeli?

Planlanan saati geçmiş, onaylı gönderileri sorguluyorum; sonra yalnızca başarılı sonucu olmayan kayıtları yayımlıyorum. Benzersiz bir içerik kimliği ve saklanan platform yanıtı, yeniden başlatma ya da yeniden denemenin zaten çıkmış gönderileri kopyalamasını engelliyor.