mana-server

Ein einziges Gerät. Darauf laufen alle Apps des Vereins, alle Plattform-Services, alle Datenbanken, alle Object-Storage-Buckets, alle Hintergrund-Worker. Keine AWS-Region, kein Hetzner-Rechenzentrum, kein gemieteter Hyperscaler-Tenant.

Die Plattform passt auf einen Mac mini M4 (2024 base) mit 10 Cores (4 Performance + 6 Efficiency), 16 GB unified Memory und 256 GB interner SSD. Daneben hängt eine 4 TB-USB-SSD mit dem Namen ManaData: dort liegen alle Postgres-Volumes und alle MinIO-Buckets, 753 GB belegt (Stand 2026-05-21).

Konkret heißt das gerade: 107 Container in 22 Compose-Projekten, davon 103 dauerhaft laufend. Darunter 17 eigenständige Postgres-Datenbanken — eine pro Service, schema-isoliert via Drizzle pgSchema. Wer einen Service löscht, löscht eine ganze DB, nicht ausgewählte Tabellen in einer fremden Cloud.

Das ist kein Trick — es ist die direkte Konsequenz davon, dass Verein-Services schlank gebaut sind und sich Hardware teilen statt jede für sich Resources zu beanspruchen. Ehrlich gerechnet ist das Gerät teurer im Strom über fünf Jahre als in der Anschaffung — aber beides liegt jeweils im niedrigen vierstelligen Bereich, nicht im Hyperscaler-Universum.

Standort: Minergie-Sparhaus in Tägerwilen (Schweiz), betrieben mit nachhaltig erzeugtem Strom. Wer wissen will, wo seine Daten liegen, bekommt eine Adresse statt einer SLA-Klausel.

Was die Maschine nicht kann: Hochverfügbarkeit. Wenn der Mac mini ausfällt — Hardware-Tod, Stromausfall, Internet-Ausfall — ist die ganze Plattform offline, bis er wieder läuft. Drei Antworten darauf sind in Arbeit:

• Failover auf den GPU-Server als Zwischenschritt — der zweite Verein-Rechner steht im selben Haus und kann bei Hardware-Ausfall die Last übernehmen. Konzept und Varianten in docs/SERVER_FAILOVER.md.
• Geografische Redundanz über mana-server-2 an einem zweiten Schweizer Standort, sobald der Verein juristisch verankert ist.
• Strom-Souveränität über die geplante Solar-Eigenversorgung, beschrieben in docs/STROM_AUTARKIE.md.