SysadminNews

Germany Puts 508,640 Euros Into Flatpak Portals

On this page
  1. Where the money goes
  2. The four new portals
  3. Entitlements and intents
  4. Why this funding model keeps producing results
  5. Sources and further reading

Germany's Sovereign Tech Agency is investing 508,640 euros in Flatpak over two years, with the work running through the end of 2027. The money buys engineering time on the portal layer, the part of Flatpak that decides what a packaged application can reach on the host. Four new portals are planned, covering audio through PipeWire, network scope and port restrictions, VPN connection management modelled on the Android and iOS APIs, and writing assistance for spell checking and grammar. Two structural pieces come with them: entitlements for declaring static permissions, and intents for declaring the services an application offers.

The short answer

Germany's Sovereign Tech Agency is putting 508,640 euros into Flatpak over two years, with delivery running through the end of 2027. The money funds the portal layer: new portals for audio through PipeWire, network scope and port restrictions, VPN connection management modelled on the Android and iOS APIs, and writing assistance for spell checking and grammar, with password auto-fill at design stage only. Two structural pieces come alongside, entitlements for declaring static permissions and intents for declaring offered services, plus maintenance on existing portals.

508,640 eurosinvested by the Sovereign Tech Fund
End of 2027when the two year programme completes
4 portalsaudio, network, VPN and writing assistance
Answer card summarising the Sovereign Tech Agency investment in Flatpak: 508,640 euros over two years running through the end of 2027, funding four new portals for audio, network, VPN and writing assistance, plus an entitlements system for static permissions and an intents system for declared services.
The Flatpak investment, in one card. PNG

Half a million euros is not a headline number in a year of gigawatt data centre announcements. Spent on portal plumbing that nobody markets, it goes further than most of them.

Where the money goes

The grant is 508,640 euros from the Sovereign Tech Fund, spread across two years and expected to complete by the end of 2027. It is co-organised by Modal Collective, with Para-Real Ltd. as the supporting organisation, and it pays a group of named contractors who already work in the portals and GNOME space rather than a new team stood up for the occasion.

The work concentrates on portals, which is the correct place to spend money on Flatpak. A portal is the mediated interface between a packaged application and the host: the application asks, a service outside the sandbox decides, and the user sees a dialog the application cannot forge. Everything Flatpak claims about limiting what an application can reach ultimately runs through that layer.

Checklist card listing the funded Flatpak work: an audio portal covering PipeWire socket permissions and WirePlumber policy, a network portal with static permissions for specific scopes and ports, a VPN portal modelled on Android and iOS APIs, a writing assistance portal for spell checking and grammar, entitlements and intents for declaring static permissions and offered services, and maintenance of existing portals including libdex porting and integration testing.
Everything the grant covers, as scoped in the announcement. PNG

The four new portals

The audio portal is the one with the most immediate practical weight. Today an application that needs sound generally receives broad access to the PipeWire socket, which is coarse. The funded work covers socket permissions and WirePlumber policy so that access can be scoped, and adds permission management around it. If you have ever wondered why a Flatpak with microphone access is a blunter thing than a phone permission, this is the gap being closed.

The network portal introduces static permissions for specific scopes and ports. That is a meaningful shift for desktop packaging, because network access today is close to binary: the application either has it or does not. Being able to declare that an application talks to a printer on the local segment and nothing else is the kind of granularity server operators have had for years and desktop packaging has not.

The VPN portal covers system level connection management, explicitly modelled on the equivalent Android and iOS APIs. Borrowing a design that two mobile platforms have already shaken out over a decade is the sensible move here.

The writing assistance portal is the quiet one, covering spell checking and grammar correction as a mediated service. It exists because dictionaries and language tooling are large, shared and awkward to bundle per application, and because an application asking the host for a correction is a better arrangement than every sandbox shipping its own copy.

Password auto-fill is listed separately and honestly, as an architectural design phase rather than a deliverable.

Entitlements and intents

The two structural pieces matter more to packagers than any single portal.

Entitlements introduce a system for declaring static permissions against specific portals. Flatpak's current permission story is a mixture of manifest flags and runtime prompts, which works but does not compose well and is hard to reason about at review time. A declarative entitlement list is something a store, a distribution or an operator can inspect before installation rather than discovering at runtime.

Intents go the other direction: an application declares the services it offers rather than only the resources it wants. That is how you get applications cooperating through a mediated layer instead of through direct access to each other, and it is the foundation for the sort of desktop integration that currently requires poking holes in the sandbox.

Alongside both, the grant funds ordinary maintenance on existing portals, including porting to libdex and building out integration testing. Unfashionable, and the part most likely to still be paying off in 2030.

Why this funding model keeps producing results

The Sovereign Tech Agency's approach is to pay for the maintenance of infrastructure that everything else sits on, rather than for new products. It has previously funded work in the GNOME project that touched Flatpak indirectly; this grant goes straight at the portal layer.

The reason it works is unglamorous. Portals are shared plumbing: no single distribution owns them, no vendor sells them, and the people who maintain them are largely doing it alongside other work. That is the classic profile of a component that quietly decays until something breaks. Paying existing maintainers to do deferred work on code they already know is close to the highest leverage available in open source funding, and it stands in contrast to the pattern where a grant funds a parallel team whose output then lands as review load on the volunteers.

For anyone building desktop images or managing fleets, the practical takeaway is a two year horizon. Nothing changes in your Flatpak manifests this month. By the end of 2027 there should be a more structured way to declare what an application may reach, which is worth tracking now rather than reacting to later. It sits alongside the broader move of desktop applications into Flatpak packaging, including the GNOME Boxes rewrite that shipped its beta as a Flatpak.

Sources and further reading

Frequently asked questions

What is a Flatpak portal, in practical terms?

A portal is the mediated door between a packaged application and the rest of the machine. A Flatpak application does not open your file picker, your camera or your screen directly. It asks a portal, which is a service running outside the sandbox, and the portal decides what actually happens, often by showing the user a dialog that the application itself cannot fake or skip. That design is why a Flatpak can be given narrow access rather than the run of your home directory. The portals funded here extend that model to audio routing, network scope, VPN connections and writing assistance.

How much of this changes the way I package or ship applications?

Over the next two years, some of it will. The entitlements work is the piece to watch: it introduces a way to declare static permissions for specific portals, which is a more structured answer than the current mix of manifest flags and runtime prompts. Intents is the other one, letting an application declare the services it offers rather than only the resources it wants. Both are additions rather than replacements, so existing manifests keep working, but if you maintain a Flatpak it is worth following the portal repositories rather than discovering the new declarations at the end of 2027.

Who is actually doing the work?

The project is co-organised by Modal Collective with Para-Real Ltd. as the supporting organisation, and the funding pays a set of named contractors drawn largely from the existing GNOME and portals community rather than a new team assembled for the grant. That matters for the outcome. Money aimed at infrastructure works best when it pays people who already know the code and already carry the review load, and the alternative, funding a parallel team that has to be reviewed by volunteers, usually adds work rather than removing it.

What is the Sovereign Tech Agency and where does the money come from?

The Sovereign Tech Agency is a German public body that invests in the maintenance of open source infrastructure that public and private systems depend on, through its Sovereign Tech Fund. The model is deliberately unglamorous: rather than funding new products, it pays for maintenance, hardening and long deferred work on components that already sit underneath everything. It has previously invested in the GNOME project, and some of that earlier work touched Flatpak. This grant is a direct one, aimed at the portal layer.

Is the password auto-fill portal actually being built?

Not yet, and the announcement is careful about the distinction. Password auto-fill is described as an architectural design phase rather than a deliverable, meaning the funded work is to explore whether a portal is the right shape for it and what that portal would look like. The other four portals, audio, network, VPN and writing assistance, are scoped as work to be developed. Treating a design exploration as a shipped feature is the standard way roadmaps get misread, so it is worth keeping the two apart when you plan around this.