Ich habe meinen Social-Media-Planer durch einen selbst gehosteten n8n-Workflow ersetzt

Fünf Dollar pro Kanal und Monat. Auf diese Zahl starrte ich immer wieder im Verlängerungsdialog, weil sie stillschweigend festlegte, an wie vielen Stellen ich posten durfte. Vier Kanäle bedeuteten viermal fünf. Käme später eine zweite Marke dazu, stiege die Rechnung erneut, für dieselben geplanten Beiträge, die ich ohnehin selbst schrieb.

n8n lief bei mir ohnehin schon auf einem VPS für zwei unabhängige Automatisierungen, also gab ich mir ein Wochenende, um zu sehen, ob ich daraus einen n8n-Social-Media-Planer für X, LinkedIn, Instagram und Facebook machen kann. Inzwischen läuft er seit vier Monaten. Hier steht, was mich der Wechsel wirklich gekostet hat, was kaputtging und wo ich ihn nach wie vor nicht empfehlen würde.

Die Kurzfassung

• Ich habe X, LinkedIn, Facebook und Instagram dazu gebracht, aus demselben Workflow zu veröffentlichen, aber die vier Zweige erforderten nicht gleich viel Arbeit.
• Instagram war das Problem: die Pflicht zum professionellen Konto, die Medienregeln, die Veröffentlichungslimits und der Token-Lebenszyklus erzeugten allesamt Wartungsaufwand, den ich mit Buffer nicht hatte.
• TikTok habe ich weggelassen, weil der Katalog der eingebauten App-Nodes von n8n es nicht führt, und ich war nicht bereit, eine eigene oder Community-Integration zum Bestandteil meines Posting-Plans zu machen.
• Die Community Edition beseitigt die Softwaregebühr, nicht die Kosten. Ich zahlte weiterhin fürs Hosting und war für Updates, Zugangsdaten, Backups, Monitoring und die Wiederherstellung fehlgeschlagener Posts zuständig.
• Mein Fazit: Der Wechsel hat sich gelohnt, weil ich Entwurf und Veröffentlichung in einer Pipeline haben wollte. Hätte ich nur einen visuellen Kalender und verlässliche Warteschlangen gewollt, wäre ich geblieben.

Wofür ich bezahlt habe und was schließlich den Ausschlag gab

Die aktuelle Preisübersicht von Buffer führt Essentials mit 5 $ pro Kanal und Monat bei jährlicher Abrechnung, während der kostenlose Tarif bis zu drei Kanäle und zehn geplante Beiträge pro Kanal zulässt. Meine vier bezahlten Kanäle standen damit bei jährlicher Abrechnung mit 20 $ pro Monat zu Buche. Das ist eine vernünftige Art, einen ausgereiften Planer zu verkaufen, aber es stellte mir genau das in Rechnung, was ich ausbauen wollte: eine Idee für mehrere Orte gleichzeitig umzuformen.

Ausschlaggebend war am Ende nicht der Preis. Ich schrieb meine Beiträge ohnehin mit einem Modell in einem separaten Fenster und fügte sie dann von Hand in den Planer ein. Zwei Werkzeuge bildeten eine offensichtliche Pipeline. Als ich den Workflow vor Augen hatte, den ich wollte, ergab ein Abo, das Entwurf und Veröffentlichung in zwei getrennten Hälften hält, für mich keinen Sinn mehr.

Was mein Workflow macht

Mein Workflow ist bewusst langweilig. Ein Schedule Trigger löst ein paar Mal am Tag aus, liest die nächste freigegebene Zeile aus meinem Google Sheet, passt den Text an jede Plattform an, schickt jede Fassung in ihren eigenen Veröffentlichungszweig und protokolliert das Ergebnis. Den Freigabestatus pflege ich von Hand im Sheet, und ich veröffentliche nur Zeilen, die ich freigegeben habe. Fehlgeschlagene Zweige lösen eine Benachrichtigung außerhalb von n8n aus, damit ein defektes Zugangsdatum nicht in einem Ausführungsprotokoll verschwindet.

Der Entwurfsschritt ruft die API eines gehosteten Modells auf. Kurz habe ich überlegt, ein Modell auf derselben Maschine zu betreiben, aber bei ein paar Dutzend Beiträgen pro Monat waren die Kostenfaktoren des Selbsthostens eines Modells größer als meine API-Rechnung. Nutzung, Datenschutz oder Latenz könnten diese Entscheidung kippen, aber ich hatte keinen Grund, zusätzliche Infrastruktur zu betreiben, nur um Social-Posts umzuschreiben. Der Workflow ist nicht raffiniert, und genau deshalb habe ich ihm vertraut.

Die Realität Plattform für Plattform (Instagram ist das Problem)

Drei meiner vier Zweige liefen weitgehend ereignislos. Instagram fraß mehr Zeit als der gesamte Rest des Projekts zusammen, und es war die Plattform, auf der ausgefallene Beiträge für mich am schwersten zu ignorieren waren. Die Tabelle zeigt die Wege, die ich genutzt oder geprüft habe; die Details darunter sind die Punkte, die mein Setup wirklich betrafen.

Für LinkedIn beschreibt die Dokumentation des LinkedIn-Nodes das Erstellen von Beiträgen für Personen und Organisationen, und n8ns Leitfaden zu den LinkedIn-Zugangsdaten hält fest , dass Posten als Organisation bedeutet, die eigene App durch LinkedIns Community Management App Review zu schicken. Das deckte meinen Bedarf. Die Dokumentation zu den X-Zugangsdaten besagt, dass X zeitbasierte Rate-Limits pro Endpunkt anwendet, abhängig von der Stufe des eigenen Entwicklerzugangsplans. Bei meinem Posting-Volumen bin ich nie an die Decke gestoßen, aber ich behandle es weiterhin als Limit, das X ändern kann, und nicht als Zusage von n8n.

Metas Leitfaden zur Inhaltsveröffentlichung dokumentiert JPEG als einziges unterstütztes Bildformat sowie ein Limit von 100 über die API veröffentlichten Beiträgen innerhalb eines gleitenden 24-Stunden-Fensters für den dokumentierten Weg. Die JPEG-Regel kostete mich einen Abend, weil meine Exporte standardmäßig PNG waren und der Fehler aus n8n heraus nicht offensichtlich war. Ich betrachte dieses Veröffentlichungslimit als an die aktuelle API-Route und -Version gebunden, nicht als dauerhaft.

In vier Monaten ging es zweimal kaputt. Beide Male Instagram. Langlebige Zugriffstokens sind nicht von Dauer, und Metas Referenz zur Token-Aktualisierung besagt, dass ein Token nur erneuert werden kann, solange es nicht abgelaufen und mindestens 24 Stunden alt ist. Verpasst man dieses Fenster, ist die Erneuerung nicht mehr der Weg zurück. Mein Fehler war, Authentifizierung als Einrichtungsarbeit zu behandeln statt als laufende Wartung. Ein Publishing-Workflow braucht eine Ablaufüberwachung, eine frühzeitige Erneuerung und eine Benachrichtigung, wenn die Verlängerung scheitert.

TikTok war schlicht kein Teil meines Ersatzes. Der Katalog der eingebauten App-Nodes führt es nicht. Ich hätte den HTTP-Request-Node, einen eigenen Node oder einen Community-Node nehmen können, aber damit wäre ich für mehr Umgang mit Zugangsdaten und mehr Ausfälle verantwortlich gewesen. Ich ersetzte einen Planer und meldete mich nicht freiwillig, noch eine Plattformintegration zu pflegen.

Die Kostenrechnung, meine Zeit eingerechnet

Als Referenz habe ich Buffer Essentials mit vier Kanälen genommen. Die unten genannten veröffentlichten Preise gelten für jährliche Abrechnung und wurden im August 2026 überprüft. Die Dollar- und Euro-Beträge habe ich in ihrer jeweiligen Währung belassen, statt so zu tun, als wären sie direkt gleichwertig.

Die Cloud-Preise von n8n setzen Starter ungefähr in dieselbe Einstiegspreisspanne wie meine vier Buffer-Essentials-Kanäle. Damit war die gemanagte Variante für meinen Fall erledigt: Ich hätte einen ähnlichen Monatsbetrag für eine Workflow-Engine gezahlt und dabei die schönere Veröffentlichungsoberfläche verloren. Der Vergleich zur Community Edition bestätigte, dass ich die grundlegende selbst gehostete Edition ohne Softwaregebühr behalten kann, aber Server und meine Zeit wurden dadurch nicht kostenlos.

Ich würde die Größe meiner Maschine auch nicht zu einer allgemeingültigen Produktionsuntergrenze von 4 GB RAM und 2 vCPU erklären. Die Deployment-Voraussetzungen von n8n geben eine breite Ressourcenspanne an. Meine Last ist klein, aber ein anderes Setup kann sich mit parallelen Ausführungen, Medien-Payloads, Code-Schritten, Datenbanklast und längerer Ausführungshistorie schnell verändern. Die ehrliche Antwort lautet: von der Last ausgehen und Speicher und CPU beobachten.

SQLite ist die Standarddatenbank von n8n und kann für ein Setup mit einer Instanz und geringem Volumen völlig ausreichen. Sobald die Ausführungshistorie zählt oder das Deployment wachsen soll, bevorzuge ich dennoch PostgreSQL. PostgreSQL braucht auch ein verteiltes Setup im Queue-Modus , denn n8n unterstützt diese Architektur über SQLite nicht. Diese Entscheidung treffe ich lieber beim Einrichten, als später eine Datenbank zu migrieren, wenn der Workflow schon wichtig geworden ist.

Der VPS war nie der teure Teil. Mein Wochenende schon. Dann kam der Abend, den JPEG mich kostete, dazu die Token-Ausfälle und die immer wiederkehrende Kontrolle, ob die Beiträge tatsächlich rausgegangen sind. Wenn ich meine eigenen Stunden überhaupt bepreise, schrumpft die Ersparnis schnell und kann ins Negative kippen. Das ist der Punkt, an dem Selbsthosting aufhört, günstig zu sein. Ich halte den Wechsel nach wie vor für richtig, aber in Woche eins hätte ich das nicht gesagt.

LESEN

Der selbstgehostete Stack für Indie-Hacker: der beste Weg, deine riesige SaaS-Rechnung zu ersetzen

Was kaputtging und was ich geändert habe

Die beiden sichtbaren Ausfälle waren Instagram-Token-Fehler, aber das tiefer liegende Problem war die Stille. Ein Abo-Planer gibt mir eine Produktoberfläche, die darauf ausgelegt ist, Kontoprobleme zu zeigen. Mein erster Workflow konnte innerhalb von n8n scheitern, während das öffentliche Symptom schlicht ein Tag ohne Beitrag war. Das hat mir beigebracht, dass ein selbst gehosteter Publisher laut scheitern und ohne Duplikate wieder hochkommen muss.

• Ich schicke Fehlerbenachrichtigungen an einen Kanal außerhalb von n8n, samt Plattformantwort und Workflow-Ausführungs-ID, damit ich nicht auf dasselbe System angewiesen bin, das mir sagen soll, dass es kaputt ist.
• Ich verfolge Token-Ablaufdaten und den Stand der App-Prüfungen und teste die Verlängerung früh genug, um neu zu autorisieren, bevor ein geplanter Beitrag zur ersten Warnung wird.
• Vor dem Veröffentlichen halte ich eine eindeutige Inhalts-ID fest. Damit kann ein fehlgeschlagener Plattformzweig es erneut versuchen, ohne auf bereits erfolgreichen Zweigen doppelt zu posten.
• Ich sichere das n8n-Datenvolume und die Datenbank und betrachte einen Restore-Test als Teil des Backups, statt darauf zu vertrauen, dass kopierte Dateien mich schon retten.
• Wo der Anbieter es zulässt, fixiere ich API-Versionen, lese die Changelogs und teste nach jeder Änderung auf n8n- oder Anbieterseite jeden Plattformzweig.
• Ausführungshistorie und Mediendateien räume ich nach der Aufbewahrung auf, die ich wirklich brauche, denn Social-Assets können aus einer winzigen Automatisierung ein unnötig großes Backup machen.

Von einer Kiste bei mir zu Hause würde ich das nicht betreiben. Ein für 9 Uhr geplanter Beitrag verlangt, dass der Workflow um 9 Uhr läuft, und Hausstrom, Anbindung, NAT und eingehende Callbacks bringen Variablen mit, die ich in einem Redaktionskalender nicht haben will. Ein VPS nimmt diese Heimnetz-Variablen weg. Meine Verantwortung für TLS, Backups, Monitoring, Updates und Wiederherstellung nimmt er mir nicht ab.

Wer das lieber lassen sollte

Bleiben Sie beim bezahlten Planer, wenn Sie einen Planer wollen. Das ist kein Trostpreis. Wenn Kalender, Vorschauen, einfache Freigaben, breite Kanalabdeckung und minimale Wartung Ihnen das Abo wert sind, ist der Kauf die richtige Entscheidung. Ohne Bedarf an maßgeschneiderter Automatisierung ist der Tausch dieser Oberfläche gegen eine Workflow-Leinwand ein Rückschritt mit Zusatzschritten.

Wenn Sie ein Produkt im Zuschnitt von Buffer wollen, das Ihnen selbst gehört, würde ich mir Postiz vor n8n ansehen. Die Open-Source-Version läuft auf dem eigenen Server, und die Plattformliste enthält TikTok unter mehr als 30 unterstützten Kanälen. Es ist ein Veröffentlichungskalender und keine Workflow-Leinwand, was es für viele, die einen bezahlten Planer verlassen, zum natürlicheren Landeplatz macht.

Ich würde es nur deshalb noch einmal tun, weil ich Recherche, Entwurf, Freigabe, Veröffentlichung und Protokollierung in einer Pipeline wollte. Das ist der Handel, den ich eingegangen bin: nicht kostenloses Planen, sondern Kontrolle, bezahlt mit Aufmerksamkeit. Bräuchte ich nur Planung, würde ich zum Abo zurückkehren.

Wenn Sie denselben Selbsthosting-Weg gehen möchten, unser n8n-Deployment mit einem Klick nimmt Ihnen den ersten Schritt der Serverinstallation ab. Es nimmt Ihnen nicht die Arbeit ab, die ich für wichtiger halte: Workflow-Zugangsdaten, Plattformfreigaben, Updates, Backups, Monitoring und die Wiederherstellung fehlgeschlagener Beiträge.

Häufig gestellte Fragen

Werden Buffer-Autorisierungen auf n8n übertragen?

Nein. Die Plattformverbindungen, die ich Buffer erteilt hatte, gehörten zu Buffers App und deren Autorisierungsfluss. Mein n8n-Workflow brauchte eigene Zugangsdaten, Tokens, Scopes und jede Plattformprüfung, die für das Konto oder den Veröffentlichungsweg nötig ist.

Sollte jede Social-Plattform einen eigenen Zweig bekommen?

Meistens ja. Ich habe getrennte Zweige verwendet, um Text, Medien, Zugangsdaten und Fehlerbehandlung je Plattform anzupassen. So konnte eine fehlgeschlagene Instagram-Anfrage es erneut versuchen, ohne einen Beitrag zu wiederholen, der auf X oder LinkedIn schon durch war.

Kann ein n8n-Workflow für mehrere Kunden veröffentlichen?

Ja, aber ich würde Zugangsdaten, Inhaltsquellen, Freigabestatus und Logs pro Kunde trennen. Plattformberechtigungen und Kontingente gelten weiterhin für die jeweilige App und das jeweilige Konto, deshalb sollte eine erfolgreiche Verbindung nie als universeller Zugang gelten.

Wie sollte ein Workflow verpasste Beiträge nachholen?

Ich frage freigegebene Beiträge ab, deren geplante Zeit verstrichen ist, und veröffentliche dann nur Datensätze ohne erfolgreiches Ergebnis. Eine eindeutige Inhalts-ID und die gespeicherte Plattformantwort verhindern, dass ein Neustart oder ein erneuter Versuch bereits verschickte Beiträge dupliziert.