Platform Engineering · Open Source · Sovereign Cloud
Cloud native platforms, built on open source, engineered to stay yours.
Liquid Reply designs, builds and operates Kubernetes platforms on open source foundations, and migrates regulated workloads into sovereign cloud environments, so your infrastructure and your data stay inside the jurisdiction and the architecture you chose.
Kubernetes-native delivery
Open source by default
EU-hosted and auditable
The platform stack
Platform engineering
Golden paths, GitOps and developer self-service.
Cloud native runtime
Kubernetes, service mesh and full observability.
Open source foundation
Components you can read, audit, fork and contribute back.
Sovereign infrastructure
European regions, open standards, no lock-in.
Built on the open source stack the world already runs on
Why sovereignty
Control is an architecture decision, not only a contract clause.
Digital sovereignty only holds up when it is designed into the platform. We build systems where the boundaries are technical, inspectable and reversible, so compliance follows from the architecture instead of resting on assurances.
Jurisdiction
Workloads and data stay in the regions and legal frameworks you choose. Verifiably, not just contractually.
Transparency
Open source components you can read, audit and fork. No black boxes between you and your production systems.
Portability
Standard APIs and infrastructure as code, so changing provider stays an option instead of becoming an emergency.
What we do
A cloud native engineering culture.
Most of our work sits where these three overlap: an open source platform, run cloud native, inside a sovereign perimeter.
Kubernetes platforms, GitOps delivery and the operating model that makes them a product your teams want to use.
Platform engineering
We build on open source, implement it in your environment and contribute upstream, with supply chain integrity and no vendor gate.
Open source
Sovereignty assessments, target architectures and the move of regulated workloads into EU-hosted, auditable environments.
Sovereign cloud
How we work
Small teams, working in your codebase.
01
Assess
We map the current platform, the compliance perimeter and the workloads that actually matter.
02
Design
A target architecture with explicit sovereignty boundaries, written down and open to review.
03
Build
Platform, pipelines and golden paths delivered incrementally, with your engineers alongside ours.
04
Operate
Run it with you, hand it over, or stay on as a second pair of hands. Your call, not a lock-in.
Where this leads
When AI arrives, the platform is already ready.
AI workloads land on the same Kubernetes platform, the same open source components and the same sovereign perimeter. The organisations putting models into production are the ones that got the platform layer right first.
Open-weight models served inside your own perimeter
European regions with operator-controlled key management
Evaluation and guardrails wired into the delivery pipeline
Cost and capacity visibility per team and per model
Model hosting
Open-weight models running on infrastructure you control.
Data & retrieval
Answers grounded in your own governed sources.
GPU scheduling
Kubernetes-native GPU sharing, quotas and cost control.
Guardrails & audit
Policy, evaluation and traceability from the first sprint.
Insights
Notes from the platform.
All articles
A follow-up to our article at the AAIF Blog Designing RequestState for Multi-Round Trip Requests. All code in this post is from the companion repository `openbao-mcp-requeststate` and runs against a real OpenBao and the official 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 offers namespaces or dedicated clusters per tenant. We look at the isolation patterns that sit between those two extremes.
Let’s talk about your platform, your open source stack, or your move to sovereignty in AI and cloud.
Tell us where you are today. We will tell you honestly what is worth changing, and what is not.