Heimserver, NAS und Fernzugriff

Das Experiment

Alles, was du bisher gebaut hast, teilt eine stille Schwäche: Es lebt auf deinem Arbeitsgerät. Klappst du das Notebook zu, schweigen Agent (Projekt 2), Wissensassistent und Sprachkette. Ein Heimserver ändert das — ein kleines, sparsames Gerät, das durchläuft und deine Dienste für alle deine Geräte bereithält. Dieses Labor geht den ehrlichen Weg dorthin: Zuerst erlebst du Fernzugriff praktisch, mit dem Rechner, den du schon hast (CHF 0, 30 Minuten). Dann planst du Gerät und Software-Schicht — kaufen musst du heute nichts.

Die Bausteine (Stand Juli 2026)

Baustein	Werkzeug	Rolle
Tunnel	Tailscale (Katalog)	privates Mesh-VPN: deine Geräte erreichen einander verschlüsselt, ohne Portfreigabe; Personal-Plan «$0 Free forever», bis 6 Nutzer (anhand offizieller Preisseite geprüft)
Tunnel, selbstgebaut	WireGuard	das offene VPN-Protokoll darunter — laut Projekt «einfach, schnell, modern»; mehr Handarbeit, dafür ohne Anbieter-Konto (anhand offizieller Projektseite geprüft)
Modell-Server	Ollama (Katalog)	betreibt Modelle kopflos per API — bindet standardmässig nur 127.0.0.1:11434, per OLLAMA_HOST fürs Heimnetz freigebbar (anhand offizieller FAQ geprüft)
Haustür	Open WebUI (Katalog)	Weboberfläche für den Modell-Server: Chat vom Handy-Browser aus, mehrbenutzerfähig, RAG-Funktionen (anhand offizieller Doku geprüft)
Verpackung	Docker/Container	Dienste samt Umgebung in Kisten (KM10) — der offizielle Standardweg für Open WebUI

Der Begriff NAS (Network Attached Storage — ein Netzwerkspeicher: ein Gehäuse mit Festplatten, das Dateien für alle Geräte im Haus bereithält) bekommt unten einen eigenen Abschnitt — er spielt eine andere Rolle, als die Werbung verspricht.

Teil 1: Der Tunnel — Fernzugriff heute noch (ca. 30 Min.)

Du machst dein Notebook testweise zum Server und greifst vom Handy aus dem Mobilfunknetz darauf zu — also wirklich «von unterwegs», nicht nur vom Sofa:

1. Tailscale-Konto anlegen (Personal-Plan, kostenlos) und den Client auf dem Notebook installieren und anmelden. Was das tut: Dein Notebook tritt einem privaten Netz bei, das nur aus deinen angemeldeten Geräten besteht.
2. Tailscale-App aufs Smartphone, mit demselben Konto anmelden. In der Geräteliste siehst du jetzt beide Geräte samt ihrer Tailscale-Adresse (eine IP, die nur innerhalb deines privaten Netzes erreichbar ist — kein Scanner der Welt sieht sie).
3. LM-Studio-Server fürs Netzwerk öffnen: Im Developer-Bereich die Option «Serve on Local Network» aktivieren (offizielle Servereinstellung; anhand der Doku geprüft). Damit nimmt der Server Anfragen von anderen Geräten an — auch durch den Tunnel.
4. Der Moment der Wahrheit: WLAN am Handy ausschalten (Mobilfunk!), im Browser http://<Tailscale-Adresse-des-Notebooks>:1234/v1/models öffnen. Erscheint die Modellliste als Textantwort, hast du gerade von draussen sicher auf deine lokale KI zugegriffen — durch einen verschlüsselten Tunnel, ohne dass irgendetwas öffentlich im Internet steht.
5. Kontrollpunkt und Rückbau: Tailscale am Handy trennen → die Adresse ist unerreichbar (genau so soll es sein). Danach «Serve on Local Network» wieder ausschalten — für den Alltag auf dem Arbeitsnotebook gilt: nur localhost, solange kein Dauerbedarf besteht.

Rücksetzweg: Servereinstellung zurückstellen, Tailscale auf beiden Geräten abmelden und deinstallieren, Konto löschen — alles ist wie vorher.

Teil 2: Den Heimserver planen (ca. 25 Min.)

Das Notebook-Experiment zeigt auch die Grenze: Ein Arbeitsgerät ist kein Server — es wird zugeklappt, neu gestartet, mitgenommen. Plane jetzt das Dauergerät, in zwei Listen:

1. Dienste-Inventar: Was soll dauerhaft laufen? Typische Kandidaten aus dem Kurs: der Posteingangs-Agent (Projekt 2), der multimodale Assistent (Projekt 3), der Wissensassistent (Projekt 1), die Smart-Home-Zentrale (Labor 6) — und ein Modell-Server, den alle gemeinsam nutzen. Notiere pro Dienst: braucht er das grosse Modell, oder reicht die 1–4B-Klasse?
2. Gerätewahl — dieselbe Denkweise wie im Hardware-Finder, auf Dauerbetrieb gemünzt:

Gerät	Kosten	Ehrliche Einordnung
Ausgemustertes Notebook/PC	CHF 0	der beste Start: vorhanden, x86, genug RAM für erste Dienste — dafür nicht auf Sparsamkeit gebaut
Gebrauchter Business-Mini-PC (ThinkCentre Tiny u. ä.)	ca. CHF 65–360 (Beleg Labor 1, Konfiguration 9)	der Kurs-Standardweg: leise, klein, refurbished mit Garantie; CPU-Inferenz trägt die 1–4B-Klasse, grössere Modelle laufen zäh
Raspberry Pi 4/5	falls vorhanden CHF 0, sonst → Labor 1	ideal für die Smart-Home-Zentrale (Labor 6); für Sprachmodelle die unterste Schublade — fürs Volltext-Whisper empfiehlt schon die HA-Doku stärkere Klassen
Mac mini	→ Labor 2	der leise Premium-Kandidat: Unified Memory trägt auch mittlere Modelle — dafür der teuerste Einstieg

3. Stromfrage stellen: Ein Dauerläufer läuft 8’760 Stunden im Jahr — überschlage Verbrauch × Strompreis für dein Wunschgerät (Rechnung selbst anstellen; als Näherung behandeln — Herstellerangaben gelten für Leerlauf, nicht unter KI-Last). Genau deshalb gewinnt der sparsame Mini-PC gegen den alten Gaming-Tower, auch wenn dieser «gratis» wäre.

Kontrollpunkt: Du hast ein Gerät gewählt und kannst in einem Satz begründen, warum es zu deinem Dienste-Inventar passt — inklusive dessen, was es nicht können wird.

Teil 3: Die Software-Schicht (ca. 25 Min.)

Auf dem Server arbeitet dieselbe Technik wie auf deinem Notebook — nur kopflos (ohne Bildschirm bedient) und im Netz erreichbar:

1. Modell-Server: Ollama. LM Studio ist auf Bedienung am Bildschirm ausgelegt; für den Server-Betrieb ist Ollama das Katalog-Zweitwerkzeug — Modelle per Befehl und API, ohne Oberfläche. Wichtigste Betriebsregel (anhand offizieller FAQ geprüft): Ollama lauscht ab Werk nur auf dem Gerät selbst (127.0.0.1, Port 11434); erst die Umgebungsvariable OLLAMA_HOST öffnet ihn fürs Heimnetz. Diese Vorsicht ab Werk ist dieselbe Logik wie dein Tunnel-Experiment: Nichts ist erreichbar, was du nicht bewusst freigibst.
2. Haustür: Open WebUI. Damit alle Hausgeräte bequem chatten können, kommt eine Weboberfläche vor den Modell-Server: Open WebUI spricht Ollama und OpenAI-kompatible Schnittstellen, läuft komplett offline und ist mehrbenutzerfähig — Partner und Kinder bekommen eigene Zugänge statt deiner Chatverläufe. Offizieller Installationsweg ist ein Docker-Container (alternativ pip) (anhand offizieller Doku geprüft). Lizenz-Fussnote für Genauigkeitsliebhaber: seit v0.6.6 BSD-3 mit Branding-Schutzklausel — für Heim-Installationen ohne praktische Folgen.
3. Zentrale + KI auf einem Gerät (das Versprechen aus Labor 6): Home Assistant und Ollama teilen sich den Mini-PC; die HA-Ollama-Integration verbindet beide — offiziell als experimentell gekennzeichnet, mit der Labor-6-Regel «wenige Entities, Nie-Liste gilt». Rechne die KM2-Regel gegen: Zentrale und Sprachpipeline sind genügsam, das Sprachmodell bestimmt den RAM-Bedarf — für die 8B-Klasse ist der CHF-65-Mini-PC nicht gebaut, für Regeln, Assist und ein 1–4B-Modell schon eher (Einordnung auf Basis der belegten Labor-1/6-Aussagen; nicht selbst im Dauerbetrieb getestet).

Vertiefung: Warum Docker auf Servern Standard ist

Ein Server sammelt über die Jahre Dienste — und jeder bringt eigene Abhängigkeiten, Versionen und Update-Rhythmen mit. Container (KM10) verpacken jeden Dienst samt Umgebung in eine eigene Kiste: Open WebUI lässt sich so in einer Zeile installieren, aktualisieren und rückstandsfrei entfernen, ohne dass er Python-Versionen oder Bibliotheken der anderen Dienste berührt. Für dein Notebook wäre das Overkill — für ein Gerät, das jahrelang durchlaufen soll, ist es die billigste Ordnung, die es gibt.

Und wo bleibt das NAS?

Das NAS hat im Heimnetz eine klare Rolle: Speicher und Backup — Fotos, Dokumente und die Wissensordner deiner Assistenten liegen zentral und redundant (mehrere Platten, eine darf ausfallen). Für Backups gilt die klassische 3-2-1-Faustregel (bewährte Branchenregel, als Näherung zu verstehen): drei Kopien, zwei verschiedene Medien, eine ausser Haus. Was ein NAS dagegen nicht sein muss: dein KI-Rechner. Die Marketing-Kategorie «NAS mit KI-Funktion» bezahlt teuer, was ein gebrauchter Mini-PC daneben günstiger erledigt — das ist wörtlich der typische Fehlkauf aus Labor 1, Konfiguration 9. Saubere Arbeitsteilung: Das NAS hütet die Daten, der Mini-PC rechnet, der Tunnel verbindet beide mit deinen Geräten.

Risiken

• Dauerbetrieb ist Verantwortung: Ein Server, den niemand aktualisiert, wird mit jedem Monat angreifbarer — plane den Update-Blick fest ein (Monatsrhythmus, wie das Log-Ritual aus Projekt 2). Wer das nicht will, fährt mit «Dienste nur bei Bedarf am Notebook» ehrlicher.
• Der Tunnel ist die einzige Tür: Bequemlichkeit wird dich irgendwann zur Portfreigabe verführen («nur schnell für die Ferien»). Nicht tun — jede Ausnahme bricht das KM9-Grundgesetz genau dort, wo es zählt.
• Stromkosten schleichen: Ein vergessener alter Tower als «Server» kostet übers Jahr real Geld — die Stromfrage aus Teil 2 gehört in jede Gerätewahl.
• Daten ohne Backup: Sobald Wissensordner und Protokolle auf den Server ziehen, hängt alles an einem Gerät — ohne 3-2-1-Backup ist der Heimserver ein Klumpenrisiko.
• Die Bastelfalle (wie Labor 6): Ein Heimserver ist ein Hobby mit offenem Ende. Ein Dienst zuerst, stabil betreiben, dann erweitern.

Erweiterungen

• Projekt 3 zieht um: Kern und Kanäle deines multimodalen Assistenten aufs Dauergerät — der Assistent ist da, ohne dass dein Notebook läuft.
• Labor-6-Stufe-3 real: Home Assistant plus Ollama auf dem geplanten Gerät — die Automations-Pyramide bekommt ihre experimentelle Spitze.
• Tunnel ohne Anbieter: WireGuard (oder Headscale als selbstgehostete Tailscale-Koordination, Katalog-Hinweis) statt Tailscale — mehr Handarbeit, null Konto.
• Familien-Chat: Open WebUI mit eigenen Zugängen pro Person — dein lokales Modell als Haus-ChatGPT, komplett offline.

Kurz geprüft

3 Fragen zum Festigen — Feedback kommt sofort.

Du willst von unterwegs auf deine Heim-KI zugreifen. Der kurssichere Weg?

VPN-Tunnel (z. B. Tailscale): Dienste bleiben privat, erreichbar sind sie nur für meine angemeldeten Geräte.Erst der Tunnel, dann der Dienst — öffentlich ist gar nichts.Portfreigabe im Router — dafür ist sie ja da.Damit steht der Dienst jedem Scanner der Welt offen; genau das verbietet das KM9-Grundgesetz.Den Server-Port einfach auf eine ungewöhnliche Nummer legen.Scanner prüfen alle Ports — Verstecken ist keine Sicherheit, der Tunnel schon.

Warum lauscht Ollama ab Werk nur auf 127.0.0.1?

Sicherheits-Voreinstellung: Erreichbar ist nur, was du bewusst freigibst — die Öffnung fürs Heimnetz ist ein aktiver Schritt (OLLAMA_HOST).Ein technischer Fehler, den man immer beheben muss.Es ist Absicht — dieselbe Logik wie beim Tunnel: sicherer Zustand als Standard.Weil Ollama nur ein Gerät gleichzeitig bedienen kann.Mit OLLAMA_HOST bedient Ollama das ganze Heimnetz — die Bindung ist eine Sicherheits-, keine Leistungsgrenze.

Im Laden steht ein teures «NAS mit KI-Funktion». Deine Kurs-Antwort?

Arbeitsteilung ist günstiger: NAS für Speicher und Backup, ein gebrauchter Mini-PC rechnet — zusammen meist besser und billiger.Der Labor-1-Fehlkauf in neuer Verpackung: Man bezahlt den Namen, nicht die Leistung.Kaufen — ein Gerät für alles ist immer effizienter.Die «KI-Funktion» solcher Geräte ist meist schwächer als ein CHF-200-Mini-PC daneben.NAS sind veraltet, alles gehört auf den Mini-PC.Für redundanten Speicher und Backups bleibt das NAS genau richtig — nur eben als Speicher, nicht als KI-Rechner.

Das kann ich jetzt

• Ich habe von unterwegs durch einen VPN-Tunnel auf meinen lokalen Modell-Server zugegriffen — und kann erklären, warum dieser Weg jede Portfreigabe schlägt.
• Ich kann ein Heimserver-Setup planen: Dienste-Inventar, Gerätewahl mit Strom- und Preisargument, Arbeitsteilung zwischen Server, NAS und Tunnel.
• Ich kenne die Server-Bausteine Ollama (kopfloser Modell-Server, bewusst freigeben), Open WebUI (Haustür für alle Hausgeräte) und Container (Ordnung für Dauerbetrieb) in ihren Rollen — und weiss, welche Modellklasse mein Wunschgerät realistisch trägt.