Code Sovereignty Starts with the Forge

Digital sovereignty is usually discussed in terms of cloud platforms, data spaces, artificial intelligence, cybersecurity, and strategic autonomy. Yet every digital public service ultimately depends on a more fundamental layer: the infrastructure where source code is written, reviewed, stored, released, and maintained. This article analyses the Dutch government’s Forgejo-based code.overheid.nl platform as a concrete example of sovereign software-development infrastructure. Using only official Dutch government, European Union, and Forgejo documentation, it argues that a public-sector Git forge is not merely a developer tool but a control point in the software supply chain. The Dutch initiative matters because it operationalises open-source policy, public-code reuse, cyber resilience, interoperability, and European digital commons into a governed environment where public software can be produced under public control. For Europe, such platforms are not symbolic alternatives to commercial forges; they are foundational components of digital sovereignty.

Introduction

Digital sovereignty is often discussed at the level of cloud, artificial intelligence, semiconductors, cybersecurity, or data spaces. Those layers are important, but they are not the first layer. Before a public administration can control an application, a platform, an AI service, or a digital public service, it must control the software production chain that creates, reviews, signs, stores, publishes, and maintains the source code.

That is why the Dutch government’s code.overheid.nl initiative is more than a developer convenience. The official landing page describes it as a code platform for the Dutch government where public organisations develop source code together on a digital, sovereign, open source platform; it offers secure Git repositories, pull requests, issue tracking, and code reviews, and it is hosted on Dutch government infrastructure¹.

From a first-principles perspective, source code is the executable memory of a modern state. If public services are implemented in software, then the place where that software is versioned, reviewed, integrated, and released is part of the state’s operational infrastructure. A government that depends structurally on an external proprietary forge for that function does not fully control the lifecycle of its own digital public services.

The basic problem: public software needs public control

A Git forge is not just a repository. It is the system of record for source code, contribution history, identities, access rights, pull requests, reviews, issues, automation hooks, releases, and sometimes CI/CD pipelines and software packages. In practice, it becomes the coordination layer through which public software is produced.

The Dutch government developer portal states the problem directly: government open source software has historically been hosted on external Git forges that are not under government control, while hosting source code is a critical part of infrastructure because government must be able to trust how code and binaries are produced².

The Netherlands is therefore addressing a dependency at the root of the software supply chain. If source code is hosted on infrastructure outside public control, then the administration remains dependent on an external platform’s licensing model, policy decisions, availability, jurisdictional exposure, identity system, integration roadmap, API compatibility, and business incentives. Even when the hosted code is open source, the forge itself may remain a dependency.

This distinction is central. Publishing open source code on a proprietary platform increases transparency, but it does not by itself create sovereignty over the development infrastructure.

code.overheid.nl: what the Dutch platform actually is

The official Dutch code platform presents itself as a shared code platform for the Dutch government. It is designed for open source development, cross-government collaboration, reuse of existing solutions, and sovereign secure hosting on Dutch government infrastructure³.

The developer portal states that code.overheid.nl had its soft launch on 24 April 2026 and is a shared Git environment for government, built on Forgejo. It also states that the platform is in a pilot phase and is being built together with developers.

This matters architecturally. The initiative is not only a publication catalogue; it is a working environment. A catalogue makes code discoverable after the fact. A forge changes how software is produced before release. It allows public organisations to converge on shared templates, shared pipelines, shared governance practices, shared review models, and shared reusable components.

The Dutch OSS register already functions as a beta overview of open source repositories for the Dutch government, with metadata on repository status, software type, maintenance model, and publiccode.yml availability⁴. A sovereign forge complements that catalogue by moving from discovery to controlled production.

Why Forgejo is strategically significant

Forgejo⁵ describes itself as a self-hosted lightweight software forge, focused on security, scaling, federation, and privacy. Its official site explicitly presents it as a self-hosted alternative to GitHub and states that organisations can take back control of their software development process by self-hosting their projects.

That is the core sovereignty property. A self-hosted forge allows the administration to control where code is stored, which identities access it, which security policies apply, which logs are retained, how backups are handled, how integrations are governed, and how the platform evolves.

Forgejo’s official documentation⁶ also shows that it supports the operational capabilities expected from a modern forge: repository management, pull requests, issues, access tokens, authentication, branch protection, package registries, webhooks, actions, runners, and installation options including binaries and Docker.

This does not mean that Forgejo automatically solves every governance, security, scalability, or compliance issue. The platform must still be hardened, operated, monitored, backed up, patched, and integrated into identity, logging, vulnerability management, and release governance. But it changes the control model: the government becomes the operator of the forge, not merely a tenant of someone else’s developer platform.

The Dutch policy context: open, unless

The Dutch initiative is not isolated. It fits into a broader national policy line. The Dutch government explains open source as software whose source code is freely available so that everyone can read, modify, and distribute it. It also states that the government called in 2020 for the source code of government software to be released as much as possible, under the principle open, unless⁷.

The implementation of the Open Data Directive in Dutch law further strengthens this principle. The Dutch government states that software made or commissioned by government should be open source as much as possible, that source code is government information, and that public-sector source code should be made suitable for reuse where possible, preferably under the EUPL licence⁸.

The key point is that open source is no longer only a cultural preference or a developer habit. It is becoming part of public-sector information governance. If code is government information and must be reusable where possible, then the state needs infrastructure capable of managing that code as public infrastructure.

A sovereign Git forge is therefore the operational counterpart of open, unless. Without a controlled development platform, the policy remains dependent on fragmented external hosting practices.

The EU policy context: open source as digital autonomy

The European Commission’s Open Source Software Strategy 2020–2023 states that open source contributes to the Commission’s digital strategy and to the Digital Europe programme. It promotes sharing and reuse of software solutions, knowledge, and expertise to deliver better European services and lower costs. Its stated objectives include progressing towards Europe’s digital autonomy, encouraging sharing and reuse, sharing the Commission’s source code, and building a world-class public service⁹.

This gives the Dutch initiative European significance. A national forge is not merely a national IT tool. It is a building block in a European pattern: public administrations need reusable, inspectable, collaboratively developed software components that can travel across borders without forcing other administrations into the same proprietary dependency chain.

The Interoperable Europe Act points in the same direction. The official Interoperable Europe Portal states that the Act aims to remove legal, organisational, semantic, and technical obstacles and to create a network of networks of sovereign, interconnected public administrations across the EU. It also emphasises sharing and reuse of interoperability solutions through the Interoperable Europe Portal¹⁰.

A sovereign code forge is one of the practical mechanisms through which that network of networks can become real. Interoperability is not only about APIs and data formats. It is also about the ability of public administrations to co-develop, inspect, fork, adapt, and maintain the software components that implement those APIs and public services.

Digital commons and the move beyond isolated pilots

The EU Digital Commons EDIC was launched to strengthen European digital sovereignty by coordinating national efforts to develop open, interoperable, reusable digital solutions shared across borders. The Commission states that the initiative brings together France, Germany, the Netherlands, and Italy, and that it is designed to move from isolated pilots to shared, scalable digital infrastructure¹¹.

This is precisely the category in which a public-sector forge belongs. If every administration publishes code in a fragmented way, Europe gets visibility but not necessarily reuse. If administrations converge on shared governance, metadata, licensing, security practices, and federation patterns, Europe gets the basis for digital commons.

The Dutch platform is therefore important because it operationalises a missing layer: not only publish public code, but produce public code in an environment aligned with public control, reuse, and cross-government collaboration.

Cyber resilience starts before deployment

The Cyber Resilience Act gives further strategic weight to the issue. The Commission states that free and open-source software has a central role in the cybersecurity of products with digital elements and in the EU economy. It also introduces the notion of open-source software stewards, who support the sustained development and viability of open-source software intended for commercial activities, with obligations such as secure development policy and vulnerability handling¹².

This matters because the security of public software cannot be reduced to penetration testing after deployment. It begins in the forge: identity governance, branch protection, peer review, signed commits, dependency review, SBOM generation, vulnerability management, release traceability, reproducible build practices, and incident response workflows.

A sovereign forge does not eliminate software supply-chain risk, it makes that risk governable. The administration can define mandatory controls, enforce minimum workflows, integrate national standards, and collect audit evidence without waiting for the policy surface exposed by an external platform.

Why this is sovereignty infrastructure

The argument can be reduced to a few hard premises.

First, public services increasingly execute through software. Second, software behaviour is determined by source code, dependencies, build systems, configuration, secrets, deployment pipelines, and runtime infrastructure. Third, the forge is where source code and much of the associated governance metadata are created, reviewed, stored, and released. Fourth, control over a digital public service is incomplete if the public authority does not control the infrastructure that governs its code lifecycle.

From those premises, the conclusion follows: a government code forge is not a peripheral developer tool. It is part of sovereign digital infrastructure.

This does not imply autarky. Europe should not isolate itself from global open source communities. The stronger position is controlled openness: publish code, reuse code, contribute upstream, federate where useful, but avoid structural dependence on a small number of external platforms for the production of public-sector software.

The European Commission’s Digital Commons EDIC language is aligned with that logic: it frames digital commons as a way to reduce dependency on a small number of global platforms and to provide real digital choice based on European values.

Architectural implications for public administrations

A public-sector forge should not be treated as a simple hosting migration. It should be designed as a governed software production platform.

At minimum, the operating model should include:

1. identity integration with government-controlled IAM;
2. mandatory MFA and privileged-access governance;
3. branch protection and mandatory peer review;
4. signed commits or equivalent provenance controls for critical repositories;
5. dependency and vulnerability scanning;
6. SBOM generation for released software;
7. controlled CI/CD runners, with separation between trusted and untrusted workloads;
8. audit logging and retention aligned with public-sector accountability;
9. backup, disaster recovery, and exit procedures;
10. standard repository metadata, preferably aligned with publiccode.yml;
11. licence governance, with EUPL or other approved open-source licences where appropriate;
12. documented contribution models for inter-administration and external community participation.

The important design principle is that sovereignty is not achieved by merely installing Forgejo. It is achieved when the forge becomes the controlled trust anchor of the public software lifecycle.

Risks and limits

The initiative also has risks.

The first risk is symbolic sovereignty: creating a national forge but continuing to develop critical code elsewhere because developer experience, tooling, automation, or support are insufficient. That would create a public façade rather than a real operational shift.

The second risk is fragmentation. If every administration creates its own isolated forge without federation, shared metadata, shared licensing practices, and shared discovery mechanisms, the result may be many sovereign islands rather than a reusable public software ecosystem.

The third risk is underfunded maintenance. Open source does not remove the need for sustained engineering. It shifts the investment from licence rent to capability, maintenance, security, community governance, and long-term stewardship.

The fourth risk is confusing self-hosting with security. Self-hosting increases control, but it also increases responsibility. A poorly operated sovereign forge can be less secure than a mature external platform. The decisive variable is not ownership alone; it is governed operational capability.

Why this matters beyond the Netherlands

The Dutch initiative is relevant to the whole EU because it demonstrates a concrete path from policy language to infrastructure.

Europe already has policy objectives around digital autonomy, interoperability, open source, cyber resilience, and digital commons. The missing step is often operational: where do administrations actually collaborate on code, under what governance model, with what security controls, and with what long-term stewardship?

code.overheid.nl answers that question at national level. If connected to EU-level catalogues, interoperability initiatives, and digital commons structures, such platforms can become part of a European public software fabric.

That fabric would not replace global open source. It would strengthen Europe’s position inside it. European administrations could contribute more systematically, reuse more effectively, reduce duplicated procurement, and keep strategic control over critical public-sector software assets.

Conclusion

The strategic importance of code.overheid.nl is not that the Netherlands has created another Git hosting site. The important point is that a government has recognised the forge as sovereign infrastructure.

A state that cannot control its software production chain cannot fully control its digital public services. A Europe that cannot share, inspect, adapt, and maintain public-sector software through governed open infrastructures will remain dependent on external platforms even when the code itself is open.

The Dutch Forgejo-based code platform is therefore best understood as a practical sovereignty primitive. It connects open, unless policy, public code reuse, supply-chain security, digital commons, and European interoperability into one operational layer: the place where public software is actually built.

For EU digital sovereignty, that layer is not optional. It is foundational.

See also longforms

Reclaiming the Namespace: EU Digital Sovereignty in the CVE Ecosystem?

Rebalancing coordination and autonomy: EU digital sovereignty, federated CVE governance, and the conditions for sustainable economic growth

See also posts

The French state becomes machine readable through an AI layer

Inside the data.gouv.fr MCP server and the new interface stack for public data

France’s Linux Desktop Turn and the European Logic of Digital Sovereignty

From a French workstation migration signal to the broader European effort to regain control over critical digital infrastructure

Footnotes

1. The official Dutch government code platform code.overheid.nl presents itself as the government-wide code platform for public organisations in the Netherlands. It describes the platform as a sovereign, open-source environment for collaboration on government source code, including Git repositories, pull requests, issue tracking, and code review. Website

2. This official Dutch government developer article explains why government source code should not depend structurally on external Git forges outside government control. It frames source-code hosting as a critical infrastructure layer for trustworthy software production and recommends a government-controlled Git forge.

3. This official Dutch government developer article announces the collaborative construction of code.overheid.nl. It explains that the platform is being built as a shared Git environment for government, based on Forgejo, and positioned as part of a broader move toward sovereign public-sector software development infrastructure.

4. The Dutch government OSS register provides an overview of open-source repositories associated with Dutch public organisations. It supports discoverability, reuse, and transparency by cataloguing government software projects and related metadata.

5. The official Forgejo website describes Forgejo as a self-hosted software forge designed to let organisations control their own software development process. This is relevant because self-hosting changes the governance model of the repository from external platform dependency to direct operational control.

6. The official Forgejo installation documentation describes the deployment options and administrative setup of Forgejo. It is relevant for understanding that the platform is not merely a repository interface, but an operable software-forge stack that can be hosted and governed by the adopting organisation.

7. This official Dutch government page explains the broader Dutch open-government context, including transparency, openness, and the publication of government information. It provides policy background for treating government source code as public information where publication and reuse are appropriate.

8. This official Dutch government notice explains the entry into force of the Dutch law implementing the EU Open Data Directive. It is the relevant source for the claim that software made or commissioned by government should, where possible, be published as open source, that source code is treated as government information, and that public-sector source code should be made suitable for reuse, preferably under the European Union Public Licence (EUPL).

9. The European Commission’s official open-source software strategy explains how open source contributes to the Commission’s digital strategy, software reuse, knowledge sharing, cost reduction, and Europe’s digital autonomy. It provides the EU-level policy basis for connecting public-sector open source with digital sovereignty.

10. The official Interoperable Europe Act page explains the EU framework for cross-border interoperability among public administrations. It is relevant because sovereign software repositories can support reuse, shared solutions, and technical interoperability across European public-sector organisations.

11. This official European Commission announcement describes the launch of the Digital Commons EDIC to advance European technological sovereignty through shared, interoperable, reusable digital solutions. It is relevant because public-sector code repositories can function as operational infrastructure for European digital commons.

12. This official European Commission page explains how the Cyber Resilience Act relates to open-source software. It is relevant because it connects open-source software, secure development practices, vulnerability handling, and software supply-chain responsibility—issues that are directly affected by how public-sector repositories and forges are governed.