Jeg udskiftede min planlægger til sociale medier med et selvhostet n8n-workflow

Fem dollar pr. kanal om måneden. Det var tallet, jeg blev ved med at stirre på i fornyelsesvinduet, for det afgjorde stille og roligt, hvor mange steder jeg måtte poste. Fire kanaler betød fire gange fem. Kom der senere et brand nummer to til, ville regningen stige igen, for de samme planlagte opslag, jeg alligevel selv skrev.

Jeg havde i forvejen n8n kørende på en VPS til to urelaterede automatiseringer, så jeg gav mig selv en weekend til at se, om jeg kunne lave den om til en n8n-planlægger til sociale medier for X, LinkedIn, Instagram og Facebook. Den har nu kørt i fire måneder. Her er, hvad skiftet reelt kostede mig, hvad der gik i stykker, og hvor jeg stadig ikke ville anbefale det.

Den korte version

• Jeg fik X, LinkedIn, Facebook og Instagram til at publicere fra det samme workflow, men de fire grene krævede ikke lige meget arbejde.
• Instagram var problemet: kravet om en professionel konto, mediereglerne, publiceringsgrænserne og tokens livscyklus skabte alt sammen vedligeholdelse, som jeg ikke havde med Buffer.
• Jeg holdt TikTok udenfor, fordi n8n's katalog over indbyggede app-noder ikke har den med, og jeg var ikke villig til at gøre en egen eller community-integration til en del af min opslagsplan.
• Community Edition fjernede softwaregebyret, ikke omkostningen. Jeg betalte stadig for hosting og stod selv for opdateringer, credentials, backups, overvågning og genopretning af mislykkede opslag.
• Min dom: skiftet var det værd, fordi jeg ville have skrivning og publicering i én pipeline. Hvis jeg kun havde villet have en visuel kalender og pålidelige køer, var jeg blevet.

Hvad jeg betalte for, og hvad der til sidst gav udslaget

Buffers aktuelle priser angiver Essentials til 5 $ pr. kanal om måneden ved årlig betaling, mens gratisplanen understøtter op til tre kanaler og ti planlagte opslag pr. kanal. Mine fire betalte kanaler landede derfor på 20 $ om måneden ved årlig betaling. Det er en fornuftig måde at sælge en gennemarbejdet planlægger på, men den opkrævede mig præcis for det, jeg ville udvide: at forme én idé om til flere steder på én gang.

Det var i sidste ende ikke prisen, der afgjorde det. Jeg skrev alligevel opslagene med en model i et separat vindue og indsatte dem så manuelt i planlæggeren. To værktøjer udførte én indlysende pipeline. Da jeg først kunne se det workflow, jeg ville have, gav det ikke længere mening for mig at betale et abonnement for at holde skrivning og publicering i to adskilte halvdele.

Hvad mit workflow gør

Mit workflow er bevidst kedeligt. En Schedule Trigger udløses et par gange om dagen, læser den næste godkendte række fra mit Google Sheet, tilpasser teksten til hver platform, sender hver version ned ad sin egen publiceringsgren og registrerer resultatet. Godkendelsesstatus fører jeg selv i arket, og jeg publicerer kun rækker, jeg har godkendt. Mislykkede grene udløser en advarsel uden for n8n, så en ødelagt credential ikke kan forsvinde inde i en eksekveringslog.

Skrivetrinnet kalder API'et på en hostet model. Jeg overvejede kort at køre en model på den samme maskine, men ved et par dusin opslag om måneden var omkostningsfaktorerne ved selv at hoste en model omkostningsfaktorerne større end min API-regning. Forbrug, privatliv eller latency kunne ændre den beslutning, men jeg havde ingen grund til at drive ekstra infrastruktur bare for at omskrive opslag. Workflowet er ikke smart, og det er en del af grunden til, at jeg stolede på det.

Virkeligheden platform for platform (Instagram er problemet)

Tre af mine fire grene forløb stort set udramatisk. Instagram slugte mere tid end resten af projektet tilsammen, og det var den platform, hvor manglende opslag var sværest for mig at ignorere. Tabellen viser de veje, jeg brugte eller vurderede; detaljerne nedenunder er de dele, der reelt påvirkede min opsætning.

For LinkedIn beskriver dokumentationen for LinkedIn-noden oprettelse af opslag for personer og organisationer, og n8n's vejledning til LinkedIn-credentials nævner , at opslag som organisation betyder, at din app skal gennem LinkedIns Community Management App Review. Det dækkede det, jeg havde brug for. Dokumentationen for X-credentials siger, at X anvender tidsbaserede rate limits pr. endpoint afhængigt af niveauet på din udviklerplan. Ved mit opslagsvolumen ramte jeg aldrig loftet, men jeg betragter det stadig som en grænse, X kan ændre, ikke som et løfte fra n8n.

Metas vejledning til udgivelse af indhold dokumenterer JPEG som det eneste understøttede billedformat og en grænse på 100 opslag udgivet via API'et inden for et glidende 24-timers vindue for den dokumenterede rute. JPEG-reglen kostede mig en aften, fordi mine eksporter som standard var PNG, og fejlen ikke var tydelig indefra n8n. Jeg betragter den publiceringsgrænse som knyttet til den aktuelle API-rute og -version frem for som permanent.

På fire måneder gik det i stykker to gange. Begge gange Instagram. Langlivede adgangstokens holder ikke evigt, og Metas reference om fornyelse af tokens siger, at et token kun kan fornys, så længe det ikke er udløbet og er mindst 24 timer gammelt. Misser man det vindue, er fornyelse ikke længere vejen tilbage. Min fejl var at behandle autentificering som opsætningsarbejde i stedet for løbende vedligeholdelse. Et publiceringsworkflow har brug for overvågning af udløbsdatoer, en tidlig fornyelse og en advarsel, når fornyelsen fejler.

TikTok var ganske enkelt ikke en del af min udskiftning. Kataloget over indbyggede app-noder har den ikke med. Jeg kunne have brugt HTTP Request-noden, en egen node eller en community-node, men så ville jeg have stået med mere håndtering af credentials og flere nedbrud. Jeg var ved at udskifte en planlægger, ikke at melde mig til at vedligeholde endnu en platformsintegration.

Regnestykket, inklusive min egen tid

Som udgangspunkt brugte jeg Buffer Essentials med fire kanaler. De offentliggjorte priser nedenfor gælder ved årlig betaling og blev bekræftet i august 2026; jeg har ladet dollar- og eurobeløbene stå i deres egne valutaer i stedet for at lade som om, de er direkte ens.

n8n's cloudpriser placerer Starter i nogenlunde samme startprisleje som mine fire Buffer Essentials-kanaler. Det dræbte den hostede løsning i mit tilfælde: jeg ville betale et lignende månedligt beløb for en workflow-motor og miste den pænere publiceringsgrænseflade. Sammenligningen af Community Edition bekræftede, at jeg kunne beholde den basale selvhostede udgave uden softwaregebyr, men det gjorde hverken serveren eller min tid gratis.

Jeg ville heller ikke gøre størrelsen på min maskine til en universel produktionsminimumsgrænse på 4 GB RAM og 2 vCPU. n8n's forudsætninger for udrulning angiver et bredt ressourceinterval. Min belastning er lille, men en anden opsætning kan hurtigt ændre sig med samtidige kørsler, mediepayloads, kodetrin, databasebelastning og længere kørselshistorik. Det ærlige svar er at tage udgangspunkt i belastningen og holde øje med hukommelse og CPU.

SQLite er n8n's standarddatabase og kan sagtens være fint til en opsætning med én instans og lavt volumen. Jeg foretrækker stadig PostgreSQL, så snart kørselshistorikken betyder noget, eller udrulningen forventes at vokse. PostgreSQL er også det, en distribueret opsætning i queue-tilstand har brug for, for n8n understøtter ikke den arkitektur oven på SQLite. Den beslutning tager jeg hellere ved opsætningen end at migrere en database, når workflowet først er blevet vigtigt.

VPS'en var aldrig den dyre del. Det var min weekend. Så kom aftenen, jeg mistede på JPEG, tokenfejlene og den tilbagevendende kontrol af, om opslagene rent faktisk var gået ud. Sætter jeg overhovedet pris på mine egne timer, skrumper besparelsen hurtigt og kan blive negativ. Det er dér, selvhosting holder op med at være billigt. Jeg synes stadig, skiftet var det værd, men i uge ét ville jeg ikke have sagt det.

LÆS

Den self-hostede stak til indie hackers: Den bedste måde at erstatte din enorme SaaS-regning på

Hvad der gik i stykker, og hvad jeg ændrede

De to synlige fejl var Instagram-tokenfejl, men det dybere problem var stilheden. En abonnementsplanlægger giver mig en produktflade, der er designet til at vise kontoproblemer. Mit første workflow kunne fejle inde i n8n, mens det eneste synlige symptom var en dag uden opslag. Det lærte mig, at en selvhostet publisher skal fejle højlydt og komme sig uden dubletter.

• Jeg sender fejladvarsler til en kanal uden for n8n og medsender platformens svar samt workflowets eksekverings-id, så jeg ikke er afhængig af det samme system til at fortælle mig, at det er gået ned.
• Jeg holder styr på tokens udløbsdatoer og status på appgennemgange, og jeg tester fornyelsen tidligt nok til at kunne genautorisere, før et planlagt opslag bliver den første advarsel.
• Jeg registrerer et unikt indholds-id før publicering, så en mislykket platformsgren kan prøve igen uden at genudgive til de grene, der allerede lykkedes.
• Jeg tager backup af n8n's datavolumen og database, og jeg betragter en gendannelsestest som en del af backuppen frem for at gå ud fra, at kopierede filer nok skal redde mig.
• Hvor udbyderen tillader det, låser jeg API-versioner, læser changelogs og tester hver platformsgren efter en ændring hos n8n eller udbyderen.
• Jeg beskærer kørselshistorik og mediefiler efter den opbevaring, jeg reelt har brug for, for socialt materiale kan gøre en lillebitte automatisering til en unødvendigt stor backup.

Jeg ville ikke køre det her fra en maskine hjemme hos mig. Et opslag planlagt til klokken 9 kræver, at workflowet kører klokken 9, og husholdningsstrøm, forbindelse, NAT og indgående callbacks tilføjer variabler, jeg ikke vil have i en indholdskalender. En VPS fjerner de hjemmenetværksvariabler; den fjerner ikke mit ansvar for TLS, backups, overvågning, opdateringer eller genopretning.

Hvem der ikke bør gøre det her

Bliv ved den betalte planlægger, hvis det, du vil have, er en planlægger. Det er ikke en trøstepræmie. Hvis en kalender, forhåndsvisninger, enkle godkendelser, bred kanaldækning og minimal vedligeholdelse er abonnementet værd for dig, er det den rigtige beslutning at købe dem. Uden behov for skræddersyet automatisering er det et skridt tilbage med ekstra trin at bytte den brugerflade ud med et workflow-lærred.

Vil du have et produkt i Buffers form, som du selv ejer, ville jeg kigge på Postiz før n8n. Open source-udgaven kan køre på din egen server, og platformslisten omfatter TikTok blandt mere end 30 understøttede kanaler. Det er en publiceringskalender frem for et workflow-lærred, hvilket gør det til et mere naturligt sted at lande for mange, der forlader en betalt planlægger.

Jeg ville kun gøre det igen, fordi jeg ville have research, skrivning, godkendelse, publicering og logning i én pipeline. Det var den handel, jeg indgik: ikke gratis planlægning, men kontrol betalt med opmærksomhed. Hvis alt, jeg havde brug for, var planlægning, ville jeg gå tilbage til abonnementet.

Vil du følge den samme selvhostede rute, fjerner vores n8n-udrulning med ét klik det første trin med serverinstallation. Den fjerner ikke det arbejde, jeg fandt vigtigere: workflow-credentials, platformsgodkendelser, opdateringer, backups, overvågning og genopretning af mislykkede opslag.

Ofte stillede spørgsmål

Overføres Buffer-autorisationer til n8n?

Nej. De platformsforbindelser, jeg havde givet Buffer, hørte til Buffers app og autorisationsflow. Mit n8n-workflow havde brug for sine egne credentials, tokens, scopes og enhver platformsgodkendelse, der kræves for kontoen eller publiceringsruten.

Bør hver social platform have sin egen gren?

Som regel ja. Jeg brugte separate grene, så jeg kunne tilpasse tekst, medier, credentials og fejlhåndtering til hver platform. Det gjorde også, at en mislykket Instagram-forespørgsel kunne prøve igen uden at genudgive et opslag, der allerede var lykkedes på X eller LinkedIn.

Kan ét n8n-workflow publicere for flere kunder?

Ja, men jeg ville isolere credentials, indholdskilder, godkendelsesstatus og logs pr. kunde. Platformstilladelser og kvoter gælder stadig for den pågældende app og konto, så én vellykket forbindelse bør aldrig opfattes som universel adgang.

Hvordan bør et workflow indhente missede opslag?

Jeg forespørger på godkendte opslag, hvis planlagte tidspunkt er passeret, og publicerer derefter kun poster uden et vellykket resultat. Et unikt indholds-id og det gemte platformssvar forhindrer, at en genstart eller et nyt forsøg duplikerer opslag, der allerede er gået ud.