ONE STEP AWAY FROM FULL SOVERENITY
Ghost Nodes 10.0.0 removes more external dependencies
When someone asks who controls your critical platform, “good question” is not the answer you want to give. Ghost Nodes is already sovereign where it matters most: in runtime. With version 10.0.0, we have removed more of the few external platform dependencies that still remained. Not very loud. Quite important. And now only one final step remains before Ghost Nodes can be offered as a fully sovereign platform.
Digital sovereignty has moved from a side topic to a real requirement.
Not because the cloud suddenly became a bad idea.
But because critical operations need to know where systems run, where data is stored, who controls access, and which external services the environment actually depends on.
A bit old-fashioned, perhaps. Like locks on doors.
Sweden’s new cloud policy points in the same direction: use cloud services when they create value, but avoid building architectures where the exit plan mostly consists of hope, meetings and a surprisingly large number of consulting hours.
That is exactly the kind of dependency Ghost Nodes was built to avoid.
Sovereignty starts at runtime
Ghost Nodes is already sovereign where it matters most: at runtime.
Integrations, automations and AI workflows can run where the business needs them — on-premises, in private cloud, in public cloud, hybrid, or in environments where the internet should preferably not be the main character.
That has been the foundation of Ghost Nodes for a long time.
But full platform sovereignty is not only about where workloads execute. It is also about identity, updates, components, configuration and the remaining services a platform depends on to operate.
That is where Ghost Nodes 10.0.0 takes another important step.
What changed in Ghost Nodes 10.0.0
In this release, we have removed more of the few external dependencies that still remained.
First, we have replaced IdentityServer 4 with Keycloak.
That means Ghost Nodes continues to support federated login through the customer’s existing identity providers, while also enabling local accounts when the environment requires it.
Second, we have replaced MyGet feeds with ProGet feeds.
In plain English: components and updates can now be hosted where we or the customer want them — not where an external service happens to live.
For most people, this probably sounds about as exciting as reading the version history of a printer driver.
Fair.
But the effect is important.
More of the Ghost Nodes platform can now be managed on the customer’s terms — from runtime to identity, components and updates.
- How users and access are handled.
- Where components and updates live.
- Which external services the environment actually needs to depend on.
These are the kinds of details that rarely get applause in a release demo.
But when the topic is control, cybersecurity, resilience and digital sovereignty, they are exactly the details that matter.
The last remaining step
Our next step is to move the last remaining parts of platform control to the customer’s local Gateway.
When that is in place, Ghost Nodes will not only be sovereign at runtime.
It will be sovereign in practice, all the way through.
That is a level of sovereignty very few platforms in our category even try to offer.
The cloud is still excellent.
As long as it is a choice.
Not something you discover you are locked into after the door has already closed.
Want to go behind the scenes?
In our Tech Corner, we write about how Ghost Nodes works under the hood — from distributed runtime and hybrid infrastructure to platform control, local execution and the architectural details that tend to matter after the strategy workshop has ended.
