01
Plattform als SaaS
CloudManager provisioniert Server, liefert containerisierte Produkte an Ihre Kunden aus und sichert, überwacht und patcht den Bestand. Der Betrieb kommt von hier, der Inhalt von Ihnen.
Wie die Plattform arbeitet →levit-cloud
Cloud-Betrieb für Systemhäuser, Rechenzentren und IT-Dienstleister.
Sie haben die Kunden, die Hardware und das Vertrauen. Was fehlt, ist die Schicht dazwischen: Wer stellt den Server bereit, wenn ein Kunde bestellt? Wer zieht das Update nach? Wer sieht nach, ob die Sicherung von gestern Nacht wirklich durchgelaufen ist?
CloudManager fasst diese Handgriffe zu einem Vorgang zusammen, auf Ihrer Infrastruktur und unter Ihrem Namen. Dazu fertige Produkte für Ihren Katalog, Beratung und individuelle Lösungen.
Kein Konzept: Die Plattform betreibt seit dem 2. März 2026 den eigenen Bestand, jeden Tag und im Produktivbetrieb.
- Verwaltete Hosts
- 14
- Produkt-Deployments
- 400
- Auditierte Vorgänge
- 300.516
- Im Produktivbetrieb
- 214 Tage
Gemessen am 02.10.2026, ausgelesen aus der Betriebsdatenbank der eigenen Installation. „Auditierte Vorgänge“ sind Einträge im Prüfpfad, also jede verändernde Aktion mit Urheber seit dem 2. März 2026.
Angebot
Vier Wege, denselben Betrieb zu lösen
Sie können die Plattform mieten, fertige Produkte darauf ausliefern, sich beraten lassen oder etwas bauen lassen, das es so noch nicht gibt. Die vier greifen ineinander, lassen sich aber einzeln buchen.
02
Fertige Produkte
Mandantenfähige Anwendungen, die Sie in Ihren Katalog stellen und mit dem CloudManager verwalten. Bestellung, Provisionierung, Aktualisierung und Sicherung laufen über dieselbe Oberfläche wie der übrige Bestand.
Was bereitsteht →03
Beratung
Zu Infrastruktur, KI, Security und Netzwerktechnik, von jemandem, der die Empfehlungen im eigenen Betrieb selbst gefahren hat und sagen kann, was sie gekostet haben.
Beratungsfelder →04
Individuelle Lösungen
Wo der Standard nicht passt: eigene Anwendungen, Anbindungen an bestehende Systeme, Automatisierung von Abläufen, die heute von Hand laufen. Betrieben wird das auf derselben Plattform.
Wie das abläuft →01 · Plattform als SaaS
Ihre Cloud, ohne ein DevOps-Team dafür aufzubauen
Proxmox, Ansible, ein Panel und ein Ticketsystem lösen je einen Teil. Es fehlt die Klammer: Bestellung, Server, Netz, Zertifikat, Ausrollen, Sicherung und Überwachung als ein Vorgang statt als sieben Werkzeuge und eine Übergabeliste. Ein Panel wie Plesk verwaltet, was auf einem Server läuft. CloudManager legt den Server erst an und ersetzt ihn, wenn Sie den Anbieter wechseln. Deploys laufen mit Docker Compose, nicht in einem Cluster. Ein Plattformteam brauchen Sie dafür nicht. Die Schritte im Einzelnen:
Provisionieren
Server bei wechselnden Anbietern oder auf eigener Hardware anlegen, in ein eigenes verschlüsseltes Netz aufnehmen und mit einem Agenten versehen. Ist die Automatik eingeschaltet, braucht es vom Auftrag bis zum erreichbaren Host keinen Handgriff.
Ausliefern
Produkte als Container an Kunden ausrollen, jeder Mandant getrennt, mit eigener Domain, eigenem Zertifikat und eigenen Zugangsdaten. Rollout mit sichtbarem Fortschritt und Rückweg.
Sichern
Sicherungen laufen nach Plan auf zwei Ziele. Ob sie sich zurückspielen lassen, wird regelmäßig ausprobiert: Im Backup-Katalog stehen seit Mai 529 erfolgreiche automatische Restore-Tests, 6 schlugen fehl, 5 gelangen teilweise. Vor einem Rollout sichert die Plattform das betroffene Projekt, vor einem eigenen Update ihre Datenbank. Scheitert die Sicherung vor einem Rollout, läuft er trotzdem weiter.
Überwachen
Metriken, Alarme und ein täglicher Bericht, der zwischen „nichts passiert“ und „nichts gemeldet“ unterscheidet.
Patchen
Betriebssystem-Updates, Schwachstellen-Scans der ausgelieferten Abbilder und eine Risikobewertung, bevor die Plattform sich selbst aktualisiert. Schlägt danach der Rauchtest fehl, geht sie automatisch auf die alte Fassung zurück.
Nachweisen
Jede verändernde Aktion steht mit Urheber im Prüfpfad. Wer wann was ausgelöst hat, ergibt eine Abfrage. Niemand muss es aus Logdateien zusammensuchen.
Drei Merkmale, die über ein Panel hinausgehen
Adressverwaltung (IPAM)
Wird eine Proxmox-VM in einem verwalteten Netz angelegt, reserviert die Plattform die Adresse vor dem Klonen und prüft sie gegen den Hypervisor. Vergeben wird unter einer Sperre je Netz, zwei gleichzeitige Aufträge bekommen also nicht dieselbe. Stündlich gleicht die Plattform den Bestand mit Proxmox, DHCP, ARP-Tabelle und Netz-Scan ab. Ist eine Quelle nicht lesbar, bleibt ihr Bestand unangetastet.
Bare Metal ohne Bildschirm
Ein neuer Server startet über das Netz und installiert sich selbst. Die Installationsdaten sind signiert und werden auf dem Gerät geprüft. Er kommt fertig eingebunden an: mit Adresse, Mesh-Profil nach Rolle, CrowdSec und SSH-Zertifikaten.
Eine Schnittstelle für alles
Was die Oberfläche kann, kann die REST-API mit OpenAPI-Beschreibung. Zugriff über Token mit Scopes, für Kunden projektgebunden. Neue Anbieter kommen als Adapter hinzu, eingehende Webhooks werden per Signatur oder geheimem Token geprüft. Ausgehende, abonnierbare Webhooks gibt es nicht.
PocketCM: der Bericht am Morgen
Die iPhone-App PocketCM zeigt, was die Plattform gerade meldet: welche Hosts sich melden, welche Sicherungen gelaufen sind, welche Alarme offen stehen. Alarme kommen als Push-Mitteilung aufs Gerät, gleichartige Meldungen gebündelt; sie lassen sich direkt aus der Mitteilung quittieren oder vier Stunden stummschalten.
Seit September gibt es außerdem Freigaben per Face ID. Für einen festen Katalog an Aktionen bestätigt der Betreiber auf dem iPhone statt nur im Browser: Vorschläge der Plattform, Sicherungen, Container-Neustarts, Host-Patches und Neustarts, Plattform-Updates, Produkt-Rollouts, Umzüge von Anwendungen und SSH-Zertifikate als zweiter Faktor. Die Freigabe ist kryptografisch an das Gerät gebunden. Alles andere bleibt bewusst am Rechner.
Am wichtigsten ist der Tagesbericht. Er trennt „nichts passiert“ von „nichts gemeldet“. Was die App nicht abrufen kann, zeigt sie als unbekannt und nicht als grün. Ein Systemhaus, das Betriebsführung verkauft, kann seinem Kunden damit sagen: Sie bekommen jeden Morgen einen Bericht. Bleibt er aus, ist das selbst eine Meldung.
Zum Stand: Einen externen Push-Dienst gibt es nur noch als Notausgang, falls die Plattform ganz ausfällt. Eine Sicht je Kunde fehlt noch. Für ein Systemhaus mit mehreren Kunden ist das die nächste offene Entscheidung.
Patchen mit KI
Vor breiteren automatischen Updates schaut ein Sprachmodell auf den Host
Automatische Updates laufen nachts und ohne Aufsicht. Geht eines schief, merkt es bis zum Morgen niemand. Deshalb steht vor dem Update eine Bewertung, die den Zustand des Hosts einbezieht. Reine Sicherheitsupdates der Hosts prüfen feste Regeln, breitere Updates bewertet zusätzlich das Modell.
Was das Modell zu sehen bekommt
Den Changelog und dazu den freien Plattenplatz, die letzte Sicherung, die Alarme der letzten sieben Tage und ob ein Kernel-Update aussteht. Riskant ist ein Update immer auf einem bestimmten Host, heute Nacht.
Lokal, ohne Rückkanal
Das Modell läuft auf eigener Hardware. Für die Update-Bewertung gibt es keinen Cloud-Anbieter und kein Ausweichen auf einen fremden Dienst, wenn das lokale Modell nicht antwortet. Die Daten über den Zustand der Hosts verlassen das Haus nicht. Wer Datensouveränität verkauft, sollte es selbst auch so halten.
Im Zweifel angehalten
Antwortet das Modell nicht oder unverständlich, gilt das nicht als Zustimmung: Das Update unterbleibt und ein Alarm geht raus. Alles außer einem ausdrücklichen „weiter“ gilt als „halt“. In diese Richtung soll ein Fehler fallen.
Sicherheitspatches warten nicht auf die KI
Reine Sicherheitsupdates laufen über eine regelbasierte Prüfung ohne Sprachmodell. Eine Lücke soll nicht offen bleiben, weil ein Modell nachdenkt. Die KI-Bewertung gilt den breiteren Updates: Host-Pakete insgesamt, Container-Images, den Mailstack.
Beleg: 247 Update-Entscheidungen seit dem 14.07.2026
(Zählung: höchste laufende Nummer; Entscheidungen zu gelöschten
Hosts verschwinden, gespeichert sind heute 204). Das Sprachmodell
selbst hat 25 Fälle bewertet und 21 davon gestoppt. Es hält also eher
an, als dass es durchwinkt. Seit dem 03.09. sieht die Praxis anders
aus: 83 Entscheidungen, keine davon angehalten. 82 liefen über die
regelbasierte Prüfung, das Modell hat nur einen Fall bewertet
(weiter). Ausgelesen aus update_gate_decisions
am 02.10.2026.
White-Label
Unter Ihrem Namen, nicht unter meinem
„Unter Ihrem Namen ausliefern“ ist schnell gesagt. Betreiber stellen dazu immer dieselben Fragen. Hier sind die Antworten, auch die eine, die noch offen ist.
- Wessen Name steht auf der Oberfläche? Ihrer. Eigene Domain, eigenes Logo, eigene Farben; die Kunden-Oberfläche und die Betreiber-Oberfläche sind getrennte Ansichten desselben Systems.
- Wer sieht meine Endkunden? Sie. Mandanten, Projekte und Zugangsdaten liegen in Ihrer Installation. Es gibt keinen Rückkanal, über den Kundendaten zu mir fließen.
- Wessen Impressum, wessen Vertrag? Ihres. Sie sind der Anbieter gegenüber Ihrem Kunden; ich bin Ihr Lieferant.
- Sieht mein Kunde irgendwo „CloudManager“? In Portal, Fußzeile, Browser-Titel und Adresse: nein, dort steht Ihre Marke. Im Quelltext, in technischen Kopfzeilen und in den Namen der Container: ja. Wer sucht, findet es.
- Muss ich Sie im AVV als Unterauftragnehmer nennen? Solange die Installation auf Ihrer Infrastruktur läuft und ich keinen Zugriff auf Ihre Kundendaten habe: nein. Sobald Sie mich zur Fehlersuche an ein System lassen: ja. Dieser Zugriff steht dann in demselben Prüfpfad, den Sie Ihrem Kunden zeigen. Die Auftragsverarbeitungs-Vereinbarung dazu liegt als Entwurf vor, samt Unterauftragsverarbeitern und Maßnahmenkatalog. Sie ist noch nicht juristisch geprüft und deshalb nicht freigegeben.
- Ein Stack für alle oder einer je Partner? Einer je Partner. Jede Partner-Installation ist eine eigene, vollständige Instanz und kein Mandant in einem fremden System.
- Wie kommen Aktualisierungen zu mir? Über dieselbe Registry und denselben Weg, über den sich die Plattform hier selbst aktualisiert, mit Risikobewertung und Rückweg. Zwang ist das keiner.
Die DSGVO-Unterlage schreibt Ihr Kunde sich selbst
Viel Zeit kostet ein Systemhaus nicht das Ausrollen, sondern die Nachfrage danach: „Schicken Sie uns bitte den Auftragsverarbeitungsvertrag.“ Bei jedem Endkunden neu, jedes Mal von Hand, jedes Mal mit der Frage, welche Produkte er eigentlich gebucht hat.
Die Plattform erzeugt dieses Dokument selbst. Ihr Kunde öffnet in seinem Portal den Punkt AVV und erhält einen auf ihn ausgestellten Vertrag als PDF: mit seinem Namen, Ihren Stammdaten, den technisch-organisatorischen Maßnahmen und der Liste der Unterauftragsverarbeiter. Als Anlage 1 folgen genau die Produkte, die er gebucht hat, jeweils mit Zweck und Datenkategorien. Der Abschluss wird mit Fassung, Zeitpunkt und Prüfsumme protokolliert, sodass später belegbar ist, welche Fassung er angenommen hat.
Stand 02.10.2026: Der Generator läuft und erzeugt das Dokument aus den Betriebsdaten. Der Klauseltext ist ein Standard-Gerüst und noch nicht juristisch geprüft; bis dahin bleibt die Ansicht für Kunden geschlossen. Das ist keine Rechtsberatung. Vor der Freigabe gehört der Vertrag zu einem Anwalt.
Zum Stand: Die Technik ist gebaut und läuft im eigenen Bestand, ein Partner-Stack ist als Testinstallation registriert. Einen zahlenden Betreiber außerhalb des eigenen Bestands gibt es noch nicht. Sie wären der erste. Was das an Konditionen und Mitsprache wert ist, klären wir im Gespräch.
02 · Fertige Produkte
Fertige Produkte für Ihren Katalog
Neben der Plattform entstehen hier Anwendungen, die als fertiges Produkt in einen Katalog gestellt werden können. Sie werden mit demselben CloudManager ausgeliefert, aktualisiert und gesichert wie alles andere. Für Sie ist ein Produkt damit ein Eintrag im Katalog und kein Sonderfall.
IoT- und Sensorplattform
LoRaWAN-Sensoren, Gateways, Messwerte und Alarme im Self-Service verwalten. Im eigenen Bestand eine der am häufigsten ausgerollten Anwendungen.
Branchenanwendungen
Mandantenfähige Fachanwendungen mit eigenem Tarifmodell. Selbst gebaut, betrieben und weiterentwickelt, nicht eingekauft und weiterverkauft.
Medien und Audio
Anwendungen für Aufnahme, Verwaltung und geräteübergreifende Auslieferung von Audioinhalten.
Ihre eigenen Produkte
Der Katalog ist nicht auf die hier entstandenen Anwendungen beschränkt. Was sich als Container ausliefern lässt, lässt sich aufnehmen, mit Tarifen, Mandantentrennung und Aktualisierungsweg.
Im öffentlichen Katalog steht nur, was einzeln freigegeben ist, und das ist bewusst wenig. Welche für Ihren Anwendungsfall in Frage kommen, klären wir im Gespräch.
03 · Beratung
Beratung von jemandem, der es selbst betreibt
Beraten wird hier nur, was auch selbst betrieben wird. Jede Empfehlung lässt sich an einem laufenden System zeigen, auch an den Stellen, an denen sie beim ersten Anlauf nicht funktioniert hat.
Infrastruktur
Anbieterunabhängigkeit, Kapazitätsplanung, Wiederanlauf nach Ausfall, Sicherungsstrategie mit geprobter Wiederherstellung.
KI
Wo ein Sprachmodell trägt und wo es nur teuer rät: eigener Betrieb statt fremder Schnittstelle, Rückfallwege, Kostendeckel und die Frage, welche Daten das Haus verlassen dürfen.
Security
Rechte- und Rollenschnitt, Geheimnisverwaltung, Prüfpfad, Schwachstellenverwaltung, Härtung. Dazu Alarme, die auch dann noch melden, wenn das überwachte System steht.
Netzwerktechnik
Verschlüsselte Standortverbindungen, Zugriffsregeln zwischen Diensten, Firewall- und Router-Aufbau, Zugang für Außenstellen ohne offene Ports.
04 · Individuelle Lösungen
Wenn das Passende noch nicht existiert
Oft fehlt gar keine Software. Die vorhandene passt nur an einer Stelle nicht. Dafür entsteht hier Eigenes, und es bleibt betreibbar, weil es auf derselben Plattform läuft wie alles andere.
-
1
Aufnehmen
Was läuft heute, wo entsteht Handarbeit, was darf sich nicht ändern. Am Ende steht eine geschriebene Fassung des Problems, keine Lösungsidee.
-
2
Schneiden
Ein kleinster Umfang, der schon nützt, und eine klare Grenze, was nicht dazugehört. Lieber ein enger Schnitt, der in Betrieb geht, als ein weiter, der es nie tut.
-
3
Bauen
In sichtbaren Schritten, jeder davon lauffähig. Sie sehen den Stand am laufenden System, nicht im Statusbericht.
-
4
Betreiben
Ausgeliefert über den CloudManager: mit Sicherung, Überwachung, Aktualisierungsweg und Prüfpfad, vom ersten Tag an.
Häufiger wird eine bestehende Anwendung übernommen. Mehrere der heute betriebenen Produkte sind so entstanden: aus einer Bastellösung auf einem Einzelrechner in einen überwachten Betrieb.
Für wen
Wer damit etwas anfangen kann
Systemhäuser
Sie betreuen Kunden, die zunehmend nach Cloud fragen, wollen aber nicht zum Wiederverkäufer eines Hyperscalers werden. Mit der Plattform liefern Sie unter eigenem Namen aus und behalten die Kundenbeziehung samt Marge.
Rechenzentren
Sie haben Fläche, Strom und Hardware, verkaufen aber bisher vor allem Kapazität. Die Plattform macht daraus ein Dienstangebot: Produkte statt Maschinen, mit Bestellung, Mandantentrennung und Abrechnungsgrundlage.
IT-Dienstleister
Sie betreiben für mehrere Kunden ähnliche Anwendungen und pflegen sie heute einzeln. Ein Bestand, ein Aktualisierungsweg, eine Sicherungsstrategie statt derselben Handgriffe mal fünf.
Mittelstand mit eigener IT
Sie wollen Daten im Haus behalten und trotzdem den Komfort moderner Dienste. Beratung und individuelle Lösungen greifen hier meist vor der Plattform.
Open Source
Digitale Unabhängigkeit als Bauweise
Aus langjähriger Arbeit mit offener Software ist hier eine Plattform entstanden, die vollständig auf offenen Bausteinen steht. Mit Gesinnung hat das wenig zu tun: Wer den Quelltext seiner Werkzeuge lesen, prüfen und im Zweifel selbst weiterführen kann, ist von keiner Preisliste und keiner Produktstrategie abhängig.
Offen bis in die Grundlagen
Linux, PostgreSQL, Docker, nginx, Traefik, Prometheus, OpenBao, Headscale: Jeder tragende Baustein ist quelloffen und ohne Lizenzvertrag betreibbar. Keiner dieser Bausteine hängt an einem Anbieter, der ihn zurückziehen könnte. CloudManager selbst ist nicht veröffentlicht. Offen sind die Grundlagen, auf denen es steht.
Keine Lizenzfalle
Kosten entstehen für Betrieb und Arbeit, nicht pro Nutzer, pro Kern oder pro Jahr. Ein wachsender Bestand macht die Rechnung nicht sprunghaft teurer, und eine geänderte Lizenzpolitik macht ihn nicht über Nacht unbezahlbar.
Prüfbar statt zugesichert
Wo Verschlüsselung, Rechteprüfung und Protokollierung wirklich stattfinden, lässt sich nachlesen. Bei geschlossener Software bleibt an dieser Stelle nur die Zusicherung des Herstellers. Bei allem mit Schutzbedarf macht das einen Unterschied.
Weiterbetrieb ohne mich
Die Bausteine sind verbreitet und dokumentiert, die Daten liegen in offenen Formaten. Wenn Sie diesen Weg eines Tages ohne levit-cloud fortsetzen wollen, ist das eine Übergabe und kein Neuanfang.
Der Unterschied zum Wiederverkauf einer Hyperscaler-Region: dort können Sie Ihrem Kunden den Ort zusichern, aber nicht den Betreiber. Digitale Souveränität heißt hier nicht, alles selbst zu hosten. Es heißt, an jeder Stelle die Wahl zu behalten: welcher Anbieter, welches Land, welches Rechenzentrum und wann gewechselt wird.
Haltung
Womit hier nicht gearbeitet wird
Keine Zahl ohne Herkunft
Jede Kennzahl auf dieser Seite lässt sich auf eine Abfrage zurückführen, und daneben steht, wann sie erhoben wurde. Was nicht gemessen ist, wird nicht behauptet.
Keine geliehene Erfahrung
Ich empfehle nur, was ich selbst betreibe, die Fehlschläge eingeschlossen, und sage Ihnen, was es mich gekostet hat.
Kein Einbahnbetrieb
Zu jedem Weg hinein gehört einer hinaus: Daten exportierbar, Anbieter austauschbar, Aktualisierungen mit Rückweg. Bindung soll aus Nutzen entstehen, nicht aus Aufwand beim Wechsel.
Keine Größe, die es nicht gibt
Hinter levit-cloud steht eine Person, kein Konzern. Das ist die Grenze und zugleich der Grund, warum Sie im Gespräch direkt mit dem sprechen, der es gebaut hat.
Kontakt
Zeigen statt behaupten
Statt einer Präsentation zeige ich Ihnen das laufende System: echte Hosts, echte Rollouts und die Stellen, an denen es noch nicht fertig ist.
kontakt@levit-cloud.de. Eine Preisliste gibt es hier nicht: Umfang und Preis hängen davon ab, wie viel Betrieb Sie abgeben und wie viel Sie behalten wollen.