e.V.
Lösungen · Governance · Live · geprüft 2026-05-21

Eigenbetrieb auf einem Mac Mini

Die ganze Vereins-Infrastruktur läuft auf einer überschaubaren Maschine in der Schweiz, nicht in einer Hyperscale-Cloud. Wir können sie sehen, anfassen, abschalten — und wissen, was sie verbraucht.

These
Souveränität fängt damit an, dass jemand im Verein die Stromrechnung der Hardware kennt, auf der die Daten liegen.
Was wir tun

Eigenbetrieb klingt wie Sturheit. Die Frage ist nicht „warum nicht einfach AWS?” — die Frage ist, was Eigenbetrieb leistet, das eine gemietete Cloud nicht leistet.

Erstens: Sichtbarkeit. Wenn die Plattform-Maschine im Wohnzimmer steht, weiß jemand im Verein, dass sie ungefähr 30 Watt zieht und nachts kühler läuft als tagsüber. Wir können die Stromrechnung benennen, wir können den Verbrauch in den Transparenzbericht schreiben. Bei einer Cloud-Rechnung steht dort eine Zahl ohne physikalische Entsprechung.

Zweitens: Datenschutz auf Hardware-Ebene. Niemand außer Vereins- Mitgliedern hat physischen Zugriff. Es gibt keinen Cloud-Anbieter, der unter Cloud-Act-Druck gestellt werden könnte. Die Daten sind in der Schweiz, weil die Maschine in der Schweiz steht — nicht, weil ein Vertrag das verspricht.

Drittens: Ehrlichkeit über Skalen. Ein Mac Mini macht keine 9-9er- Verfügbarkeit. Wir versprechen sie auch nicht. Was darauf läuft, braucht keine Hyperscale-Resilience, weil das, was darauf läuft, keine Hyperscale-Software ist. Es ist Vereins-Software für ein paar tausend Nutzer:innen, mit der Servicequalität, die das ehrlich erwarten lässt.

Die Risiken: Single-Point-of-Failure, fehlendes Off-Site-Backup, keine Hardware-Redundanz. Diese stehen in den offenen Punkten und sind kein Geheimnis. Wir lösen sie nach und nach. Bis dahin operieren wir auf einer Maschine, die wir kennen — was nicht selbstverständlich ist in einer Industrie, die das Wort „Infrastruktur” inzwischen synonym mit „undurchsichtig” gebraucht.

Umsetzung

Wie genau das funktioniert

  • Ein Apple Mac Mini M4 mit externer ManaData-SSD als zentrale Plattform-Maschine. Standort: Schweiz, Wohnzimmer.
  • Compose-basiertes Container-Setup, ~25 Services für 11 Apps — Postgres, Redis, MinIO, alle Plattform-Services, Stalwart-Mail.
  • GPU-Inferenz auf separater Box mit eigener Souveränitäts-Logik (`mana-llm`, `mana-stt`, `mana-tts`).
  • Cloudflared-Tunnel als einzige öffentliche Anbindung — keine offenen Ports am Heim-Router, kein VPN-Konzentrator.
  • Backup-Cron lokal aktiv (18 DBs / 9 Container / 46 GB), off-site in Vorbereitung.
  • Strom-Verbrauch dokumentiert in der Transparenz-Übersicht; die ganze Verein-IT braucht ungefähr so viel wie ein Standby-Kühlschrank.
Trade-offs

Was uns das kostet

Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.

  • Ein Mac Mini ist ein Single Point of Failure. Wir tauschen Hyperscale-Resilience gegen Übersichtlichkeit — bewusst, aber nicht ohne Risiko.
  • Off-Site-Backup ist noch nicht produktiv. Solange das so ist, überlebt der Verein einen Wohnungs-Brand digital nicht.
  • Skalierung über die Apple-Mini-Klasse hinaus erfordert architektonische Arbeit, die wir bei einer Cloud nicht hätten — das nehmen wir hin, solange wir unter dieser Schwelle bleiben.
Diagnose

Welche Probleme dieser Lösung adressiert

Diagnose ohne Antwort ist Lamentation; Antwort ohne Diagnose ist Ingenieurs-Spielerei. Hier verbindet sich beides.

Stand

Offene Punkte

  • Off-Site-Backup-Endpoint muss festgelegt werden — Vorschlag: zweiter Mac Mini in Süddeutschland, periodisch synchronisiert.
  • Hardware-Redundanz für den Krisenfall (zweite Maschine als warmer Standby) ist nicht eingerichtet.

Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.