Csatornánként havi öt dollár. Ezt a számot bámultam a megújítási képernyőn, mert csendben ez döntötte el, hány helyre posztolhatok. Négy csatorna négyszer ötöt jelentett. Ha később egy második márkát is felveszek, a számla újra megugrik, ugyanazokért az ütemezett posztokért, amelyeket amúgy is én írtam.
Az n8n amúgy is futott már egy VPS-en két, ettől független automatizálás miatt, ezért adtam magamnak egy hétvégét, hogy kiderítsem, tudok-e belőle n8n közösségimédia-ütemezőt csinálni X-re, LinkedInre, Instagramra és Facebookra. Már négy hónapja fut. Íme, mibe került valójában a váltás, mi romlott el, és hol nem ajánlanám továbbra sem.
A rövid verzió
- Sikerült ugyanabból a munkafolyamatból posztolni X-re, LinkedInre, Facebookra és Instagramra, de a négy ág nem egyforma munkát igényelt.
- Az Instagram volt a gond: a professzionális fiók előírása, a médiaszabályok, a közzétételi korlátok és a tokenek életciklusa mind olyan karbantartást hozott, ami a Buffernél nem volt.
- A TikTokot kihagytam, mert az n8n beépített alkalmazáscsomópont-katalógusa nem tartalmazza, és nem akartam egyedi vagy közösségi integrációt beemelni a posztolási ütemtervembe.
- A Community Edition a szoftverdíjat szüntette meg, nem a költséget. A hosztolást továbbra is fizettem, és rám maradtak a frissítések, a hitelesítő adatok, a mentések, a felügyelet és a sikertelen posztok helyreállítása.
- Az ítéletem: a váltás megérte, mert egy csővezetékben akartam a fogalmazást és a közzétételt. Ha csak vizuális naptárt és megbízható sorokat akartam volna, maradtam volna.
Miért fizettem, és mi billentette végül a mérleget
A Buffer aktuális árazása az Essentialst havi 5 $-ban adja meg csatornánként éves számlázással, míg az ingyenes csomag legfeljebb három csatornát és csatornánként tíz ütemezett bejegyzést támogat. A négy fizetős csatornám így éves számlázással havi 20 $-ba került. Ez ésszerű módja egy kiforrott ütemező árusításának, csakhogy pontosan azért kért pénzt, amit bővíteni akartam: hogy egy ötletet több helyre is átformáljak egyszerre.
Végül nem az ár döntött. A posztokat amúgy is egy modellel írtam egy külön ablakban, majd kézzel másoltam be az ütemezőbe. Két eszköz csinált egyetlen nyilvánvaló csővezetéket. Amint láttam magam előtt a kívánt munkafolyamatot, értelmét vesztette előfizetést fizetni azért, hogy a fogalmazás és a közzététel két külön félben maradjon.
Mit csinál a munkafolyamatom
A munkafolyamatom szándékosan unalmas. Egy Schedule Trigger naponta néhányszor elindul, beolvassa a következő jóváhagyott sort a Google Sheetemből, platformonként igazítja a szöveget, mindegyik változatot a saját közzétételi ágába küldi, és rögzíti az eredményt. A jóváhagyás állapotát kézzel vezetem a táblázatban, és csak az általam jóváhagyott sorokat teszem közzé. A hibára futó ágak n8n-en kívüli riasztást indítanak, hogy egy elromlott hitelesítő adat ne tűnhessen el egy futási naplóban.
A fogalmazási lépés egy hosztolt modell API-ját hívja. Rövid ideig fontolgattam, hogy ugyanazon a gépen futtatok modellt, de havi néhány tucat posztnál egy modell saját üzemeltetésének költségtényezői nagyobbak voltak a költségtényezők, mint az API-számlám. A használat mértéke, az adatvédelem vagy a késleltetés felülírhatja ezt a döntést, de nem volt okom külön infrastruktúrát üzemeltetni pusztán azért, hogy közösségi posztokat írjak át. A munkafolyamat nem elmés, és részben épp ezért bíztam benne.
A valóság platformonként (az Instagram a gond)
A négy ágamból három nagyjából eseménytelenül futott. Az Instagram több időt vitt el, mint a projekt összes többi része együttvéve, és ez volt az a platform, ahol a kimaradt posztokat a legnehezebben hagytam figyelmen kívül. A táblázat az általam használt vagy megvizsgált utakat mutatja; alatta a részletek azok, amelyek ténylegesen hatottak a felállásomra.
| Platform | n8n-útvonal | Fő korlát | Ítélet |
|---|---|---|---|
| X | Beépített X-csomópont | A végpontkorlátok az X fejlesztői csomagtól függenek | API-hozzáféréssel működik |
| Beépített LinkedIn-csomópont | A szervezeti nevében való posztoláshoz LinkedIn-alkalmazásfelülvizsgálat kell | Jóváhagyás után működik | |
| Facebook Graph API-csomópont | Oldalengedélyek, tokenek és Graph API-verziók | Beállítás után működik | |
| Meta Graph API | Professzionális fiók, médiaszabályok, kvóták, tokenéletciklus | Működik, de karbantartás árán | |
| TikTok | Nincs beépített alkalmazáscsomópont a listán | HTTP-s, egyedi vagy közösségi integrációt igényel | Ha elengedhetetlen, használjon ütemezőt |
A LinkedIn esetében a LinkedIn-csomópont dokumentációja lefedi a személyek és szervezetek nevében történő posztolást, és az n8n LinkedIn-hitelesítési útmutatója kimondja, hogy szervezet nevében posztolni annyit tesz, hogy az alkalmazást át kell vinni a LinkedIn Community Management App Review folyamatán. Ez fedezte, amire szükségem volt. Az X hitelesítési dokumentációja azt mondja, hogy az X végpontonként időalapú kéréskorlátokat alkalmaz, a fejlesztői hozzáférési csomag szintjétől függően. Az én posztolási mennyiségemnél nem ütköztem a plafonba, de továbbra is olyan korlátnak tekintem, amelyet az X bármikor módosíthat, nem pedig az n8n ígéretének.
A Meta tartalomközzétételi útmutatója a JPEG-et jelöli meg egyetlen támogatott képformátumként, és a dokumentált útvonalra 100, API-n át közzétett bejegyzés korlátját adja meg egy csúszó 24 órás ablakban. A JPEG-szabály egy estémbe került, mert az exportjaim alapértelmezés szerint PNG-k voltak, és a hiba n8n-en belülről nem látszott. Ezt a közzétételi korlátot az aktuális API-útvonalhoz és -verzióhoz kötöm, nem tekintem véglegesnek.
Négy hónap alatt kétszer tört el. Mindkétszer az Instagram. A hosszú élettartamú hozzáférési tokenek nem örökké élnek, és a Meta tokenfrissítési referenciája azt mondja, hogy egy token csak addig frissíthető, amíg nem járt le, és legalább 24 órás. Ha ez az ablak becsukódik, a frissítés többé nem visszaút. Az én hibám az volt, hogy a hitelesítést telepítési munkának tekintettem, nem folyamatos karbantartásnak. Egy közzétételi munkafolyamathoz lejáratfigyelés, korai frissítés és riasztás kell, ha a megújítás elbukik.
A TikTok egyszerűen nem volt része a cserének. A beépített alkalmazáscsomópont-katalógus nem tartalmazza. Használhattam volna a HTTP Request csomópontot, egy egyedit vagy egy közösségit, csakhogy akkor több hitelesítőadat-kezelés és több meghibásodás lett volna a nyakamon. Egy ütemezőt váltottam ki, nem arra jelentkeztem, hogy még egy platformintegrációt karbantartsak.
A költségszámítás, a saját időmmel együtt
Kiindulásnak a négycsatornás Buffer Essentialst vettem. Az alábbi közzétett árak éves számlázásra vonatkoznak, és 2026 augusztusában ellenőriztem őket; a dolláros és eurós összegeket a saját, közzétett pénznemükben hagytam, ahelyett hogy közvetlenül azonosnak tüntetném fel őket.
| Lehetőség | Közzétett havi ár | Mit tartalmaz | Mit üzemeltet Ön |
|---|---|---|---|
| Buffer Essentials, 4 csatorna | $20, billed yearly | Ütemező felület és korlátlan ütemezett bejegyzés | Semmilyen infrastruktúra |
| n8n Cloud Starter | 20 €, éves számlázással | 2500 munkafolyamat-futtatás | A munkafolyamat és a hitelesítő adatok |
| n8n Cloud Pro | 50 €, éves számlázással | 10 000 munkafolyamat-futtatás | A munkafolyamat és a hitelesítő adatok |
| n8n Community Edition | Nincs szoftverdíj | Saját üzemeltetésű munkafolyamat-motor | Kiszolgáló, frissítések, adatok, mentések, felügyelet |
Az n8n felhőárazása nagyjából ugyanabba a belépő árkategóriába teszi a Startert, mint a négy Buffer Essentials-csatornámat. Ezzel a menedzselt változat az én esetemben megbukott: hasonló havi összeget fizettem volna egy munkafolyamat-motorért, és elvesztettem volna a kellemesebb közzétételi felületet. A Community Edition összehasonlítása megerősítette, hogy megtarthatom az alap, saját üzemeltetésű kiadást szoftverdíj nélkül, csakhogy ettől sem a kiszolgáló, sem az időm nem lett ingyenes.
A saját gépem méretét sem tenném meg általános, 4 GB RAM-os és 2 vCPU-s éles üzemi alsó határnak. Az n8n telepítési előfeltételei tág erőforrás-tartományt adnak meg. Az én terhelésem kicsi, de egy másik felállás gyorsan változhat párhuzamos futásokkal, médiatartalmakkal, kódlépésekkel, adatbázis-terheléssel és hosszabb futási előzményekkel. Az őszinte válasz az, hogy a terhelésből induljunk ki, és figyeljük a memóriát és a CPU-t.
Az n8n alapértelmezett adatbázisa az SQLite és kis forgalmú, egypéldányos telepítéshez teljesen megfelelhet. Ettől még a PostgreSQL-t választom, amint a futási előzmények számítanak, vagy a telepítés növekedni fog. A PostgreSQL az, amit egy elosztott sormódú felállás felállás igényel, mert az n8n ezt az architektúrát SQLite fölött nem támogatja. Ezt a döntést inkább a telepítéskor hozom meg, mint hogy adatbázist migráljak, amikor a munkafolyamat már fontossá vált.
A drága rész sosem a VPS volt. A hétvégém volt az. Aztán jött a JPEG miatt elvesztett este, a tokenhibák, és az ismétlődő ellenőrzés, hogy a posztok tényleg kimentek-e. Ha egyáltalán beárazom a saját óráimat, a megtakarítás gyorsan összemegy, és mínuszba fordulhat. Ez az a pont, ahol a saját üzemeltetés megszűnik olcsó lenni. Máig úgy gondolom, hogy megérte a váltás, de az első héten ezt nem mondtam volna.
Mi romlott el, és min változtattam
A két látható hiba Instagram-tokenhiba volt, de a mélyebb gond a csend volt. Egy előfizetéses ütemező olyan termékfelületet ad, amelyet a fiókproblémák megmutatására terveztek. Az első munkafolyamatom el tudott hasalni az n8n-en belül, miközben kívülről csak annyi látszott, hogy aznap nem ment ki poszt. Ebből tanultam meg, hogy egy saját üzemeltetésű közzétevőnek hangosan kell hibáznia, és duplikátumok nélkül kell talpra állnia.
- A hibariasztásokat egy n8n-en kívüli csatornára küldöm, a platform válaszával és a munkafolyamat futásazonosítójával együtt, hogy ne ugyanattól a rendszertől kelljen megtudnom, hogy elromlott.
- Nyomon követem a tokenek lejárati dátumát és az alkalmazásfelülvizsgálat állását, a megújítást pedig elég korán tesztelem ahhoz, hogy újra engedélyezhessek, mielőtt egy ütemezett poszt lenne az első figyelmeztetés.
- Közzététel előtt egyedi tartalomazonosítót rögzítek, így egy elbukott platformág újrapróbálkozhat anélkül, hogy a már sikeres ágakra újra kiposztolna.
- Mentem az n8n adatkötetét és adatbázisát, a visszaállítási tesztet pedig a mentés részének tekintem, ahelyett hogy abban bíznék, majd megmentenek a lemásolt fájlok.
- Ahol a szolgáltató engedi, rögzítem az API-verziókat, elolvasom a változásnaplókat, és minden n8n- vagy szolgáltatóoldali változás után letesztelem az összes platformágat.
- A futási előzményeket és a médiafájlokat a ténylegesen szükséges megőrzési idő szerint metszem vissza, mert a közösségi anyagoktól egy pöttöm automatizálásból fölöslegesen nagy mentés lesz.
Ezt nem futtatnám otthoni gépről. A reggel 9-re időzített poszthoz 9-kor élő munkafolyamat kell, a lakossági áramellátás, a kapcsolat, a NAT és a bejövő visszahívások pedig olyan változókat hoznak, amiket egy tartalomnaptárban nem akarok. Egy VPS leveszi ezeket az otthoni hálózati változókat. A TLS, a mentések, a felügyelet, a frissítések és a helyreállítás felelősségét nem veszi le rólam.
Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.
Linux csomagok megtekintéseKinek nem érdemes belevágnia
Maradjon a fizetős ütemezőnél, ha ütemezőt akar. Ez nem vigaszdíj. Ha a naptár, az előnézetek, az egyszerű jóváhagyások, a széles csatornalefedettség és a minimális karbantartás megéri Önnek az előfizetést, akkor megvenni a helyes döntés. Egyedi automatizálás igénye nélkül ezt a felületet munkafolyamat-vászonra cserélni visszalépés, ráadásul plusz lépésekkel.
Ha Buffer formájú, de a sajátjának mondható terméket szeretne, én az n8n előtt a Postiz Postizt néznék meg. A nyílt forráskódú változata futhat a saját szerverén, a platformlistája pedig több mint 30 támogatott csatorna között a TikTokot is tartalmazza. Közzétételi naptár, nem munkafolyamat-vászon, és épp ezért természetesebb kikötő sokaknak, akik otthagynak egy fizetős ütemezőt.
Csak azért csinálnám meg újra, mert egyetlen csővezetékben akartam a kutatást, a fogalmazást, a jóváhagyást, a közzétételt és a naplózást. Ezt az alkut fogadtam el: nem ingyenes ütemezést, hanem figyelemmel megfizetett kontrollt. Ha csak ütemezésre lenne szükségem, visszatérnék az előfizetéshez.
Ha ugyanezt a saját üzemeltetésű utat szeretné járni, az egykattintásos n8n-telepítésünk leveszi a kezdeti kiszolgálótelepítés lépését. Nem veszi le viszont azt a munkát, amit fontosabbnak találtam: a munkafolyamat hitelesítő adatait, a platformjóváhagyásokat, a frissítéseket, a mentéseket, a felügyeletet és a sikertelen posztok helyreállítását.
Gyakran ismételt kérdések
Átvihetők a Buffer engedélyei az n8n-be?
Nem. A platformkapcsolatok, amelyeket a Buffernek adtam, a Buffer alkalmazásához és engedélyezési folyamatához tartoztak. Az n8n-munkafolyamatomnak saját hitelesítő adatokra, tokenekre, hatókörökre és minden olyan platformfelülvizsgálatra szüksége volt, amit a fiók vagy a közzétételi útvonal megkövetel.
Minden közösségi platform kapjon saját ágat?
Általában igen. Külön ágakat használtam, hogy platformonként igazíthassam a szöveget, a médiát, a hitelesítő adatokat és a hibakezelést. Ettől egy elbukott Instagram-kérés újrapróbálkozhatott anélkül, hogy újra kiment volna egy poszt, ami az X-en vagy a LinkedInen már sikeres volt.
Publikálhat egyetlen n8n-munkafolyamat több ügyfélnek is?
Igen, de ügyfelenként elkülöníteném a hitelesítő adatokat, a tartalomforrásokat, a jóváhagyási állapotokat és a naplókat. A platformengedélyek és kvóták továbbra is az adott alkalmazásra és fiókra vonatkoznak, ezért egyetlen sikeres kapcsolatot sem szabad univerzális hozzáférésnek tekinteni.
Hogyan pótolja egy munkafolyamat a kimaradt posztokat?
Lekérdezem azokat a jóváhagyott posztokat, amelyeknek az ütemezett ideje már elmúlt, majd csak azokat a rekordokat teszem közzé, amelyeknek nincs sikeres eredménye. Az egyedi tartalomazonosító és az eltárolt platformválasz megakadályozza, hogy egy újraindítás vagy újrapróbálkozás megkettőzze a már kiment posztokat.
