Platform Engineering · Open Source · Souveräne Cloud
Cloud-Native-Plattformen auf Open Source, die Ihnen gehören.
Liquid Reply plant, baut und betreibt Kubernetes-Plattformen auf Open-Source-Fundamenten und migriert regulierte Workloads in souveräne Cloud-Umgebungen, damit Ihre Infrastruktur und Ihre Daten in der Jurisdiktion und der Architektur bleiben, die Sie gewählt haben.
Kubernetes-native Umsetzung
Open Source als Standard
EU-gehostet und auditierbar
Der Plattform-Stack
Platform Engineering
Golden Paths, GitOps und Self-Service für Ihre Teams.
Cloud-Native-Betrieb
Kubernetes, Service Mesh und vollständige Observability.
Open-Source-Fundament
Komponenten, die Sie lesen, prüfen, forken und mitgestalten können.
Souveräne Infrastruktur
Europäische Regionen, offene Standards, kein Lock-in.
Aufgebaut auf dem Open-Source-Stack, auf dem die Welt bereits läuft
Warum Souveränität
Kontrolle ist eine Architekturentscheidung, keine Vertragsklausel.
Digitale Souveränität hält nur, wenn sie in die Plattform hineinentworfen wird. Wir bauen Systeme, deren Grenzen technisch, prüfbar und umkehrbar sind, damit Compliance aus der Architektur folgt und nicht auf Zusicherungen beruht.
Jurisdiktion
Workloads und Daten bleiben in den Regionen und Rechtsrahmen, die Sie wählen. Nachweisbar, nicht nur vertraglich.
Transparenz
Open-Source-Komponenten, die Sie lesen, prüfen und forken können. Keine Blackbox zwischen Ihnen und der Produktion.
Portabilität
Offene Schnittstellen und Infrastructure as Code, damit ein Anbieterwechsel eine Option bleibt und kein Notfall wird.
Was wir tun
Drei Disziplinen, eine Engineering-Kultur.
Der Großteil unserer Arbeit liegt dort, wo sich diese drei überschneiden: eine Open-Source-Plattform, cloud-native betrieben, innerhalb eines souveränen Perimeters.
Kubernetes-Plattformen, GitOps-Delivery und die Platform-Engineering-Praxis, die daraus ein Produkt macht, das Ihre Teams gern nutzen.
Platform Engineering
Wir bauen auf Open Source, implementieren es in Ihrer Umgebung und tragen Upstream bei, mit integrer Lieferkette und ohne Anbieterschranke.
Open Source
Souveränitätsanalysen, Zielarchitekturen und die Migration regulierter Workloads in EU-gehostete, auditierbare Umgebungen.
Souveräne Cloud
Wie wir arbeiten
Kleine Teams, direkt in Ihrer Codebasis.
01
Analyse
Wir erfassen die bestehende Plattform, den Compliance-Perimeter und die Workloads, auf die es wirklich ankommt.
02
Design
Eine Zielarchitektur mit klar gezogenen Souveränitätsgrenzen, dokumentiert und überprüfbar.
03
Umsetzung
Plattform, Pipelines und Golden Paths entstehen schrittweise, gemeinsam mit Ihren Engineers.
04
Betrieb
Wir betreiben mit Ihnen, übergeben vollständig oder bleiben als zweites Paar Hände. Ihre Entscheidung.
Wohin das führt
Wenn KI dazukommt, steht die Plattform bereits.
KI-Workloads landen auf derselben Kubernetes-Plattform, denselben Open-Source-Komponenten und im selben souveränen Perimeter. Wer die Plattformebene zuerst richtig gebaut hat, bringt Modelle auch in Produktion.
Open-Weight-Modelle im eigenen Perimeter betrieben
Europäische Regionen mit selbst kontrolliertem Key Management
Evaluation und Guardrails fest in der Delivery-Pipeline verankert
Kosten- und Kapazitätstransparenz pro Team und pro Modell
Model Hosting
Open-Weight-Modelle auf Infrastruktur, die Sie kontrollieren.
Daten & Retrieval
Antworten, die in Ihren eigenen kuratierten Quellen verankert sind.
GPU-Scheduling
Kubernetes-natives GPU-Sharing mit Quotas und Kostenkontrolle.
Guardrails & Audit
Policies, Evaluation und Nachvollziehbarkeit ab dem ersten Sprint.
Insights
Notizen aus der Plattform.
Alle Artikel
Ein Follow-up zu unserem Artikel im AAIF-Blog „Designing RequestState for Multi-Round Trip Requests“. Der gesamte Code in diesem Beitrag stammt aus dem Begleit-Repository `openbao-mcp-requeststate` und läuft gegen ein echtes OpenBao und das offizielle MCP Python SDK.
Many cloud transformations start in a similar way and often repeat the same foundational steps: Landing zones are built individually, governance is redefined several times, and standards are developed from scratch. In practice, teams frequently end up solving very similar challenges with only slight variations. We looked at this in the context of newer and sovereign cloud providers, where publicly available best practices and blueprints are still emerging. Working with a new provider will always involve a learning curve, but it does not have to mean repeating avoidable work. This is the reason for this project. We have developed a Terraform-based landing zone architecture for STACKIT as a reusable blueprint and intentionally want to share it as part of our community work. Our goal is not to replace existing guidance, but to provide an additional, directly usable starting point for other teams. Since STACKIT has also published its own Landing Zone Accelerator, our blueprint should be seen as a complementary implementation perspective based on practical project experience.
Kubernetes bietet Namespaces oder dedizierte Cluster pro Mandant. Wir betrachten die Isolationsmuster zwischen diesen beiden Extremen.
Sprechen wir über Ihre Plattform, Ihren Open-Source-Stack oder Ihren Weg in die souveräne Cloud.
Sagen Sie uns, wo Sie heute stehen. Wir sagen Ihnen ehrlich, was sich zu ändern lohnt und was nicht.