Ik verving mijn socialmediaplanner door een zelfgehoste n8n-workflow

Vijf dollar per kanaal, per maand. Naar dat getal bleef ik staren op het verlengscherm, want het bepaalde stilletjes op hoeveel plekken ik mocht posten. Vier kanalen betekende vier keer vijf. Kwam er later een tweede merk bij, dan liep de rekening opnieuw op voor dezelfde ingeplande berichten die ik toch al zelf schreef.

Ik had n8n al draaien op een VPS voor twee losstaande automatiseringen, dus gaf ik mezelf een weekend om te zien of ik er een n8n-socialmediaplanner van kon maken voor X, LinkedIn, Instagram en Facebook. Inmiddels draait hij vier maanden. Dit is wat de overstap me echt kostte, wat er stukging en waar ik hem nog steeds niet zou aanraden.

De korte versie

• Het lukte me om vanuit dezelfde workflow te publiceren op X, LinkedIn, Facebook en Instagram, maar de vier takken kostten niet evenveel werk.
• Instagram was het probleem: de eis van een professioneel account, de mediaregels, de publicatielimieten en de levenscyclus van tokens leverden allemaal onderhoud op dat ik met Buffer niet had.
• TikTok heb ik weggelaten omdat de catalogus met ingebouwde app-nodes van n8n het niet vermeldt, en ik was niet bereid een eigen of community-integratie onderdeel te maken van mijn postschema.
• Community Edition haalde de softwarekosten weg, niet de kosten als geheel. Ik betaalde nog steeds voor hosting en was zelf verantwoordelijk voor updates, credentials, back-ups, monitoring en het herstellen van mislukte posts.
• Mijn oordeel: de overstap was het waard omdat ik schrijven en publiceren in één pipeline wilde. Had ik alleen een visuele kalender en betrouwbare wachtrijen gewild, dan was ik gebleven.

Waarvoor ik betaalde, en wat uiteindelijk de doorslag gaf

De actuele prijzen van Buffer zet Essentials op 5 $ per kanaal per maand bij jaarlijkse facturering, terwijl het gratis plan tot drie kanalen en tien ingeplande berichten per kanaal ondersteunt. Mijn vier betaalde kanalen kwamen daarmee op 20 $ per maand bij jaarlijkse facturering. Dat is een redelijke manier om een verzorgde planner te verkopen, maar het rekende me precies aan wat ik wilde uitbreiden: één idee omvormen voor meerdere plekken tegelijk.

Uiteindelijk gaf niet de prijs de doorslag. Ik schreef mijn berichten al met een model in een apart venster en plakte ze daarna met de hand in de planner. Twee tools vormden één voor de hand liggende pipeline. Zodra ik de workflow voor me zag die ik wilde, sloeg een abonnement betalen om schrijven en publiceren in twee losse helften te houden voor mij nergens meer op.

Wat mijn workflow doet

Mijn workflow is bewust saai. Een Schedule Trigger gaat een paar keer per dag af, leest de volgende goedgekeurde rij uit mijn Google Sheet, past de tekst aan per platform, stuurt elke versie door zijn eigen publicatietak en legt het resultaat vast. De goedkeuring houd ik zelf bij in het sheet en ik publiceer alleen rijen die ik heb goedgekeurd. Mislukte takken sturen een melding buiten n8n om, zodat een kapotte credential niet in een uitvoeringslog kan verdwijnen.

De schrijfstap roept de API van een gehost model aan. Ik heb kort overwogen een model op dezelfde machine te draaien, maar bij een paar dozijn berichten per maand waren de kostenfactoren van een model zelf hosten groter dan mijn API-rekening. Gebruik, privacy of latency kunnen die afweging kantelen, maar ik had geen reden om extra infrastructuur te draaien alleen om social posts te herschrijven. De workflow is niet slim, en dat is deels waarom ik hem vertrouwde.

De realiteit per platform (Instagram is het probleem)

Drie van mijn vier takken verliepen grotendeels zonder gedoe. Instagram slokte meer tijd op dan de rest van het project bij elkaar, en het was het platform waar gemiste posts het lastigst te negeren waren. De tabel toont de routes die ik gebruikte of onderzocht; de details eronder zijn de punten die mijn opzet echt raakten.

Voor LinkedIn beschrijft de documentatie van de LinkedIn-node het aanmaken van berichten voor personen en organisaties, en n8n's handleiding voor LinkedIn-credentials vermeldt dat posten als organisatie betekent dat je app door LinkedIns Community Management App Review moet. Dat dekte wat ik nodig had. De documentatie over X-credentials zegt dat X per endpoint tijdgebonden ratelimieten hanteert, afhankelijk van het niveau van je ontwikkelaarsplan. Bij mijn postvolume liep ik nooit tegen het plafond aan, maar ik blijf het zien als een limiet die X kan wijzigen, niet als een belofte van n8n.

Meta's handleiding voor het publiceren van content documenteert JPEG als enige ondersteunde afbeeldingsindeling en een limiet van 100 via de API gepubliceerde berichten binnen een voortschrijdend venster van 24 uur voor de gedocumenteerde route. De JPEG-regel kostte me een avond, omdat mijn exports standaard PNG waren en de fout vanuit n8n niet zichtbaar was. Ik houd dat publicatielimiet gekoppeld aan de huidige API-route en -versie in plaats van het als permanent te beschouwen.

In vier maanden ging het twee keer stuk. Beide keren Instagram. Langlevende accesstokens zijn niet eeuwig, en Meta's referentie over het vernieuwen van tokens zegt dat een token alleen vernieuwd kan worden zolang het niet is verlopen en minstens 24 uur oud is. Mis dat venster en vernieuwen is niet langer de weg terug. Mijn fout was authenticatie behandelen als installatiewerk in plaats van doorlopend onderhoud. Een publicatieworkflow heeft bewaking van vervaldata nodig, een tijdige vernieuwing en een melding wanneer verlengen mislukt.

TikTok maakte simpelweg geen deel uit van mijn vervanging. De catalogus met ingebouwde app-nodes vermeldt het niet. Ik had de HTTP Request-node, een eigen node of een community-node kunnen gebruiken, maar dan was ik verantwoordelijk geweest voor meer credentialbeheer en meer storingen. Ik verving een planner, ik meldde me niet aan om nog een platformintegratie te onderhouden.

De kostenberekening, inclusief mijn tijd

Als referentie nam ik Buffer Essentials met vier kanalen. De gepubliceerde prijzen hieronder gelden bij jaarlijkse facturering en zijn in augustus 2026 gecontroleerd; ik heb de bedragen in dollars en euro's in hun eigen valuta gelaten in plaats van te doen alsof ze direct gelijk zijn.

De cloudprijzen van n8n zetten Starter ongeveer in dezelfde instapprijsklasse als mijn vier Buffer Essentials-kanalen. Daarmee viel de managed variant voor mijn situatie af: ik zou een vergelijkbaar maandbedrag betalen voor een workflow-engine en de fijnere publicatie-interface kwijtraken. De vergelijking van de Community Edition bevestigde dat ik de basale zelfgehoste editie zonder softwarekosten kon houden, maar daarmee werden de server en mijn tijd niet gratis.

Ik zou de omvang van mijn machine ook niet tot een universele productie-ondergrens van 4 GB RAM en 2 vCPU verheffen. De deployment-vereisten van n8n geven een brede resourcerange. Mijn belasting is klein, maar een andere opzet kan snel veranderen door gelijktijdige uitvoeringen, media-payloads, codestappen, databasebelasting en een langere uitvoeringsgeschiedenis. Het eerlijke antwoord is: begin bij de werklast en houd geheugen en CPU in de gaten.

SQLite is de standaarddatabase van n8n en kan prima volstaan voor een opzet met één instantie en weinig volume. Toch verkies ik PostgreSQL zodra de uitvoeringsgeschiedenis ertoe doet of de deployment moet groeien. PostgreSQL is ook wat een gedistribueerde opzet in queue-modus nodig heeft, want n8n ondersteunt die architectuur niet bovenop SQLite. Ik neem die beslissing liever bij het opzetten dan dat ik later een database migreer als de workflow eenmaal belangrijk is.

De VPS was nooit het dure deel. Mijn weekend wel. Daarna kwam de avond die JPEG me kostte, de tokenstoringen en het steeds terugkerende controleren of de berichten echt de deur uit waren. Zodra ik mijn eigen uren ook maar enigszins beprijs, slinkt de besparing snel en kan ze negatief worden. Dat is het punt waarop zelf hosten ophoudt goedkoop te zijn. Ik vind de overstap nog steeds de moeite waard, maar in week één had ik dat niet gezegd.

LEES

De Zelf-Gehoste Stack voor Indie Hackers: De beste manier om je enorme SaaS-rekening te vervangen

Wat er stukging en wat ik heb veranderd

De twee zichtbare storingen waren Instagram-tokenfouten, maar het diepere probleem was stilte. Een abonnementsplanner geeft me een productinterface die is gemaakt om accountproblemen te tonen. Mijn eerste workflow kon binnen n8n falen terwijl het zichtbare symptoom simpelweg een dag zonder posts was. Dat leerde me dat een zelfgehoste publisher luid moet falen en zonder duplicaten moet herstellen.

• Ik stuur foutmeldingen naar een kanaal buiten n8n, met de reactie van het platform en het uitvoerings-ID van de workflow, zodat ik niet afhankelijk ben van hetzelfde systeem om te horen dat het stuk is.
• Ik houd vervaldata van tokens en de status van appbeoordelingen bij, en test de verlenging vroeg genoeg om opnieuw te autoriseren voordat een ingepland bericht de eerste waarschuwing wordt.
• Ik leg vóór het publiceren een unieke content-ID vast, zodat een mislukte platformtak opnieuw kan proberen zonder te herposten op takken die al gelukt waren.
• Ik maak een back-up van het n8n-datavolume en de database, en beschouw een hersteltest als onderdeel van die back-up in plaats van erop te vertrouwen dat gekopieerde bestanden me wel redden.
• Waar de aanbieder het toelaat pin ik API-versies vast, ik lees de changelogs en test elke platformtak na een wijziging aan de kant van n8n of de aanbieder.
• Ik snoei de uitvoeringsgeschiedenis en mediabestanden op basis van de bewaartermijn die ik echt nodig heb, want socialassets kunnen van een piepkleine automatisering een onnodig grote back-up maken.

Ik zou dit niet vanaf een bak bij mij thuis draaien. Een bericht dat om 9 uur staat ingepland vereist dat de workflow om 9 uur draait, en huisstroom, connectiviteit, NAT en inkomende callbacks voegen variabelen toe die ik niet in een contentkalender wil. Een VPS haalt die thuisnetwerkvariabelen weg; het haalt niet mijn verantwoordelijkheid weg voor TLS, back-ups, monitoring, updates of herstel.

Wie dit beter niet moet doen

Blijf bij de betaalde planner als je een planner wilt. Dat is geen troostprijs. Als een kalender, previews, eenvoudige goedkeuringen, brede kanaaldekking en minimaal onderhoud het abonnement voor jou waard zijn, is ze kopen de juiste beslissing. Zonder behoefte aan maatwerkautomatisering is die interface inruilen voor een workflowcanvas een stap terug met extra handelingen.

Wil je een product in de vorm van Buffer dat je zelf bezit, dan zou ik naar Postiz kijken, vóór n8n. De opensourceversie draait op je eigen server, en de platformlijst bevat TikTok tussen meer dan 30 ondersteunde kanalen. Het is een publicatiekalender in plaats van een workflowcanvas, en daarmee een natuurlijker landingsplek voor veel mensen die een betaalde planner verlaten.

Ik zou dit alleen opnieuw doen omdat ik onderzoek, schrijven, goedkeuren, publiceren en loggen in één pipeline wilde. Dat is de ruil die ik accepteerde: geen gratis plannen, maar controle betaald met aandacht. Had ik alleen planning nodig, dan ging ik terug naar het abonnement.

Wil je dezelfde zelfgehoste route volgen, dan haalt onze n8n-installatie met één klik de eerste stap van het installeren van de server weg. Het haalt niet het werk weg dat ik belangrijker vond: workflow-credentials, platformgoedkeuringen, updates, back-ups, monitoring en het herstellen van mislukte posts.

Veelgestelde vragen

Gaan Buffer-autorisaties mee naar n8n?

Nee. De platformkoppelingen die ik aan Buffer had gegeven, hoorden bij Buffers app en autorisatieflow. Mijn n8n-workflow had eigen credentials, tokens en scopes nodig, plus elke platformbeoordeling die voor het account of de publicatieroute vereist is.

Moet elk socialmediaplatform een eigen tak krijgen?

Meestal wel. Ik gebruikte aparte takken om tekst, media, credentials en foutafhandeling per platform aan te passen. Zo kon een mislukte Instagram-aanvraag het opnieuw proberen zonder een bericht te herposten dat op X of LinkedIn al gelukt was.

Kan één n8n-workflow voor meerdere klanten publiceren?

Ja, maar ik zou credentials, contentbronnen, goedkeuringsstatussen en logs per klant scheiden. Platformrechten en quota gelden nog steeds voor de betreffende app en het betreffende account, dus één geslaagde koppeling is nooit universele toegang.

Hoe moet een workflow gemiste posts inhalen?

Ik vraag goedgekeurde posts op waarvan de geplande tijd voorbij is en publiceer daarna alleen records zonder geslaagd resultaat. Een unieke content-ID en de opgeslagen platformreactie voorkomen dat een herstart of hernieuwde poging berichten dupliceert die al de deur uit waren.