Die letzten drei Tage waren intensiv – technisch, strukturell und gedanklich.
Mit diesem ersten Beitrag möchte ich festhalten, was wir konkret umgesetzt haben und warum die Winkelmann.Cloud genau so entsteht, wie sie entsteht.

Ausgangspunkt

Ziel war und ist eine eigene, unabhängige Business-Cloud, die ich vollständig selbst betreibe.
Keine Blackbox, keine Konzernabhängigkeit, keine unnötige Komplexität – sondern klare Systeme, klare Zuständigkeiten und nachvollziehbare Technik.

Alles basiert auf Linux, Open Source und dem Grundsatz:

Was ich nicht verstehe, betreibe ich nicht.

1. Klare Infrastruktur-Struktur

Am Anfang stand nicht die Software, sondern die Struktur.
Bevor irgendein Dienst produktiv ging, habe ich die Infrastruktur sauber getrennt: Hauptsysteme, Testsysteme und Integrationsumgebungen sind klar voneinander abgegrenzt. Jede virtuelle Maschine hat einen festen Zweck und eine definierte Rolle.

IP-Adressen, Netze und Hostnamen folgen einer festen Logik. Das klingt banal, ist aber entscheidend, wenn Systeme wachsen oder Fehler auftreten. Ich möchte jederzeit wissen, wo ein Dienst läuft, warum er dort läuft und was passiert, wenn er ausfällt. Diese Klarheit spart später massiv Zeit – gerade im laufenden Betrieb.

2. Stabile Server-Basis

Auf dieser Struktur wurde eine stabile Server-Basis aufgebaut.
Alle Systeme laufen auf Debian-basierten Linux-Distributionen, bewusst ohne unnötige Zusatzsoftware. Die Grundhärtung wurde direkt zu Beginn umgesetzt: saubere Benutzerverwaltung, restriktive Zugriffsrechte, SSH kontrolliert eingerichtet.

Ein zentrales Thema war dabei DNS. Erst als die Namensauflösung intern wie extern zuverlässig funktioniert hat, ging es weiter. Auch Docker und Docker Compose wurden nicht „einfach installiert“, sondern als bewusst eingesetzte Laufzeitumgebung konfiguriert. Container sind Werkzeuge – keine Abkürzung, um Verantwortung auszulagern.

3. Reverse-Proxy & Zugriffskonzept

Ein entscheidender Schritt war das Zugriffskonzept.
Alle Dienste sind über einen zentralen Einstiegspunkt erreichbar. Intern werden sie sauber weitergeleitet, ohne unnötige Umleitungen oder komplizierte Regeln. Jeder Pfad, jede Weiterleitung ist dokumentiert und nachvollziehbar.

Wichtig war mir dabei: Debugbarkeit.
Wenn etwas nicht erreichbar ist, möchte ich genau wissen, an welcher Stelle es scheitert – DNS, Proxy, Container oder Anwendung. Deshalb gibt es keine „magischen“ Automatismen. Alles ist bewusst einfach gehalten, aber technisch sauber.

4. Business-Software produktiv gemacht

Erst auf dieser stabilen Basis wurden die eigentlichen Business-Anwendungen produktiv genommen. Dazu gehören unter anderem Dokumentenmanagement, CRM/ERP-Funktionen, eine Wissensdatenbank sowie eine Lösung für Asset- und Inventarverwaltung.

Alle Systeme sind selbst gehostet, logisch voneinander getrennt und dennoch integrierbar. Es geht nicht darum, möglichst viele Tools zu betreiben, sondern die richtigen – und diese so, dass sie im Alltag wirklich helfen. Die Cloud soll Arbeitsprozesse unterstützen, nicht verkomplizieren.

5. Fehler analysiert – nicht übergangen

Ein besonders wichtiger Teil der letzten Tage war der Umgang mit Problemen.
Ein gutes Beispiel dafür war NetBox. Statt Fehler zu ignorieren oder mit Workarounds zu überdecken, wurde das System konsequent analysiert: Environment-Variablen, Docker-Konfiguration, Secrets, Abhängigkeiten.

Am Ende stand eine klare Entscheidung: lieber ein System vollständig neu aufsetzen als einen instabilen Zustand akzeptieren. Das mag kurzfristig mehr Aufwand sein, zahlt sich aber langfristig aus.
Stabilität entsteht durch Verständnis – nicht durch Glück.

6. Tests, Backups und Betriebssicherheit als Pflicht – nicht als Zusatz

Nach dem Aufbau der Business-Cloud begann der Teil, der oft unterschätzt wird: intensive Tests und Absicherung des laufenden Betriebs.
Eine Cloud ist erst dann produktionsreif, wenn sie Fehler verzeiht, Daten schützt und wiederherstellbar ist.

Proxmox als technische Basis

Die gesamte Infrastruktur läuft auf Proxmox als virtualisiertem Hostsystem. Das ist bewusst so gewählt: klare Trennung von Hardware, VM und Anwendung, konsistente Snapshots, saubere Backups auf Host-Ebene.

Backups werden nicht als einzelne Aufgabe betrachtet, sondern als Strategie:

• VM-Snapshots vor Änderungen
• Regelmäßige, versionierte Sicherungen
• Trennung von Produktivdaten und Sicherungszielen
• Wiederherstellung aktiv getestet, nicht nur angenommen

Ein Backup, das nie getestet wurde, ist kein Backup.

Der Paperless-Fehler – und warum er wichtig war

Nach einer IP-Änderung war Paperless plötzlich nicht mehr vollständig funktionsfähig. Dokumente waren vorhanden, aber Verweise, interne Pfade und Zuordnungen passten nicht mehr. Auf den ersten Blick wirkte alles „fast richtig“ – und genau das ist gefährlich.

• Die Daten selbst waren intakt
• Metadaten und interne Referenzen zeigten auf alte Zustände
• Ein Weiterbetrieb hätte langfristig Inkonsistenzen erzeugt

Die Lösung war kein Workaround, sondern eine saubere Entscheidung: Ursache nachvollziehen, Auswirkungen bewerten, Systemzustand bereinigen und die Funktion bewusst neu herstellen.

Von der Analyse zur SOP

Aus diesem Vorfall entstand direkt eine neue SOP (Standard Operating Procedure):

• Prüfungen vor IP- oder Netzwerkänderungen
• Identifikation sensibler Dienste
• Klare Entscheidung: reparieren oder neu aufsetzen
• Pflichtprüfungen nach Wiederherstellung

Diese SOPs sorgen dafür, dass zukünftige Fehler nicht neu analysiert, sondern abgearbeitet werden können.

Lokale Automatisierung & Überwachung als Ergänzung

Parallel zur Business-Cloud wurde auch die lokale Infrastruktur bewusst mitgedacht – nicht als Spielerei, sondern als Teil der Betriebssicherheit.

• Lokale Hausautomatisierung mit Shelly-Geräten
• Zentrale Steuerung über Home Assistant, vollständig lokal
• Reolink PoE 360° Kameras zur Gebäude- und Geländeüberwachung

Alles läuft lokal, getrennt von der Business-Cloud, aber dokumentiert und kontrollierbar.

Netz-Infrastruktur: Segmentierung statt Mischbetrieb

Ein zentraler Baustein ist eine klar segmentierte Netz-Infrastruktur. Statt eines großen Netzes gibt es logisch getrennte Bereiche mit klaren Aufgaben.

Diese Trennung sorgt dafür, dass Fehler, Sicherheitsprobleme oder Ausfälle lokal begrenzt bleiben – und nicht das Gesamtsystem gefährden.

Server- & Rechenzentrumsnetz (192.168.10.0/24)

Das Server- und Rechenzentrumsnetz bildet das technische Fundament der gesamten Winkelmann.Cloud.
In diesem Netz befinden sich ausschließlich Systeme, die direkt für den Betrieb der Infrastruktur notwendig sind: Virtualisierungshosts, zentrale Serverdienste und Basis-VMs.

Dieses Netz ist nicht per WLAN erreichbar und bewusst stark eingeschränkt. Es gibt keine Endgeräte, keine IoT-Komponenten und keine Consumer-Hardware. Ziel ist maximale Ruhe im Netz: möglichst wenig Kommunikation, möglichst wenig Angriffsfläche und eine klare Trennung zur restlichen Umgebung.

Administrativer Zugriff erfolgt ausschließlich kontrolliert aus dem Firmennetz. Das Servernetz selbst ist kein Arbeitsnetz, sondern ein reiner Betriebsbereich.

Firmennetzwerk & Backup (192.168.20.0/24)

Das Firmennetzwerk ist das eigentliche Arbeits- und Verwaltungsnetz.
Hier befinden sich die Systeme, mit denen täglich gearbeitet wird: Clients, Verwaltungsrechner und die zentralen Zugänge zur Cloud-Infrastruktur.

Gleichzeitig ist dieses Netz der Ausgangspunkt für Backups. Von hier aus werden Sicherungen angestoßen, geprüft und überwacht. Backups sind damit organisatorisch nah am Betrieb angesiedelt, aber technisch klar von den Servern getrennt.

Wichtig ist die Balance:
Dieses Netz ist produktiv nutzbar, aber nicht unkontrolliert offen. Administrative Zugriffe sind erlaubt, private oder fremde Geräte jedoch nicht. So bleibt der Betrieb übersichtlich und reproduzierbar.

Test- & Integrationsnetz (192.168.30.0/24)

Das Test- und Integrationsnetz ist bewusst als Fehlerraum gedacht.
Hier werden neue Systeme aufgebaut, Updates getestet und Konfigurationen ausprobiert, bevor sie produktiv eingesetzt werden.

Fehler in diesem Netz sind kein Problem – im Gegenteil: sie sind gewünscht.
Denn nur was hier stabil läuft, darf später in die produktive Cloud übernommen werden. Dadurch wird verhindert, dass unfertige oder schlecht verstandene Änderungen direkt im laufenden Betrieb landen.

Dieses Netz ist klar vom Server- und Firmennetz getrennt. Es gibt definierte Übergänge, aber keine automatische Durchlässigkeit.
Stabilität entsteht nicht durch Geschwindigkeit, sondern durch Kontrolle.

Kamera- & Überwachungsnetz (192.168.40.0/24)

Für Kameras und Überwachungssysteme existiert ein eigenes Netzsegment.
Alle Kameras – insbesondere PoE- und 360°-Modelle – kommunizieren ausschließlich innerhalb dieses Netzes oder mit klar definierten Gegenstellen.

Der entscheidende Punkt:
Kameras haben keinen direkten Zugriff auf das Firmennetz oder die Server. Selbst wenn ein Gerät kompromittiert wäre, bliebe der Schaden lokal begrenzt.

Zugriffe auf die Kameras erfolgen gezielt, etwa zur Ansicht oder Auswertung. Dauerhafte Verbindungen oder unnötige Internetzugriffe werden vermieden.
Überwachung soll Sicherheit erhöhen – nicht neue Risiken schaffen.

IoT-Aktoren – Shelly & Steuergeräte (192.168.50.0/24)

Dieses Netz ist für steuernde IoT-Geräte reserviert, insbesondere für Aktoren wie Shelly-Relais, Schalter oder Sensorik.
Diese Geräte erfüllen eine konkrete Aufgabe: schalten, messen, reagieren.

Sie sind funktional wichtig, aber technisch nicht vertrauenswürdig genug, um in sensiblen Netzen zu laufen.
Deshalb dürfen sie ausschließlich mit der lokalen Automatisierung kommunizieren – nicht mit Servern, Backups oder Clients.

Die Steuerlogik liegt zentral, die Geräte selbst bleiben so „dumm“ wie möglich.
Das reduziert Abhängigkeiten und vereinfacht die Fehlersuche erheblich.

IoT-Consumer-Geräte (192.168.60.0/24)

Consumer-IoT-Geräte wie Staubsauger, Rasenmäher oder ähnliche Haushaltsgeräte werden konsequent in ein eigenes Netz ausgelagert.
Diese Geräte gelten grundsätzlich als nicht vertrauenswürdig, unabhängig vom Hersteller.

Sie erhalten nur den minimal notwendigen Netzwerkzugang – oft lediglich Internetzugriff oder Zugriff auf einen einzelnen Dienst.
Ein Kontakt zu internen Systemen ist nicht vorgesehen.

Diese Trennung ist keine Schikane, sondern eine Schutzmaßnahme.
Wenn ein solches Gerät Probleme verursacht, bleibt der Effekt lokal – und nicht systemweit.