TrueNAS Apps-Katalog produktiv: wann die eingebauten Apps das zweite System ersetzen können

Der Apps-Katalog in TrueNAS ist eines der Features, bei denen wir in den letzten zwei Jahren den größten Haltungswechsel gesehen haben. Noch 2024 war die Grundregel bei vielen Admins: “Container auf dem Dateiserver? Niemals.” Mit TrueNAS 25.10 Goldeye und einem jetzt wirklich erwachsenen Apps-Katalog ist diese Regel differenzierter geworden. In KMU-Umgebungen ersetzen die eingebauten Apps immer öfter das klassische “zweite System” — oft einen kleinen Linux-Server oder eine Proxmox-VM, die niemand so richtig pflegen wollte. Dieser Artikel zeigt, wann wir den TrueNAS Apps-Katalog produktiv empfehlen, wann wir trotzdem auf einen separaten Host setzen und welche Workloads sich in der Praxis bewährt haben.

Was im TrueNAS Apps-Katalog 2026 wirklich drin ist

Unter der Haube läuft seit TrueNAS Scale 25.04 Fangtooth ein Docker-basierter Stack — also keine klassische Kubernetes-Schicht mehr wie in früheren Scale-Versionen, sondern Docker Compose als Laufzeit mit TrueNAS-eigener Orchestrierung darüber. Für uns als Partner heißt das: das, was im Apps-Tab läuft, ist am Ende ein Linux-Container, der auf einem Dataset persistente Daten ablegt. Das macht die Lösung berechenbar.

Im offiziellen Katalog finden wir heute unter anderem:

• Nextcloud als vollständige Dateiplattform mit Office-Integration
• Vaultwarden als selbstgehosteten Bitwarden-kompatiblen Passwortmanager
• Grafana inklusive Prometheus-Backend für kleine Monitoring-Setups
• Jellyfin als Media-Server (relevanter für ambitionierte Praxen und Vereine als für klassische Industrie-KMU)
• Immich als Foto-Backup-Ziel für Smartphones
• Paperless-ngx für dokumenten-basierte Workflows
• Authentik als zentralen Identity-Provider
• AdGuard Home als DNS-Filter

Dazu kommt die Custom App, die wir in einem eigenen Artikel zum TrueNAS App Catalog mit eigenen Images ausführlich beschrieben haben. Für diesen Beitrag geht es aber genau nicht um Spezialfälle, sondern um die Standard-Apps aus dem Katalog — und die Frage, wann sie das zweite System in einem KMU ersetzen können.

TrueNAS Apps für KMU: wann die eingebauten Apps wirklich tragen

Unsere Erfahrung aus kleinen und mittleren Umgebungen ist klar: Je stärker eine App an die Daten gebunden ist, die sowieso auf dem NAS liegen, desto besser passt sie direkt auf TrueNAS. Je stärker eine App an einen laufenden Dienst oder eine eigene Benutzerschicht gebunden ist, desto eher gehört sie auf einen separaten Host.

Nextcloud direkt auf TrueNAS

Nextcloud ist für uns das Paradebeispiel. Die Nutzdaten liegen auf einem ZFS-Dataset, Snapshots laufen über die Standard-Mechanik mit, Replikation auf ein zweites TrueNAS oder zu einem Hyperscaler-S3 funktioniert mit den etablierten Werkzeugen. Für Standard-KMU-Workloads bis einige dutzend Nutzer bietet die TrueNAS-App die saubere Trennung aus Nutzdaten-Dataset, Konfigurations-Dataset und Datenbank, und wir sparen uns den klassischen “Nextcloud-Linux-Server” nebenher.

Wo wir trotzdem skeptisch werden: Sobald wir mehr als etwa 50 aktive Nutzer, deutliche Office-Online-Workloads oder Hochverfügbarkeit erwarten, wandert Nextcloud zu uns typischerweise doch wieder auf eigene Proxmox-VMs mit externer Datenbank — einfach, weil die horizontale Skalierung und die Patching-Zyklen dort flexibler sind.

Vaultwarden auf dem NAS — ein echter Sweetspot

Vaultwarden ist für den Mittelstand aus unserer Sicht die beste Nachricht, die der Apps-Katalog gebracht hat. Für 10 bis 50 Mitarbeiter brauchen wir keinen eigenen VPS, keine komplexe Reverse-Proxy-Kette und keine getrennte Datenbank. Ein Dataset für den persistenten State, eine App-Instanz, ein TrueNAS-Snapshot-Schedule — fertig. Zusammen mit einem sauberen Backup-Setup Proxmox und TrueNAS haben wir damit eine Passwort-Infrastruktur, die wir mit gutem Gewissen empfehlen.

Grafana und kleines Monitoring

Für kleine Monitoring-Szenarien — Temperatur in Serverräumen, Backup-Erfolg, ein paar Switch-Metriken, SMART-Werte — reicht die Grafana-App auf dem NAS vollkommen aus. Die Metriken, die wir ohnehin aus TrueNAS exportieren, landen über ein paar Standard-Exporter in einer kleinen Prometheus-Instanz direkt daneben.

Nicht geeignet ist das Setup, sobald echtes Infrastruktur-Monitoring für mehrere Standorte, SLA-Reporting oder Audit-Anforderungen dazukommen. Dann baut DATAZONE lieber einen eigenen Monitoring-Stack auf einem dedizierten Host — getrennt vom Fileserver, damit ein NAS-Ausfall uns nicht gleichzeitig die Monitoring-Sicht nimmt.

Jellyfin und Immich — für Vereine, Praxen und Spezialfälle

Für klassische Industrie-KMU sind Jellyfin und Immich keine Core-Anwendungen. Für Zahnarztpraxen mit Patienten-Fotodokumentation, Fotostudios oder Vereinsarchive sind sie es durchaus. In diesen Fällen passt die direkte NAS-Integration gut, weil die Mediendaten nicht noch einmal über das Netz zu einem separaten Host wandern müssen.

Authentik und AdGuard Home — im Zweifel lieber separat

Hier werden wir vorsichtig. Authentik als Identity-Provider und AdGuard Home als DNS-Resolver sind Dienste, von denen andere Dinge abhängen. Fällt der Dateiserver aus und nimmt den Identity-Provider mit, melden sich Nutzer plötzlich an gar nichts mehr an. Fällt der DNS-Resolver aus, geht halbes Netz dunkel.

Deshalb unsere klare Empfehlung: Dienste, von denen andere Infrastruktur abhängt, gehören auf getrennte Hosts — oder in redundanter Form auf zwei Systeme, aber nicht ausschließlich auf das NAS, dessen primärer Zweck Dateiablage ist.

Wann wir trotzdem einen separaten Server empfehlen

Es gibt klare Signale, bei denen wir im Gespräch mit Kunden den Finger heben:

• Hochverfügbarkeit und Failover. TrueNAS HA ist eine Storage-HA, keine Service-HA für Apps. Wer eine Nextcloud-Instanz zweifach aktiv-aktiv braucht, bekommt das sauber nur mit zwei Proxmox-Hosts und ordentlichem Load-Balancing.
• Service-SLAs mit Patching-Fenstern außerhalb der Storage-Zeiten. Wir wollen den Fileserver am Wochenende patchen, die Apps aber unter der Woche nachts. Das sind zwei Rhythmen, die auf einem Host nur leidlich zusammenpassen.
• Starke Rechenlast in Apps. Transcoding, Big-Data-Jobs, OCR-Pipelines ziehen CPU-Last, die wir vom Fileserver fernhalten wollen.
• Audit- und Compliance-Trennung. Für manche Branchen — Anwaltskanzleien, Steuerberater, Gesundheitswesen — ist eine saubere Trennung zwischen “Dateiablage” und “Anwendungsschicht” nicht nur technisch, sondern auch regulatorisch sinnvoll.

In diesen Fällen setzen wir auf einen Proxmox-Host neben dem NAS. Die Hardware dafür lässt sich bei DATAZONE wie gewohnt im TrueNAS-Konfigurator planen, auch wenn der Host am Ende Proxmox betreibt und das NAS “nur” als Backend-Storage über iSCSI oder NFS bedient. Wer unsicher ist, bekommt im TrueNAS-Support die Hardware-Dimensionierung und das Lizenz-Setup mit angeschaut, bevor der erste Rack-Platz vergeben ist.

Snapshots, Backup und Updates mit Apps auf TrueNAS

Der eigentliche Grund, warum Apps auf dem NAS so attraktiv geworden sind, liegt im ZFS-Backend. Wenn wir die Apps-Konfiguration und die App-Daten auf eigene Datasets legen, bekommen wir Snapshots, Replikation und Verschlüsselung quasi geschenkt.

Unser bewährtes Schema:

• tank/apps — Docker-Root und Image-Layer, LZ4-Compression, keine aggressiven Snapshots
• tank/appdata/<app>/config — Konfiguration, 16K Recordsize, stündliche Snapshots, 7 Tage Aufbewahrung
• tank/appdata/<app>/data — Nutzdaten und Datenbanken, 64K Recordsize, tägliche Snapshots, 30 Tage Aufbewahrung

Was wir nicht tun: die TrueNAS-eigenen Apps-Snapshots als einziges Backup verwenden. Snapshots schützen vor Fehlbedienung und einzelnen Software-Bugs. Sie schützen nicht vor einer verschlüsselten Replikation oder vor dem Verlust des gesamten Pools. Deshalb läuft parallel immer eine Replikation auf ein zweites Ziel — entweder ein zweites TrueNAS im anderen Brandabschnitt oder, wie in unserem Beitrag zur TrueNAS-Replikation zu Hyperscaler-S3 beschrieben, in einen Object-Storage mit Immutability.

Beim Update-Rhythmus bleibt es dabei: Apps-Updates haben ihre eigene Kadenz, TrueNAS-Updates eine andere. Vor einem Major-Release von TrueNAS — und das steht uns mit TrueNAS 27 GA Anfang Dezember 2026 bevor — schauen wir in jedem Projekt noch einmal in die Release-Notes der verwendeten Apps und machen immer einen vollständigen Pool-Snapshot vor dem Upgrade. Für produktive Umgebungen bleibt die klare Empfehlung: nicht am ersten Tag auf das neue Major gehen, sondern den eingespielten 25.10-Goldeye-Pfad weiterfahren, bis TrueNAS 27 ein bis zwei Patch-Releases hinter sich hat.

Wenn das NAS zu klein ist: Hardware ehrlich dimensionieren

Container ziehen RAM. Nicht so viel wie eine volle VM, aber mehr, als wir in einem reinen Fileserver eingeplant hätten. Unsere Faustregel für KMU-Setups mit Apps:

• Für reine Fileserver-Nutzung reicht der klassische TrueNAS-RAM-Richtwert
• Für drei bis fünf Standard-Apps rechnen wir 16 bis 32 GB zusätzlich dazu
• Für Nextcloud mit Office-Online-Integration sind 32 GB zusätzlich der Boden, nicht die Decke
• CPU-Reserven: zwei bis vier zusätzliche Threads je nach App-Mix

Für die Hardware-Basis bedeutet das in der Regel: Ein TrueNAS M30 oder M40 aus dem aktuellen iXsystems-Portfolio ist die ehrliche Startlinie, sobald der Katalog aktiv genutzt werden soll. Die EOL-Modelle M50 und M60 empfehlen wir für Neukunden nicht mehr. Mini-Systeme wie das Mini R eignen sich für sehr kleine Umgebungen und für ausgelagerte Nebenstellen — in unserem Beitrag zum TrueNAS Mini R für Homeoffice und Remote-Standorte haben wir das genauer beschrieben.

Preise für die genannten Systeme bekommen Sie bei uns auf Anfrage, weil sich die Hardware- und Lizenzkonditionen aktuell schnell bewegen. Verbindliche Zahlen gibt es nur in einem konkreten Projekt mit Konfiguration und Support-Level.

FAQ: TrueNAS Apps-Katalog produktiv

Ist der Apps-Katalog in TrueNAS 25.10 Goldeye produktiv einsetzbar?

Ja. Für Standard-Workloads wie Nextcloud, Vaultwarden, Grafana oder Paperless-ngx betrachten wir den Katalog als produktiv. Entscheidend ist die saubere Trennung von Konfiguration und Daten auf eigenen Datasets und eine Backup-Strategie, die über Snapshots hinausgeht.

Löst der Apps-Katalog einen separaten Proxmox-Host immer ab?

Nein. Für hochverfügbare Dienste, Workloads mit hoher CPU-Last und Dienste, von denen andere Infrastruktur abhängt — Identity, DNS, zentrales Monitoring — empfehlen wir weiterhin einen separaten Host. Der Apps-Katalog ersetzt in der Praxis sehr gut das “zweite kleine Linux-System” nebenher, aber nicht die dedizierte Virtualisierungsplattform.

Was passiert mit meinen Apps beim Upgrade auf TrueNAS 27?

TrueNAS 27 kommt Anfang Dezember 2026 als GA. iXsystems hat angekündigt, die bestehenden Apps-Formate aus 25.10 nahtlos zu übernehmen. Trotzdem gilt bei uns: Pool-Snapshot vor dem Upgrade, Patch-Release abwarten, Rollback-Pfad schriftlich festhalten. Für produktive KMU-Umgebungen empfehlen wir, 25.10 Goldeye bis zum ersten oder zweiten 27.x-Patch weiterzufahren.

Wie sichere ich die Apps-Daten richtig?

Konfigurations- und Datendatasets gehören in eine replizierte Snapshot-Strategie. Zusätzlich eine Replikation auf ein zweites, physisch getrenntes System oder in einen immutablen Object-Storage. Rein lokale Snapshots sind kein Backup, sondern eine Komfortfunktion gegen Fehlbedienung.

Kann ich eigene Container im Katalog starten?

Ja, über die Custom-App-Funktion lassen sich eigene Docker-Images aus privater Registry oder vom Docker Hub einbinden. Die Details dazu haben wir im Artikel zum TrueNAS App Catalog mit eigenen Images beschrieben.

Wie steige ich am besten ein, wenn mein NAS heute nur Dateien ablegt?

Mit einer kleinen App zum Lernen — Vaultwarden ist dafür ideal — und einem klaren Dataset-Layout von Anfang an. Danach kommen die anwendungsnäheren Apps. Wer unsicher ist, kann sich bei uns im IT-Service oder im TrueNAS-Support die Zielarchitektur einmal in einem kurzen Workshop anschauen lassen, bevor der erste Produktiv-Workload umzieht.