Docker, CI/CD und über 10 selbstgehostete Dienste auf dem ZimaCube 2 betreiben

Eva Wong ist die Technische Redakteurin und residente Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

💡
Community Spotlight: Michael Luckenbill, ZimaCube 2 Pioneer Program

Als ich den ZimaCube 2 zum ersten Mal ausgepackt habe, hatte ich eine Frage, die wichtiger war als jeder Datenblattvergleich: Kann dieses Gerät wirklich einen echten Infrastruktur-Stack betreiben?

Nach Wochen des Dauerbetriebs lautet die Antwort eindeutig ja. Hier ist genau, was ich laufen habe, wie es performt und warum die Standard-8GB-Konfiguration weiter kam, als ich je erwartet hätte.

Der Stack: Alles läuft auf einer Box

Der ZimaCube 2 ist jetzt das Zentrum meiner selbstgehosteten Infrastruktur. Hier ist das Gesamtbild:

Kernservices (Docker Compose)

  • Nginx Proxy Manager – Reverse Proxy und SSL-Termination
  • Cloudflare Tunnel – verschlüsselter Zugriff ohne geöffnete Ports
  • Ghost CMS – selbstgehosteter Blog (der, den du gerade liest)
  • Vaultwarden – Passwortverwaltung
  • Uptime Kuma – Infrastruktur-Monitoring
  • 5+ zusätzliche Container für Automatisierung und Tools

CI/CD-Pipeline

  • GitHub Actions Self-Hosted Runner – bauen und deployen Docker-Container direkt in meine lokale Umgebung
  • Automatisierte Deployment-Workflows, die bei jedem Push ausgelöst werden

Speicher & Daten

  • ZFS-Pools, die 3× HDDs und 3× NVMe-Laufwerke umfassen
  • Lokale Backup-Workflows mit dedizierten Backup-Laufwerken
  • Medien- und Datenspeicherung mit Snapshot-Unterstützung

Netzwerk

  • Duales 2,5Gb Ethernet kombiniert mit WiFi 7 Router
  • Reverse Proxy Routing zu allen Diensten
  • Verschlüsselte Tunnel für den Fernzugriff
All das – jeder einzelne Dienst – läuft auf einem ZimaCube 2.

8GB RAM: Der überraschende Leistungsträger

Hier kommt der ehrliche Teil: Als ich sah, dass die Standardkonfiguration mit 8GB DDR5 geliefert wird, war mein erster Impuls, sofort ein RAM-Upgrade zu bestellen. Stattdessen entschied ich mich, zu testen, wie weit die Standardkonfiguration realistisch reicht, bevor ich mehr Geld ausgebe.

Das Ergebnis hat mich überrascht.

Selbst mit über 10 Docker-Containern – darunter ein Reverse Proxy, verschlüsselte Tunnel, Monitoring, CI/CD Runner, CMS-Hosting und Speicherdienste – fühlte sich das System nie überfordert an. Der Speicherverbrauch blieb überschaubar. Die Startzeiten der Container waren schnell. Die Reaktionsfähigkeit der Dienste blieb ausgezeichnet.

Das sagt viel über die Effizienz moderner Linux-Container-Workloads und die Plattformarchitektur aus. Die NVMe-Speicherpools bedeuten, dass Swap bei Bedarf wirklich nutzbar ist, und die DDR5-Speicherbandbreite hält die Container-I/O reaktionsschnell.

Ich plane immer noch, später den Arbeitsspeicher zu erweitern – besonders wenn ich mehr KI-Workloads hinzufüge – aber die Standarderfahrung war weitaus leistungsfähiger als erwartet.

ZimaCube 2 vollständiges Self-Hosting-Infrastruktur-Stack-Diagramm: Hardware-Spezifikationen, Docker-Apps, ZFS-Speicherpools, CI/CD- und Remote-Zugriffs-Workflow-Übersicht

Docker CI/CD: BUILD → DEPLOY → AUTOMATE → REPEAT

Einer der wichtigsten Anwendungsfälle für mich ist Docker-basierte CI/CD. So funktioniert der Workflow auf dem ZimaCube 2:

  1. Ich pushe Code zu GitHub
  2. Ein selbstgehosteter GitHub Actions Runner auf dem ZimaCube 2 übernimmt den Job
  3. Der Runner baut das Docker-Image lokal
  4. Der neue Container wird in meiner selbstgehosteten Umgebung bereitgestellt
  5. Nginx Proxy Manager leitet den Traffic an den aktualisierten Dienst weiter
  6. Cloudflare Tunnel sorgt dafür, dass es von überall zugänglich ist
⟳  All dies läuft auf einer einzigen Maschine. Speicher, Netzwerk, Docker, Reverse Proxy und Automatisierung laufen alle auf einem zentralisierten System.

Genau für diesen Workflow wollte ich diese Maschine. Kein Jonglieren mehr zwischen einem NAS für Speicher, einer separaten Box für Rechenleistung und einem weiteren System für CI/CD.

Speicherarchitektur, die Sinn macht

Das Dual-Pool-Design macht diese Konsolidierung möglich:

Pool Laufwerke RAID Zweck
Bulk (HDD) 3 × 6TB RAID 1 + Hot Spare Medien, Datensätze, Backups
Schnell (NVMe) 2 × 512GB RAID 1 Docker, VMs, App-Speicher
Schnelles Backup 1 × 2TB NVMe Lokales Backup-Ziel

Der schnelle Pool ist der Ort, an dem Docker lebt. Container-Images, Volumes und Laufzeitdaten liegen alle auf NVMe RAID 1, was bedeutet, dass Container-Start und I/O-Operationen wirklich schnell sind. Der Bulk-Pool übernimmt die Langzeitspeicherung – Mediendateien, Archive und Datensätze, die keine NVMe-Geschwindigkeit benötigen.

Diese Trennung bedeutet, dass ich nie zwischen Kapazität und Leistung wählen muss.

Thermische Leistung unter Dauerlast

Einer der beeindruckendsten Aspekte des ZimaCube 2 ist die thermische Leistung. Selbst beim Ausführen von Docker-Containern, Speicherpools, Reverse-Proxys, Überwachungsdiensten, CI/CD-Infrastruktur und selbstgehosteten Anwendungen bleibt das System sowohl leise als auch kühl.

Das Metallgehäuse, das Luftstromdesign, die mitgelieferten NVMe-Kühlkörper und das interne Komponentenlayout tragen alle dazu bei. Für ein kompaktes, ständig eingeschaltetes Infrastrukturgerät ist die thermische Auslegung wirklich ausgezeichnet.

Im Vergleich zu den älteren Rack-Servern, die ich zuvor verwendet habe, ist der Unterschied bei Wärmeentwicklung, Stromverbrauch, Geräuschpegel und Platzbedarf enorm.

Netzwerk: Dual 2,5GbE in der Praxis

Die dualen 2,5Gb-Ethernet-Ports passen perfekt zur modernen Netzwerkinfrastruktur. In Kombination mit einem WiFi-7-Router und einem 2,5GbE-Switch:

  • Schnelle Dateiübertragungen zu und von den Speicherpools
  • Reaktionsschnelles Container-Netzwerk zwischen Diensten
  • Reibungsloser Fernzugriff über Cloudflare Tunnel
  • Keine Engpässe bei gleichzeitigen Workloads

Für ein kompaktes Infrastrukturgerät ist duales 2,5GbE enorm wichtig — es bedeutet, dass Ihr Speicherzugriff nicht durch eine einzelne Gigabit-Verbindung begrenzt wird.

Bauen Sie Ihre eigene selbstgehostete Plattform mit dem ZimaCube 2 →

Häufig gestellte Fragen

F1. Wie viele Docker-Container kann der ZimaCube 2 ausführen?

Mit der Standardkonfiguration von 8 GB DDR5 betreibt Michael über 10 Container, darunter Reverse Proxy, CMS, Passwortmanager, Monitoring, CI/CD Runner und Speicher-Dienste — mit ausreichend Reserven. Der NVMe-Speicherpool sorgt für schnelle Container-I/O auch bei gleichzeitiger Last.

F2. Kann der ZimaCube 2 GitHub Actions Runner ausführen?

Ja. Selbstgehostete GitHub Actions Runner funktionieren gut auf dem ZimaCube 2. Michael nutzt sie, um Docker-Container direkt in seine lokale selbstgehostete Umgebung zu bauen und bereitzustellen — eine vollständig lokale CI/CD-Pipeline.

F3. Reichen 8 GB RAM für ein Docker-Homelab aus?

Für Container-Workloads — Docker, Reverse Proxies, Tunnel, Monitoring und Speicher-Dienste — reichen 8 GB überraschend weit. Moderne Linux-Container sind speichereffizient, und der NVMe-Speicher bietet bei Bedarf schnellen Swap. Sie können später jederzeit über den SODIMM-Slot aufrüsten.

F4. Was ist der Vorteil von zwei Speicherpools (HDD + NVMe)?

Der NVMe-Pool bewältigt I/O-intensive Workloads wie Docker, VMs und Anwendungsdaten mit niedriger Latenz. Der HDD-Pool bietet kostengünstigen Massenspeicher für Medien, Backups und Datensätze. Diese Trennung bedeutet, dass Sie nie Kapazität gegen Leistung eintauschen müssen.

F5. Unterstützt der ZimaCube 2 Cloudflare Tunnel?

Ja, und es funktioniert gut. In Kombination mit Nginx Proxy Manager und dualem 2,5GbE-Netzwerk können Sie Ihre selbstgehosteten Dienste sicher zugänglich machen, ohne Ports an Ihrem Router öffnen zu müssen.

Zima Kampagnen-Zentrale

Mehr zum Lesen

Was passiert, wenn zwei KI-Agenten um einen Server kämpfen?
Jun 16, 2026Community & Stories

Was passiert, wenn zwei KI-Agenten um einen Server kämpfen?

Zero Noichis KI-Cybersicherheits-Experiment nutzte zwei ZimaBoard 2-Geräte, um Angreifer- und Verteidigeragenten zu simulieren, und zeigte, wie Homelab-Server sichere KI, Docker, NAS und Sicherheitstests unterstützen...

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.