Wir könnten es selbst — warum wir es nicht tun
OB7 entwickelt White-Label-SaaS für EV-Charging. Unsere Kunden sind Stadtwerke, Energieversorger und Betreiber von Ladeinfrastruktur. Server selbst aufsetzen können wir. Das Know-how ist im Haus.
Aber jede Stunde an Serverproblemen fehlt im Produkt. Das ist keine romantische DevOps-Geschichte, sondern eine einfache Rechnung.
Wir lagern Deployment deshalb bewusst aus. Nicht aus Unvermögen, sondern weil wir kontrollieren wollen, wohin unsere Engineering-Zeit fließt. Software bauen — ja. Sie produktiv betreiben — nicht selbst.
Der Schatten neben dem Build
Der Gedanke „Lass uns das kurz selbst hosten" endet fast immer in einem Berg an Arbeit, der nichts mit dem Produkt zu tun hat.
SSL-Zertifikate ausstellen, erneuern, monitoren. Webhooks und CI/CD pflegen — meistens macht es jemand, der eigentlich an der Anwendung programmieren sollte. Provider-Accounts, Rechnungen, Compliance-Kram. Nächtliche Wartungsfenster planen und kommunizieren. Selbst wenn alles glatt läuft, ist das Sprint-Zeit, die nicht in Features fließt.
Software und somit Container builden & bauen gehört zu unserem Produkt. Alles zwischen „Code ist fertig" und „Website ist online" soll uns nicht parallel zur eigentlichen Arbeit auf den Tisch fallen.
Wir wollten nur deployen
Die Anforderung an lowcloud war simpel: Wir liefern das fertige Container-Image. Der Rest soll ohne YAML-Marathon und ohne nächtliche Server-Pflege funktionieren.
Heute wird unsere Website vollständig über lowcloud ausgespielt. Im Alltag heißt das:
Registry anbinden, Webhook setzen, deployen. Keine zusätzliche Klickstrecke und keine parallele CI/CD-Bastellösung pro Release, die wieder jemand warten muss.
Was heute automatisch läuft
Seit dem Switch kümmern wir uns nicht mehr um Server-Provisioning, sobald das Image steht. Kein manuelles Nachfassen beim Provider, keine Ticketkette nur fürs Hochfahren von Maschinen.
SSL-Zertifikate werden ausgestellt und erneuert, ohne dass wir Let's Encrypt per Hand und Cronjobs zusammenkleben müssen. Bei jedem Push auf GitHub feuert ein Webhook, das Deployment rollt an, und nach 50 Sekunden ist die neue Version live. Wir pflegen keine eigene Pipeline mehr, deren einziger Zweck es ist, Infrastructure-Configs aktuell zu halten. Load Balancing und Routing sind fertig konfiguriert da und fressen nicht jede Woche Zeit im Sprint-Refining.
Nach den ersten Deployments war unser Fazit im Team kurz: SSL-Provisioning rennt, Images ziehen klappt, Webhook funktioniert. „Stumpf ist Trumpf" ist uns im Alltag deutlich lieber als Last-Minute-Bastelei vor dem Release.
tl;dr: Wir geben das Container-Image rein, lowcloud gibt die Website raus.
Warum nicht einfach ein eigenes Cloud-Konto?
Viele Teams fahren gut mit Bring-your-own-Cloud: eigenes Konto, eigene Beziehung zum Provider, volle Kontrolle. Kann der richtige Weg sein. Für uns war bewusst das Gegenteil gefragt. Kein eigener Hetzner-Account zum Mitführen, keine Cloud-Rechnungen im Team verteilen, Infrastruktur-Compliance nicht als Daueraufgabe neben dem Produkt.
lowcloud hostet auf deutschen und europäischen Providern, unter anderem Hetzner. Für OB7 in einem regulierten Umfeld — E-Mobility, Verträge, hohe Erwartungen an Daten und Verfügbarkeit — war das ein entscheidender Faktor. DSGVO-konform, ohne dass wir die Compliance-Kette fürs Hosting selbst zusammenstellen.
Konkret im Alltag: praktisch kein Infrastruktur-Overhead mehr. Kein Rätselraten vor ablaufenden Zertifikaten, kein On-Call für „die Maschine". Letzendlich haben wir unter anderem „2 Stunden im Sprint freigespielt", „>5 Releases/Woche ohne Infra-Eskalation".
Delegieren ist eine Produktentscheidung
Dieser Schritt steht direkt neben unserer Zero-Bug-Policy. Qualität heißt nicht nur, Bugs schnell zu beheben. Es heißt auch, die richtige Arbeit zu priorisieren und den Rest so zu organisieren, dass er nicht ständig als Problem zurückkommt. Delegieren ist hier kein Ausweichen, sondern Prioritätensetzung.
OB7 bleibt auf EV-Charging-Software fokussiert. Wir konzentrieren uns auf das, was Betreiber und Fahrer vor der Ladesäule erwarten — und machen keinen zweiten DevOps-Job im Team auf.
Wer sein Team beim Deployment ähnlich entlasten will: lowcloud.io.