NeoNephos: The Open Cloud Native Stack Europe Actually Needs

Haters gonna hate... You can’t regulate a cloud stack into existence. You have to build it.

I’m tired of sovereignty discussions that stop at “where is the data stored?” or “which jurisdiction applies?”. Important questions, yes. But they are not enough. A sovereign cloud is not a legal checkbox.

It requires a different operating model. It is infrastructure. It is lifecycle management. It is key management. It is UI composition. It is cluster operations. It is packaging. It is discovery. It is federation.

Some might call it a stack. Also, I’m not the biggest fan of calling it that way, as “stack” is too often used inflationally.

And this is why the NeoNephos Foundation is actually interesting.

NeoNephos is not “yet another cloud provider”. It is also not a single product you can install and then everything magically works. To be clear, that is a challenge. But it is also the point.

NeoNephos is trying to create the open source building blocks for a cloud-to-edge stack (Europe likes to call that the Cloud Edge Continuum) that can be run by different providers, different organizations and different countries without everyone reinventing the same wheel in a slightly incompatible way.

That sounds boring. But boring is good in this case. And the … stack … we will look at, in my opinion, is anything but boring.

Hperscalers did not win only because they had better VMs. They won because they offered a full, integrated operating model. Compute, storage, Kubernetes, identity, portals, observability, APIs, billing, discovery, security, lifecycle, documentation and a thousand small things that make the whole system usable.

Europe and honestly the open source cloud ecosystem in general, often has the pieces and the people. It just lacks in the market.

NeoNephos is trying to make those pieces fit together.

TLTR: What is NeoNephos?

NeoNephos is a Linux Foundation Europe initiative that hosts open source projects for cloud and edge infrastructure. Many of the early projects came out of the IPCEI-CIS / ApeiroRA context, but the foundation is not “EU-only”. It is open source, neutral governance and global by design.

The core idea is simple:

Build an open, cloud native, multi-provider stack that avoids vendor lock-in and gives organizations the freedom to run serious infrastructure on their own terms.

Not with PowerPoint sovereignty, but with code.

The current project list is already pretty broad:

• Garden Linux: the operating system layer

• IronCore: Kubernetes-driven IaaS APIs for compute and storage

• CobaltCore: OpenStack / infrastructure operations for the stack

• Gardener: managed Kubernetes at scale

• OpenControlPlane: declarative cloud landscapes and control planes

• Platform Mesh: multi-tenant developer platform on kcp

• Greenhouse: day-2 operations across Kubernetes fleets

• Open Component Model: component packaging and supply chain metadata

• Open Resource Discovery: self-description protocol for services and resources

• Open Micro Frontend Platform: portal platform for micro frontends

• Luigi: micro frontend framework

• Katalis: federation APIs for cloud/edge operators

• Open Key Chain Manager: open key management for customer-managed keys

The stack view

If you look at NeoNephos project by project, it can feel a bit overwhelming. So I think the better way is to look at the layers.

At the bottom, you need an operating system that is built for cloud infrastructure. That is Garden Linux. A good old Debian, continuously managed, updated, and patched. Ready for almost anything.

Then you need infrastructure APIs for compute, storage, and low-level resources. That is where IronCore and CobaltCore come in.

Add Kubernetes as the runtime abstraction on top. That is Gardener.

Next you need a higher-level way to describe whole cloud landscapes. That is OpenControlPlane.

Source: NeoNephos

For your developer-facing self-service, tenancy, authorization, and search comes Platform Mesh.

Then you need day-2 operations, observability, security posture, and access control across many clusters. That is Greenhouse.

To package and transport software components with metadata, provenance, and dependencies, you use the Open Component Model.

Then you need services to describe themselves. That is Open Resource Discovery.

And of course you need something for the eyes, which in other words gives you a portal and UI layer. That is Open Micro Frontend Platform and Luigi.

For federation across providers and edge environments, you might look at Katalis.

And of course, you need key management. That is Open Key Chain Manager.

The point is: NeoNephos is not only solving “how do I start a Kubernetes cluster?”. We solved that enough times already. It is targeting the full cloud operating model.

And that is the interesting part.

Why this stack is actually superior

Now comes the spicy part.

Is the NeoNephos stack better than AWS, Azure, or Google Cloud?

For a startup that wants to deploy a SaaS app tomorrow and does not care about lock-in? Probably not.

Use the hyperscaler. Move fast. Done.

But for governments, regulated industries, European providers, telecoms, research organizations, and enterprises that care about multi-provider control, transparency, portability, and long-term independence?

Then yes, this model is superior.

Not because every single project is already better than every proprietary alternative.

That would be nonsense.

It is superior because the architecture points in the right direction.

1. It is modular, but not random

The open source ecosystem often gives you a box of Lego bricks without instructions. NeoNephos is closer to a stack of components that are meant to fit together.

Garden Linux, Gardener, Greenhouse, OCM, ORD, OpenControlPlane, Platform Mesh, these are not isolated ideas. They share patterns around Kubernetes, declarative APIs, reconciliation, OpenTelemetry, OIDC, and cloud native operations. And all play well together.

That common mental model matters. Yes, other tools should do so too, but in reality many of them require a lot of tinkering before they integrate well.

2. It uses Kubernetes as the integration language

Kubernetes won because of its API model as much as its container scheduler.

NeoNephos leans into that. CRDs, controllers, reconciliation, Kubernetes Resource Model, GitOps, declarative state.

This means the stack is not only “runs on Kubernetes”, but “thinks in Kubernetes”.

That is a big difference.

3. It avoids single-vendor open source traps

A lot of “open source” is technically open but strategically controlled by one company.

NeoNephos being under Linux Foundation Europe matters here. Neutral governance, donated trademarks, shared technical councils, and open contribution models are not bureaucracy. They are anti-lock-in mechanisms.

And yes, governance is boring.

But without governance, open source can become vendor marketing with a GitHub repo attached.

4. It targets federation from the beginning

Most cloud stacks assume one provider owns everything.

NeoNephos assumes many providers have to work together.

That is much closer to the European market reality. Europe will likely not produce one hyperscaler that simply replaces AWS. The better path is compatibility, federation, portability, and shared standards across many providers.

This is where projects like Katalis, ORD, OCM, and OpenControlPlane become strategically important.

5. It includes the boring parts

Everyone wants to talk about compute and AI.

Few people want to build key management, resource discovery, component descriptors, operations dashboards, or micro frontend shells.

But those boring parts are what make platforms usable.

NeoNephos includes them.

That is why I take it seriously.

About the necessity and why we need this path for more digital sovereignty, I gave a closing keynote recently at the Cloud Native Summit Munich. Have a look:

Where there is light, there is shadow

Of course, this is not perfect. And I think it would be dishonest to pretend otherwise.

As I experienced it with my own team, the stack is far from simple. You need to know a lot, be well in engineering, be able to read between the lines (especially where are no/old/outdated docs), and you need to be ready to deal with fragmentation.

It is not a ready-to-use cloud

NeoNephos itself says this clearly. It provides building blocks, not a shrink-wrapped cloud product.

That means adopters still need integration work. A lot of it.

If you expect “install NeoNephos and get a hyperscaler”, you will be disappointed.

Maturity is uneven

Gardener is mature. Luigi is mature. Some other projects are newer, alpha, or still finding their shape.

That is normal for a foundation stack, but it matters for adoption. Production users need to know which pieces are ready now and which pieces are strategic bets.

Documentation is also often weak. Leads to false impressions and ideas about what those tools are.

The naming is sometimes confusing

OpenControlPlane, OpenMCP, OpenMFP, OCM, ORD, KCM… The full-length name of each tool should give a hint about what it is good for, but the abbreviations are a massacre.

I know we are engineers, but still… :D

A stack this broad needs very clear storytelling, otherwise people get lost before they understand the value.

Integration is the product

The hard part is not having projects. The hard part is making them work together in repeatable, supported combinations.

That means reference architectures, conformance tests, packaged distributions, vendor support, documentation, and real-world blueprints.

Without that, NeoNephos risks becoming another “great set of projects” that only experts can assemble.

Hyperscalers still win on UX

Let’s be honest.

AWS, Azure, and Google are not only strong because of technology. They are strong because the user experience is integrated. Docs, consoles, APIs, support, marketplaces, billing, training, certifications.

Open source alternatives need to compete with that. They need proper UX/UI.

Not by copying everything, but by making the open path usable.

Therefore, it needs you

But all of those caveats are solvable. It just needs more contributors. More end users. More people interested in the bigger idea, not to build for one hypervisor, but to build a platform that doesn’t care anymore where it is running.

At https://neonephos.org you will find all projects, how to contribute, how to reach out, discuss and collaborate. Or ask me :)

The bigger point

I think NeoNephos is one of the more important open source infrastructure efforts in Europe right now because it understands something many sovereignty discussions miss:

Sovereignty is not an ON or OFF switch.

It is a path.

You become more sovereign when you can run workloads across providers.

You become more sovereign when your platform is not controlled by one vendor.

You become more sovereign when your components are portable.

You become more sovereign when your keys are under your control.

You become more sovereign when services can describe themselves.

You become more sovereign when operations are standardized.

You become more sovereign when providers can federate.

You become more sovereign when the code is open and governed neutrally.

And yes, you still need companies to build services on top of this. You still need support. You still need money. You still need people. You still need boring operational excellence. But you need them anyhow, with or without hyperscaler.

Complaining about hyperscaler dependency is easy.

Building an alternative is hard.

NeoNephos is at least doing the hard thing.

The Takeaway

The cloud native world does not need another random platform project.

It needs an open stack that covers the full lifecycle: from OS to IaaS, from Kubernetes to operations, from packaging to discovery, from portals to federation, from keys to governance.

That is what makes NeoNephos interesting.

Not because every piece is finished.

Not because it magically solves sovereignty.

Not because Europe can download independence from GitHub.

But because it is building the pieces that independence actually requires.

And in my opinion, that is the only sovereignty discussion worth having.

You can’t download sovereignty.

You have to build it.