Private Cloud: Hardware, Kosten und ehrliche Kompromisse

Im zweiten Teil ging es um die Komponenten der privaten Cloud und die Logik hinter der Auswahl. Heute wird es konkret: Welche Hardware trägt das Ganze, was kostet das wirklich — und wo liegen die ehrlichen Grenzen dieses Ansatzes?

Die Hardware: Weniger ist mehr #

Die gesamte Infrastruktur läuft auf einem einzigen physischen Rechner. Verbaut ist ein Intel Core i3-10110U mit 64 GB RAM. Kein Server-Rack, kein Datacenter-Ausschuss, kein surrendes Ungetüm im Keller — sondern ein kompaktes, stromsparendes System, das für den Dauerbetrieb ausgelegt ist.

Den Rechner habe ich noch vor der großen Speicherkrise gekauft. 64 GB RAM in einem kompakten System zu diesem Preis wäre heute deutlich teurer — das war schlicht gutes Timing. Der Kaufpreis lag bei ungefähr 400–500 Euro.

Der i3-10110U ist ein Mobile-Prozessor mit niedrigem TDP. Das zahlt sich im Dauerbetrieb direkt aus: Im realen Betrieb als Proxmox-Host mit laufendem Kubernetes-Cluster bewegt sich der Verbrauch bei geschätzten 15–25 Watt im Idle — je nach Last. Das entspricht ungefähr 6–8 Euro Stromkosten pro Monat.

Was das wirklich kostet #

Zwei Dinge haben dieses Setup erst wirtschaftlich gemacht: Glasfaser und günstige S3-Preise.

Ohne Glasfaser wäre ein selbst gehosteter Dienst mit externem Zugriff ein Kompromiss — langsame Uploads, träge Synchronisation, schlechte Nutzererfahrung. Mit Glasfaser merkt man im Alltag keinen Unterschied zu einem gehosteten Dienst. Das war ein entscheidender Enabler.

Der zweite Faktor: S3-Object-Storage ist in den letzten Jahren so günstig geworden, dass sich eigener NAS-Speicher vor Ort kaum noch lohnt. Ich wollte bewusst kein lokales NFS-Volume für Nextcloud-Daten und Backups betreiben — zu viel Wartung, zu viel lokale Abhängigkeit. Stattdessen lagere ich beides aus: Nextcloud-Daten liegen auf dem Cluster-Storage, Backups fließen automatisch zu Contabo S3 in München. Das ist einfacher, günstiger und sicherer als ein weiteres lokales Gerät.

Zum Vergleich: Eine gemanagte Nextcloud-Instanz bei Hetzner Storage Share mit 5 TB kostet bereits knapp 17 Euro pro Monat — ohne Passwortmanager, ohne Dokumentenverwaltung, ohne Fotoverwaltung, ohne Identity Management. Wer alles einzeln mieten wollte, käme schnell auf das Dreifache meiner Gesamtkosten. Und die Daten lägen trotzdem bei einem Dritten.

Bei einem Anschaffungspreis von rund 450 Euro und laufenden Kosten von ~10,50 Euro pro Monat hat sich die Hardware nach etwa zwei Jahren gegenüber einer vergleichbaren Managed-Lösung amortisiert. Ab dann ist der monatliche Vorteil rein rechnerisch deutlich spürbar.

Die ehrlichen Nachteile #

An dieser Stelle wäre es unseriös, nur das Positive zu betonen. Dieser Ansatz hat reale Einschränkungen — und die gehören offen benannt.

Single Point of Failure. Ein physischer Host bedeutet: Fällt die Maschine aus, fällt alles aus. Kein automatisches Hardware-Failover. Für ein privates Setup ist das ein bewusst akzeptiertes Risiko — abgefedert durch ein solides Backup-Konzept und die Tatsache, dass keine produktionskritischen Geschäftsdaten darauf laufen.

Heimanbindung. Der Host hängt an einem Heimanschluss. Keine garantierte Verfügbarkeit, keine SLA. Glasfaser macht das deutlich besser als DSL — aber es bleibt ein Heimanschluss.

Wartungsaufwand. Updates, Monitoring, gelegentliche Eingriffe — das läuft weitgehend automatisiert, aber jemand muss den Überblick behalten.

Diese Einschränkungen sind real. Und sie sind auch der Grund, warum dieser Ansatz nicht für jeden und nicht für jede Situation der richtige Weg ist.

Wachsen ohne neu zu bauen #

Die ehrlichste Frage zu diesem Setup lautet nicht “was kann es?”, sondern “was passiert, wenn es nicht mehr reicht?”. Und genau hier zeigt sich, warum der Unterbau so wichtig ist — nicht die Hardware, sondern die Art, wie sie bereitgestellt wird.

Wenn der bestehende Proxmox-Host an seine Grenzen stößt — mehr RAM-Bedarf durch neue Applikationen, mehr CPU-Last durch mehr Nutzer, oder schlicht der Wunsch nach echter Ausfallsicherheit — dann kommt ein zweiter Proxmox-Host dazu. Was auf den ersten Blick nach einem großen Schritt klingt, ist in der Praxis erstaunlich unspektakulär.

Der Weg vom ersten zum zweiten Host #

Auf dem neuen Host wird Proxmox installiert, die VMs für zusätzliche Worker-Nodes provisioniert — und ab da übernimmt die Automatisierung. Ansible bringt die Nodes auf den exakt gleichen Stand wie die bestehenden: gleiche Kernel-Parameter, gleiche Container-Runtime, gleiche Kubernetes-Version, gleiche Konfiguration bis ins Detail. Kein manuelles Nachjustieren, kein “auf welchem Host lief nochmal welche Version?”.

Sobald die neuen Nodes dem Cluster beigetreten sind, übernimmt Flux. Die Applikationen im Cluster merken den Zuwachs von selbst — der Kubernetes-Scheduler verteilt Pods auf die neuen Worker, Longhorn repliziert Volumes auch dorthin, und alles, was in Git steht, gilt automatisch auch für die neue Hardware.

Von der Mini-PC bis zum Rack-Server #

Dieses Prinzip endet nicht beim zweiten kleinen Rechner. Es gilt genauso, wenn die Hardware ausgetauscht oder grundlegend professioneller wird. Der hier beschriebene Setup läuft auf einem kompakten Mini-PC — aber nichts an der Software-Architektur ist daran gebunden.

Wer in zwei Jahren feststellt, dass ein 19-Zoll-Server mit 1 oder 2 Höheneinheiten besser passt — ein Dell PowerEdge, ein HPE ProLiant, ein Lenovo ThinkSystem mit redundanten Netzteilen, ECC-RAM und Hardware-RAID — der ersetzt schlicht die Hardware. Proxmox installieren, Ansible laufen lassen, Nodes beitreten. Die Applikationen, die Daten, die Konfiguration: alles bleibt unverändert, weil alles in Git liegt. Der Cluster merkt nicht, ob unter ihm ein Mini-PC oder ein Rack-Server steht.

Das ist der eigentliche Wert dieser Architektur. Sie ist nicht auf “Hobby-Hardware” beschränkt — sie ist hardware-agnostisch. Dieselben Helm-Charts, dieselben Flux-Konfigurationen, derselbe Stack laufen auf einem 400-Euro-Mini-PC genauso wie auf einem Enterprise-Server für mehrere tausend Euro. Der Unterschied liegt in Leistung, Ausfallsicherheit und Verfügbarkeit — nicht in der Funktionsweise.

Für kleine Unternehmen bedeutet das: Man kann klein anfangen, mit überschaubarem Budget, und später wachsen, ohne die Architektur neu zu denken. Die Investition in Automatisierung und GitOps zahlt sich genau dann aus, wenn die Hardware sich ändert.

Warum GitOps den Unterschied macht #

Git ist die einzige Quelle der Wahrheit. Jede Konfigurationsänderung — sei es ein neues Helm-Chart, eine geänderte Ressourcen-Anforderung oder eine angepasste Netzwerk-Policy — wird in Git committed. Flux zieht sich diese Änderungen und wendet sie auf den Cluster an. Ein zweiter Host, ein neuer Rack-Server, ein komplett ausgetauschtes Setup — die gleichen Git-Repositories beschreiben jeden Zustand präzise.

Keine Config-Drift. Das ist das Problem, das bei manuell gepflegten Umgebungen nach Monaten unweigerlich auftaucht: Auf Host A wurde mal eben ein Paket nachinstalliert, auf Host B eine Datei von Hand editiert, und niemand weiß mehr warum. Mit Ansible und Flux passiert das nicht — weil jede Änderung den Weg über Git nimmt. Wer einen neuen Worker hinzufügt oder die komplette Hardware tauscht, bekommt garantiert den gleichen Zustand wie überall sonst. Nachvollziehbar, reproduzierbar, jederzeit.

Das ist kein theoretischer Vorteil. Das ist der Unterschied zwischen einer Infrastruktur, die man pflegt, und einer, die man betreibt.

Was das in der Praxis bedeutet #

Ein zweiter Proxmox-Host im Mini-PC-Format kostet — je nach gewählter Hardware — zwischen 400 und 800 Euro einmalig, dazu die laufenden Stromkosten. Die eigentliche Arbeit, den Cluster darauf zu erweitern, ist in wenigen Stunden erledigt: VMs provisionieren, Ansible laufen lassen, Nodes joinen, fertig. Keine Downtime, kein Re-Deployment der Applikationen, kein Datenumzug.

Wer gleich professionelle Rack-Hardware wählt, zahlt natürlich mehr — bekommt dafür aber redundante Komponenten, Out-of-Band-Management (iDRAC, iLO) und Enterprise-Support. Der Prozess zur Integration bleibt derselbe.

Und falls in zwei Jahren ein weiterer Host dazukommen soll: Derselbe Prozess, dieselben Playbooks, dieselbe Git-Historie. Das Setup skaliert nicht, weil die Hardware skaliert — sondern weil die Automatisierung es tut.

Für Unternehmen sieht die Rechnung anders aus #

Für ein kleines Unternehmen verschiebt sich das Bild gegenüber einem privaten Setup. Glasfaser ist oft vorhanden, S3-Kosten skalieren mit dem Datenvolumen, und die Hardware-Investition verteilt sich auf mehrere Nutzer. Die grundlegende Architektur bleibt dieselbe — aber die Anforderungen an Verfügbarkeit, Redundanz und Support sind andere. Genau an diesem Punkt macht eine professionelle Begleitung den Unterschied.

Im nächsten Teil: Der technische Deep-Dive. Helm-Charts, Flux-Konfiguration, konkrete Deployments — für alle, die es genau wissen wollen.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen — ich freue mich auf die Diskussion: