Who Controls How Your Code Runs? – True Digital Sovereignty

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.

The missing layer in the digital sovereignty debate

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.

  • How code starts.
  • How it is isolated.
  • How it scales.
  • How networking, resources and operations are managed.

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.

A recurring pattern in the history of computing

Throughout the history of computing, when dependencies between systems become too strong, architecture tends to evolve by introducing clearer interfaces.

  • Operating systems made applications independent of specific hardware.
  • Internet protocols made it possible for different networks to communicate.
  • Virtualization made servers movable between environments.

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.

When data becomes portable, the next question emerges

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.

Execution as an architectural decision

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:

  • Where do systems run?
  • And who defines how they run?

Emerging interest in independent execution models

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.

Heim guest blog post visual showing the two different layers

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.

Sovereignty as an architectural choice

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.

Photo of Nimer Björnberg, CEO and Co-founder of NorNor, creators of Heim

Summer promotion!

Start your free 30-day trial today and discover why thousands of businesses trust UpCloud

  • $500 free credits
  • Risk-free trial
  • Optimized performance
  • Scalable infrastructure
  • Top-tier security
  • Global availability

Sign up

See also

UpCloud banner with document ands erver icons, visualizing digital transformation in regulated industries.

Navigating Digital Transformation in Regulated Industries

In our recent webinar, Mafalda Johannsen sat down with Sampsa Somerma, Director of Digitalisation, Data, and AI at Oriola, to discuss all things digital transformation. Here's what we learned!

Fiona Horan

Enterprise Marketing Specialist

Portrait of Teemu Toppola, newly appointed Head of Product at UpCloud, with his arms crossed against an abstract background of data light trails.

UpCloud appoints Teemu Toppola as Head of Product

UpCloud is delighted to announce the appointment of Teemu Toppola as our new Head of Product, effective September 1st, 2023. Teemu joined UpCloud in 2021 […]

Pihla Jormakka

Brand Specialist

Post on UpCloud's blog about Terraform best practices for beginners.

Terraform best practices for beginners

Getting started with Terraform takes some effort to read the documentation. To give you a head start, we've compiled a quick list of Terraform best practices.

Janne Ruostemaa

Editor-in-Chief

Back to top