Selbstgehosteter Social-Media-Scheduler: Open-Source-Alternative zu Buffer

Social-Media-Manager kennen das Problem: Jeden Morgen hastig Posts für alle Kanäle zu erstellen, während man eigentlich strategisch planen möchte. Die meisten Scheduler-Lösungen zwingen Nutzer dazu, ihre Entwürfe, Analytics und Zugangsdaten auf fremden Servern zu hinterlegen. Doch was wäre, wenn man ein eigenes, selbstgehostetes System nutzen könnte – kostenlos und ohne Kompromisse bei der Datenhoheit?

Genau diese Lücke schließt TryPost, ein Open-Source-Projekt, das als Alternative zu kommerziellen Tools wie Buffer oder Hootsuite entwickelt wurde. Die Software ermöglicht es, Posts im Voraus für bis zu zehn Plattformen zu planen – von X (ehemals Twitter) über LinkedIn bis hin zu Mastodon – und läuft vollständig auf dem eigenen Server. Basierend auf Laravel 13 und Vue 3 mit Inertia setzt das Tool auf bewährte Technologien, die Entwicklern vertraut sind. Besonders innovativ ist die Integration eines MCP-Servers, der KI-Tools wie Claude oder Cursor direkt in den Veröffentlichungsprozess einbindet.

Ein zentraler Mechanismus für zehn verschiedene Plattformen

Die größte Herausforderung bei Social-Media-Schedulern liegt nicht in der Benutzeroberfläche, sondern in der Komplexität der API-Integrationen. Jede Plattform definiert eigene Regeln: X erlaubt maximal 280 Zeichen, LinkedIn 3.000. Instagram verlangt zwingend ein Bild, während Threads und Bluesky eigene Protokolle nutzen. Eine saubere Architektur erfordert daher eine klare Trennung zwischen der Anwendungslogik und den plattformspezifischen Anforderungen.

In TryPost wird diese Trennung durch ein Enum realisiert, das alle unterstützten Netzwerke auflistet und deren individuelle Eigenschaften zentral verwaltet:

enum Platform: string
{
    case X = 'x';
    case LinkedIn = 'linkedin';
    case Instagram = 'instagram';
    case Threads = 'threads';
    case Bluesky = 'bluesky';
    // ... weitere Netzwerke
    
    public function maxContentLength(): int
    {
        return match ($this) {
            self::X => 280,
            self::LinkedIn => 3000,
            // ... weitere Netzwerke
        };
    }

    public function queue(): string
    {
        return "social-{$this->value}";
    }
}

Jeder Plattform wird eine konkrete Publisher-Klasse zugeordnet, die genau eine API-Schnittstelle bedient. Ein Service-Locator wählt zur Laufzeit die passende Implementierung aus, ohne dass die Kernlogik des Schedulers angepasst werden muss:

private function publisher(): SocialPublisher
{
    return match ($this->postPlatform->platform) {
        Platform::X => app(XPublisher::class),
        Platform::LinkedIn => app(LinkedInPublisher::class),
        Platform::Instagram => app(InstagramPublisher::class),
        // ... weitere Netzwerke
    };
}

Die Schnittstelle aller Publisher-Klassen ist einheitlich: Sie erhalten einen Post als Eingabe und liefern eine Post-ID sowie die öffentliche URL zurück. So bleibt die Integration neuer Plattformen auf ein Minimum reduziert – eine einfache Erweiterung des Enums und die Implementierung einer neuen Klasse genügen.

OAuth und die Fallstricke beim Token-Refresh

Die Authentifizierung mit externen Plattformen erfolgt über OAuth 2.0, wobei TryPost die Bibliothek Laravel Socialite nutzt – inklusive benutzerdefinierter Provider für Netzwerke wie Instagram, die nicht standardmäßig unterstützt werden. Besonders kritisch ist dabei die Verwaltung der Zugangstokens, da diese sensible Daten darstellen. Laravel bietet mit dem encrypted-Cast eine einfache Lösung, um Tokens sicher in der Datenbank zu speichern:

protected function casts(): array
{
    return [
        'access_token' => 'encrypted',
        'refresh_token' => 'encrypted',
        'token_expires_at' => 'datetime',
        'scopes' => 'array',
    ];
}

Ein häufig unterschätzter Fehler tritt auf, wenn Refresh-Tokens rotieren. Einige Plattformen wie LinkedIn generieren bei jedem Refresh einen neuen Token – und machen den alten sofort ungültig. In einem Szenario mit mehreren geplanten Posts, die gleichzeitig veröffentlicht werden sollen, kann dies zu einem Wettlauf führen: Mehrere Jobs versuchen gleichzeitig, den Token zu erneuern, doch nur der erste Erfolg führt zum Ziel. Die Folge: Vier Jobs scheitern mit der Meldung "Ungültiger Token", obwohl die Authentifizierung eigentlich noch gültig war.

TryPost begegnet diesem Problem mit zwei Maßnahmen:

• Vorabprüfung der Tokens: Bevor ein Refresh durchgeführt wird, wird zuerst versucht, den Post zu veröffentlichen. Nur bei einer 401-Fehlermeldung (Token abgelaufen) wird der Refresh-Prozess ausgelöst.
• Token-Rotation mit Sperre: Beim tatsächlichen Refresh wird ein Cache-Lock verwendet, um sicherzustellen, dass nur ein Job zur gleichen Zeit den Token aktualisiert. Andere Jobs warten auf das Ergebnis und nutzen den neuen Token.

public function publishWithFreshToken(PostPlatform $postPlatform): array
{
    try {
        return $this->publisher()->publish($postPlatform);
    } catch (TokenExpiredException) {
        $this->refreshToken($postPlatform->socialAccount);
        return $this->publisher()->publish($postPlatform);
    }
}

public function refreshToken(SocialAccount $account): void
{
    $lock = Cache::lock("token-refresh:{$account->id}", 30);
    if (!$lock->get()) {
        $account->refresh(); // Ein anderer Job rotiert bereits den Token
        return;
    }
    try {
        match ($account->platform) {
            Platform::LinkedIn => $this->refreshLinkedIn($account),
            Platform::X => $this->refreshX($account),
            // ... weitere Netzwerke
        };
    } finally {
        $lock->release();
    }
}

Planung mit doppelter Absicherung: Ein Post, eine Veröffentlichung

Der Kern eines jeden Schedulers ist die Veröffentlichungslogik. TryPost nutzt einen einfachen, aber effektiven Ansatz: Ein Cron-Job läuft jede Minute und prüft nach Posts, die zum aktuellen Zeitpunkt veröffentlicht werden sollen. Für jeden dieser Posts wird ein Job in die Warteschlange gestellt.

// routes/console.php
Schedule::command(ProcessScheduledPosts::class)
    ->everyMinute()
    ->withoutOverlapping()
    ->onOneServer();

Kritisch ist dabei die Gewährleistung, dass jeder Post genau einmal veröffentlicht wird – selbst wenn zwei Worker gleichzeitig aktiv sind oder der Scheduler kurzzeitig überlappt. TryPost löst dies durch eine atomare Statusaktualisierung, die gleichzeitig als Sperre dient:

public function handle(): void
{
    Post::query()->due()->each(function (Post $post) {
        $claimed = Post::whereKey($post->id)
            ->where('status', Status::Scheduled)
            ->update(['status' => Status::Publishing]);
        
        if ($claimed === 1) {
            PublishPost::dispatch($post);
        }
    });
}

Nur der Worker, dessen UPDATE-Befehl die Statusänderung von Scheduled zu Publishing erfolgreich durchführt, darf den Publish-Job auslösen. Alle anderen sehen null betroffene Zeilen und überspringen den Post. Diese Lösung kommt ohne verteilte Sperren oder zusätzliche Infrastruktur aus und bleibt damit schlank und wartbar.

Zukunftsperspektiven: Mehr Automatisierung, mehr Plattformen

TryPost zeigt, wie mit modernen Frameworks wie Laravel und Vue 3 eine voll funktionsfähige, selbstgehostete Alternative zu etablierten Social-Media-Tools entstehen kann – ohne Kompromisse bei Kontrolle oder Datenschutz. Die modulare Architektur ermöglicht es, neue Plattformen mit minimalem Aufwand zu integrieren, während die robuste Token-Verwaltung und die zuverlässige Publish-Logik den Betrieb stabil halten.

Mit der wachsenden Bedeutung von dezentralen Netzwerken wie Mastodon und Bluesky könnte die Nachfrage nach Tools wie TryPost weiter steigen. Zudem eröffnet die Integration von KI-Assistenten über den MCP-Server neue Möglichkeiten für automatisierte Content-Erstellung und -Planung. Entwickler, die nach einer datenschutzfreundlichen und flexiblen Lösung für ihr Social-Media-Management suchen, finden in diesem Projekt einen vielversprechenden Einstiegspunkt – und die Möglichkeit, selbst zur Weiterentwicklung beizutragen.