Who Controls How Your Code Runs? – True Digital Sovereignty
-
About
- Type
- Blog
About
Table of contents
Posted on 27 March 2026
Debates about digital sovereignty often focus on comparing American cloud services with European alternatives. This captures an important concern, but it risks oversimplifying where the real dependencies lie.
Cloud discussions often focus on where systems run. Much less attention is given to who controls how they run. The real dependencies rarely sit in the applications themselves. They sit in how application code is executed in production. Execution is rarely treated as an independent architectural decision. Yet this is where practical control over how systems operate is ultimately defined.
“Digital sovereignty is not defined by where your servers are. It is defined by who controls the conditions under which your software runs. That is an architectural question, and right now, most organizations have never asked it.”
Nimer Björnberg, Co-Founder and CEO, NorNor
This becomes clearer when we look more closely at how modern cloud platforms actually work. Even when infrastructure is based on open source or European IaaS providers, the execution model itself is often deeply integrated into the platform running the environment.
In practice, all of this is defined by the platform providing the infrastructure. For organizations, this means that even when data and servers can be moved, the way an application actually runs is often still tied to a specific environment.
Throughout the history of computing, when dependencies between systems become too strong, architecture tends to evolve by introducing clearer interfaces.
In each case, a layer was introduced that separated the application from the underlying technology.
Cloud computing has simplified infrastructure in many ways. But how application code is executed is still largely defined by the platform running the environment. As a result, control over execution, how code starts, runs and scales, remains closely tied to platform architecture.
The European Data Act strengthens the right to move data between providers and limits technical barriers to switching services. This is an important step. But the ability to export data is not the same as the ability to move the code that actually runs the business.
In other words: data portability does not automatically imply execution portability.
When data becomes portable, the next question naturally follows:
Can the application move as easily as the data?
This is where execution models become central. Because even if infrastructure and data can move geographically, it is the architecture of execution that ultimately determines how dependent an organization is on a particular platform. At the same time, the way software is built has changed. Modern systems consist of hundreds of services, APIs, and background processes that are
deployed continuously.
“When organizations move from hyperscalers to European providers, they often gain jurisdictional control but lose something less visible: control over how their code executes. That layer, execution, is where the real dependency sits. Making it independent is what sovereignty looks like in practice.”
Nimer Björnberg, Co-Founder and CEO, NorNor
As systems become more dynamic, the environment in which code executes becomes increasingly important. Control is no longer defined only by where infrastructure is located, but by how application code is allowed to run.
If execution is treated as an integrated part of a specific platform, it effectively becomes part of that provider’s control model. If it can instead be separated from the infrastructure, the architecture becomes more portable. This does not reduce the importance of infrastructure. Reliable and transparent infrastructure remains essential.
But it allows organizations to separate two different questions:
In recent years, there has been growing interest in approaches that separate execution from the underlying platform. The idea is to make execution an explicit architectural layer rather than an implicit property of a specific cloud platform.
One example is Heim, an execution environment designed to decouple how application code runs from the infrastructure beneath it. In such a model, the same application code can execute across different infrastructures without the execution logic itself being defined by the platform operating the environment.

In practice, this means the same code and the same developer workflows, regardless of where the infrastructure runs. This does not eliminate the need for stable infrastructure. But it shifts control over how code runs from the platform to the architecture.
Discussions about digital sovereignty often begin with the question of where infrastructure is located. That is an important question. But as cloud architectures evolve, it becomes increasingly clear that technical control over systems is not determined by geography alone. It is determined by how execution is architected, and ultimately by who controls the conditions under which application code runs.
In a European context, where questions of digital sovereignty and infrastructure independence are becoming increasingly important, this architectural distinction may prove decisive. In the end, digital sovereignty is not defined only by where infrastructure is located.
It is defined by who controls how software actually runs.
Guest post by Nimer Björnberg
Nimer Björnberg is CEO and Co-founder of NorNor, the company behind Heim. He works at the intersection of software architecture, digital sovereignty, and operational simplicity in cloud environments.
Heim is an execution platform for backend applications that simplifies how applications are run, managed and secured across cloud and data center environments.
