Von Mastodon zu snac: Ein Fediverse-Server, der in einen Ordner passt

Permalink 4 min read Published: 2026-05-16

infrastructure fediverse #snac #mastodon #fediverse #activitypub #kubernetes #volsync #migration

Warum ich den ausgewachsenen Mastodon-Stack gegen snac getauscht habe — einen ActivityPub-Server ohne Datenbank, Cache oder Object-Storage

Table of contents

Vor einer Weile habe ich ausführlich beschrieben, wie meine Mastodon-Instanz auf Kubernetes aufgebaut ist — und schon damals durchklang, dass dieser Stack für genau ein menschliches Konto reichlich überdimensioniert ist. Inzwischen habe ich die Konsequenz gezogen: this-is-fine.social läuft heute auf snac , einem ActivityPub-Server, der in einen einzigen Verzeichnisbaum passt.

Was Mastodon wirklich kostet

Mastodon ist exzellente Software — aber es ist eben kein Programm, sondern ein kleines verteiltes System. Für meinen einen Account hielt ich am Ende diese ganze Maschinerie am Laufen:

Schicht	Mastodon	Betriebsaufwand
App	web + streaming + sidekiq	mehrere Prozesse, große Images
Datenbank	CloudNativePG, 3 Instanzen	Cluster, WAL, Backups, Upgrades
Cache	Dragonfly (Redis-kompatibel)	eigenes Deployment + Snapshots
Medien	Rook-Ceph RGW (S3)	Bucket, Policy, Zugangsdaten

Jede dieser Schichten will gepflegt, überwacht und gesichert werden. Für eine Plattform mit tausenden Nutzern ist das angemessen. Für ein persönliches Konto auf der eigenen Domain ist es schlicht zu viel Software, die nachts kaputtgehen kann.

snac dreht die Gleichung um

snac („Social Networks Are Crap“) ist ein minimaler ActivityPub-Server in portablem C. Der entscheidende Unterschied: keine Datenbank, kein Cache, kein Object-Storage. Der gesamte Zustand — Beiträge, Folgebeziehungen, Medien — liegt in einem Verzeichnisbaum unter SNAC_BASEDIR. Föderiert wird trotzdem voll mit Mastodon, Pleroma und Co., und für Clients spricht snac sogar eine Mastodon-kompatible API.

Aus dem Stapel beweglicher Teile wird damit ein einziger Pod auf einem einzigen PVC:

flowchart TB subgraph BEFORE["vorher · Mastodon"] direction TB MW["web / streaming / sidekiq"] PG[("PostgreSQL ×3")] RD[("Dragonfly")] S3[("Rook RGW · S3")] MW --> PG & RD & S3 end subgraph AFTER["nachher · snac"] direction TB SN["snac :8001"] PVC[("ein PVC<br/>/snac/data")] SN --> PVC end BEFORE -->|"weniger Moving Parts"| AFTER

Im Cluster ist das ein unspektakuläres Deployment: ein Container aus meiner eigenen, signierten Registry (oci.this-is-fine.io/snac/snac), SNAC_BASEDIR=/snac/data, Port 8001, dazu server.json und style.css aus einer ConfigMap. Das war’s.

GitOps macht den Wechsel sichtbar

Der eigentliche Umzug bestand im GitOps-Repo aus zwei Zeilen: Mastodon raus, snac rein. Genau das steht heute in der zentralen Overlay-Kustomization — und weil das Repo den Ist-Zustand beschreibt, ist Mastodon damit auch wirklich aus dem Cluster verschwunden:

  # fediverse-system
  - ../../applications/fediverse-system/snac
  # NOTE: Way too bloated - Keeping for reference only
  #- ../../applications/fediverse-system/mastodon

Nach außen hängt snac an derselben HTTPRoute-Logik wie zuvor Mastodon: Host this-is-fine.social, die Föderations-Pfade (/.well-known/webfinger, host-meta, nodeinfo) und die Mastodon-API (/api/v1, /api/v2, /oauth) zeigen allesamt auf den snac-Service. Die Domain im Fediverse bleibt also dieselbe — nur dahinter steht jetzt ein Bruchteil der Software.

Backups werden trivial

Das ist mein liebster Nebeneffekt. Statt Datenbank-Dumps, Bucket-Kopien und Cache-Snapshots zu orchestrieren, kollabiert die gesamte Sicherung auf einen PVC. snac klinkt sich einfach in dasselbe VolSync-Restic-Muster ein wie jede andere Anwendung — ein dependsOn: volsync, ein paar gestempelte Variablen, fertig. Restore heißt: Verzeichnisbaum zurückspielen, Pod starten.

snac nutzt Hard Links für eine effiziente Medien-Ablage. Beim Restore eines solchen Baums sollte man darauf achten, die Hard Links zu erhalten (rsync -H, tar -H), sonst bläht sich das Verzeichnis unnötig auf. VolSync mit restic snapshotet den PVC ohnehin konsistent — der Punkt ist nur beim manuellen Hantieren relevant.

Account-Umzug und Trade-offs

Den eigentlichen Konto-Umzug nimmt einem das Fediverse-Protokoll weitgehend ab: Follows, Listen und Blocks als CSV aus Mastodon exportieren, in snac importieren, einen Alias setzen und auf Mastodon den „Move“-Mechanismus auslösen, der die Follower auf den neuen Handle umzieht.

Ein Account-Move im Fediverse braucht die Kooperation der Gegenstellen — die Remote-Server müssen den Umzug akzeptieren, und DNS sowie ActivityPub-Handles müssen zusammenpassen. Vor dem Umschalten lohnt der Blick in das snac-Manual und in einen Migrationsleitfaden.

Ehrlich bleibt: snac ersetzt nicht jedes Mastodon-Feature. Moderation, Listen und die Admin-Oberfläche sind dünner, das Web-UI ist bewusst karg. Für mein Lab ist genau das der Punkt — weniger Software, weniger nächtliche Überraschungen, dieselbe Präsenz im Fediverse. Ein gutes Tauschgeschäft.

Fazit

Manchmal ist der größte Fortschritt, Dinge wegzunehmen. Aus vier zustandsbehafteten Schichten ist ein Pod mit einem Ordner geworden — und das Fediverse merkt davon nichts. Mastodon bleibt großartige Software; sie war für meinen Anwendungsfall nur die falsche Größe.