Digital sovereignty is not built in strategy documents. It begins with a git push.

Some days I want to shout into the void:

We keep talking and talking about European digital sovereignty. About control over our data, our technology, and our critical infrastructure. About the need to reduce dependency on American technology giants.

But when do we actually start acting?

Digital sovereignty does not come from another strategy, another statement of intent, or another PowerPoint deck. It is created through concrete technological choices.

And one of the most important choices concerns your company’s code.

Code is the foundation of your business

#

Code is no longer just a concern for the development department. It drives products, customer journeys, automation, data processing, and critical business processes.

Every IT director should therefore be able to answer:

• Where does our code live?
• Who controls the infrastructure around it?
• What legislation is our organization actually subject to?
• Can we move our code, pipelines, and artifacts without a lengthy migration project?
• What happens to the business if a key vendor changes pricing, terms, or access?

If the answers are unclear, the business does not just have a technical challenge. It has a strategic risk.

Sovereignty has to be felt in day-to-day operations

#

This is where fremforge comes in.

fremforge is a European Git and CI/CD platform where code, builds, and artifacts run on T Cloud Public in Germany. The platform’s critical data path is designed without US-controlled cloud providers or US-owned subprocessors.

The goal is not to carry out a revolution overnight.

The goal is to make the first step realistic, measurable, and low risk.

It makes it possible to:

• reduce strategic vendor dependency
• strengthen ownership and control over your company’s code
• limit legal and operational risk
• increase resilience and long-term freedom to act
• create a clear business case for security and resilience

Start with one team and one repository

#

You do not need to move the entire organization at once.

Pick one well-defined project. Map its dependencies. Move the code and the build process. Test security, workflows, export options, and the day-to-day developer experience.

Agree up front on what the pilot needs to prove:

1. Can the team work effectively on the platform?
2. Does the code and build data stay on the intended European infrastructure?
3. Can the solution integrate with the company’s existing environment?
4. Can code, configuration, and history be exported again?
5. Which risks and dependencies are actually reduced?

After 30 days, you will have something far more valuable than another debate about principles: real experience, documentation, and an actual basis for decision-making.

So my call to the IT director is simple:

Pick one team and one repository. Give them 30 days. Let them prove that European digital sovereignty can work in practice.

And to the engineers:

If you can already see the need, make the dependencies visible. Show leadership where the code lives, which external services your pipelines call, and what it would take to keep control.

Change does not begin with everyone agreeing.

It begins with someone taking the first concrete step.

If you want to name the first team and repository, let’s have a conversation.