A guided tour through our digitally sovereign ecosystem – Liene at KCD Czech & Slovak 2026

At KCD Czech & Slovak 2026 in Prague, I took the stage to walk the audience through five years of building a digitally sovereign managed-services ecosystem from the ground up – the architectures that worked, the ones we threw away, and the bigger picture of where this is all going. The conference ran on May 21-22 at the Faculty of Information Technology, CTU in Prague, in three languages and packed with the wider European cloud-native community.

True to form, I framed the whole talk around Czech food – each chapter of the journey paired with a dish.

Watch the recording of my talk

The starting point: a single customer project

The story starts in February 2021 with what looked like a normal customer project. The ingredients: Crossplane v0.17, MariaDB, Redis, and an external Cloud Foundry that needed databases on demand via the Open Service Broker API. We called this Framework 0.1.

The architecture was already recognisably what we’d build on later – a control-plane cluster running Crossplane with XRDs and Compositions, talking to one or more service clusters through provider-helm, provider-sql, and provider-kubernetes. Customers ordered an instance, Crossplane composed it, and the right Helm releases, database objects, users, and Kubernetes resources showed up in the service cluster. Four environments: dev, nonprod, prod-nonpremium, prod-premium.

That worked. So I asked the obvious next question: if it works for one customer, can it be a product?

AppCat 1.0: from project to platform

By December 2022 we had AppCat 1.0 – VSHN’s Application Catalog – first wired up to external services, then by 2025 with our own catalog of managed PostgreSQL, Redis, MariaDB, Keycloak, and MinIO. The framework had matured into what we now call Framework 1.0: a clean stack with Service Definitions (XRDs), Service Implementations (Compositions), Crossplane as the control plane, and provider plugins for $App, $Cloud, and Helm – all driven by the Kubernetes API and exposed through the OSB API.

This is the picture most people see when we talk about Crossplane at VSHN. We’ve been running it in production since 2021, we’re an official Crossplane vendor, and we’ll happily argue that you should stop fighting Terraform state and manage your infrastructure through Kubernetes instead. But the framework diagram on a slide hides everything that makes a managed service actually managed.

The unglamorous middle: everything that makes a service managed

The “more features” slide was deliberately boring – a wall of words that anyone who has run a managed database in anger will recognise: backup, restore, logs, metrics, alerting, maintenance, version upgrade, scaling, user management. Plus application-specific things like Collabora for NextCloud, plus giving customers a free choice of infrastructure underneath.

This is where the real engineering lives. The control plane is the easy part. The hard part is everything you have to build, automate, and operate around it before a customer can rely on it at 3am on a Sunday.

The detour: split architecture (and back again)

Not every decision survives contact with reality, and I was refreshingly direct about one we walked back. At some point we tried a Split Architecture – separating the control cluster from the service cluster more strictly, with Crossplane on one side, managed resources and providers in their own namespace, and instances deployed into a service cluster on the other side. The diagram was elegant. The operational reality was not.

So we went back to one cluster. The “Nope – back to one cluster” slide – with the instance namespace dramatically circled in red – got a laugh, and it makes a serious point: sovereignty and operational simplicity aren’t opposed. Sometimes the right answer is the boring one.

Crossplane v2.0 – deliberate adoption

By August 2025 Crossplane v2.0 was on the horizon, with significant changes to how Compositions and packages work. Our position was simple: we wait. Not because we’re conservative for the sake of it, but because the framework we’d built was carrying real production workloads and the migration needed to be deliberate, not opportunistic.

In the meantime, we kept going.

Framework 2.0 and AppSlap

By May 2026 we had Framework 2.0, with a much cleaner separation between what service maintainers do and what framework engineers do. Service maintainers work with a ServiceBundle that references their custom functions. A Converter turns that into proper Crossplane artifacts – Composition, Composite, package metadata – using the VSHN function stdlib. The Crossplane CLI reads those artifacts and builds the Crossplane package. The whole pipeline is what we now call AppSlap 2.0.

The point of this isn’t the diagram. The point is that we can now onboard new services without rebuilding the framework around them – which is what you need if you want an ecosystem rather than a product.

Servala – the sovereign app store

May 2026 also marked the Codey instance running in production on Servala – the part of all this that turns a framework into an ecosystem. Servala is, in plain terms, a sovereign app store: a marketplace and ecosystem hub that connects four kinds of players and routes services to customers.

• Cloud Service Providers bring sovereign infrastructure – compute, storage, network
• Software Vendors bring the applications and tools, open source and commercial
• Managed Service Providers bring 24/7 operations and support
• Implementation Partners bring consulting and integration

Servala sits in the middle. Customers get sovereign managed applications without having to assemble the network themselves, and without locking themselves to any single party in it.

This is what I mean when I say sovereignty is a network problem, not a software problem. No single vendor can credibly claim to be sovereign end to end. What you can do is build the connective tissue that lets independently sovereign providers compose into something a customer can actually buy and run.

What it takes from a sovereign cloud provider

A practical note from the talk: not every cloud calls itself sovereign, and not every sovereign cloud is ready to host this kind of stack. I listed the concrete requirements: a real API to manage cloud resources, self-service VM provisioning, custom VM base image upload, S3-compatible object storage, fast SSD block storage, CSI storage attachments at scale (100+), a managed load balancer with 100+ listeners, NAT gateway and firewall. If any of these are missing, the ecosystem doesn’t land.

These are not exotic asks. They’re the baseline that hyperscalers normalised a decade ago. The good news is that a growing number of European and Swiss providers now check all the boxes – which is what makes the whole project realistic in 2026 in a way it wouldn’t have been five years ago.

Always under construction

One of the slides was just a picture of the Sagrada Família. I took the joke – and the seriousness behind it. Building a sovereign ecosystem is a long game. There’s no version where you finish, take a photo, and walk away. The framework will keep evolving, Crossplane will keep evolving, partners will join and leave, and customers will ask for things nobody has thought of yet.

The CNCF landscape slide made the same point a different way – the cloud-native ecosystem is enormous, and standing on its shoulders is the only sane way to build something at this scale. Sovereignty doesn’t mean reinventing everything. It means assembling the right things, with the right partners, in the right jurisdictions, and keeping the option to change your mind.

Conclusion

Five years in, one lesson stands out above all others: digital sovereignty is not a product that any single company can sell. It’s an ecosystem that has to be built together.

Thank you, Prague

Huge thanks to the KCD Czech & Slovak organisers and the local cloud-native community for two excellent days at FIT ČVUT. The conversations after the talk were as valuable as the talk itself – it’s clear that many people across Europe are thinking hard about what a sovereign, open, and operationally serious cloud-native ecosystem should look like.

I was genuinely energised by the discussions, questions, and feedback after the session. It’s encouraging to see how much interest there is in practical approaches to digital sovereignty and how many organisations are tackling similar challenges.

If you’re building sovereign cloud platforms, managed services, or ecosystem partnerships, I’d love to exchange experiences and explore how we can work together.

Want to learn more about VSHN’s work on digitally sovereign managed services? Visit crossplane.ch, servala.com, or appcat.ch.

About VSHN Application Catalog (AppCat)

VSHN Application Catalog (AppCat) is VSHN’s platform for delivering production-ready managed services across multiple cloud providers and Kubernetes environments. Built on Crossplane and Kubernetes, AppCat automates the full lifecycle of services such as PostgreSQL, MariaDB, Redis, and Keycloak – from provisioning and upgrades to backups, monitoring, and day-2 operations.

What started as a solution for a single customer project has evolved into a framework that powers managed services for organisations across Switzerland and beyond. AppCat enables customers to consume services through self-service interfaces while giving operators a consistent way to manage applications across different infrastructures.

Today, AppCat serves as a core building block of the wider sovereign ecosystem presented in Liene’s talk. It provides the automation and operational foundation that allows managed service providers, cloud providers, software vendors, and implementation partners to collaborate through platforms such as Servala while maintaining openness, portability, and customer choice.