Lessons learned extending carbon.txt to support the Blue Angel

Earlier in 2026, at the Green Web Foundation we began investigating how we might expand support in carbon.txt to work with various sustainability labels. One of the more promising ones that caught our eye was Germany’s Blue Angel for Software – the first ever sustainability for label for software. In this post Director of Technology and Policy Chris Adams shares some of the key findings, and thoughts on where web-first, certification of digital products and services might go in future.

Starting out – what is the Blue Angel label in the first place?

Since the late 1970’s, the German government has funded the existence of an ecolabel called the Blue Angel label, used to identify environmentally friendly goods and services.

The Blue Angel label now covers more than 70,000 products, across different more than 100 types of product, from more than 1800 companies.

Relatively recently, two new extensions of the scheme, to cover datacentres and software were developed – the Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215) and the Blue Angel for Data Centres (DE-UZ 228). The second of these, the more datacentre focussed label was itself a consolidation of two prior schemes, the Blue Angel for “Energy Efficient Data Centre Operation” (DE-UZ-161) from 2012, and the Blue Angel for “Climate Friendly Colocation Data Centers” (DE-UZ214) from 2020.

Our focus for carbon.txt has been supporting these two, relatively new schemes – Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215), and Blue Angel for Datacentres (DE-UZ 228), and to do this, we need to understand what claims each label makes about products or services that are awarded the labels.

Understanding Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215)

The first label scheme is specifically aimed at identifying software that demonstrates characteristics we might associate with environmentally friendliness. While the full DE-UZ 215 critieria document is very detailed, for the purposes of this post, you can think of there being about three high level sets of claims – that it is energy and data efficient, it is backwards compatible with guaranteed updates, and it is free of advertising and tracking.

To earn this label, these properties need to be demonstrated in working software under conditions representative of real world use. In addition, the steps taken to test the software, as well as how much energy and data it uses to carry out common tasks need to be published. The software also needs to maintain or improve this recorded efficiency over the life time of the label being issued. The label can be issued to open source software as well as proprietary software, and the Blue Angel website lists which products are available.

Here’s how the site looks today:

Understanding Blue Angel for Data Centres (DE-UZ-228)

While the DE-UZ 215 label above covers software, it does not directly refer to datacentres where software is often run, nor the measures that datacentre operators can take to make them more environmentally friendly. Here the Blue Angel For Data Centres (DE-UZ-228) applies.

With this label is about three main sets of claims for the datacentres – that they are energy efficient, that they save resources, and they have transparent interfaces.

To earn this label, datacentres need to undergo an audit, which includes agreeing to publishing certain standardised metrics related to energy use, water use, and describe how the datacentre operates under real world conditions.

Like the software that earns the label, the datacentres are listed on the Blue Angel website, and the full extensive documentation of the assessment critieria is online too.

Identifying where to support these labels with carbon.txt

Our vision of carbon.txt at the Green Web Foundation is about two key ideas:

1. Machine-readable discovery of sustainability data and claims
2. Access to underlying data for independent validation and verification

On the face of it, these are good fits for the two Blue Angel label schemes because they both rely on publishing at least some data that actively demonstrates the underlying claims.

For datacentres, it’s about publishing numbers that represent real world performance, rather than an idealised perfect world scenario.

For software, how the software is tested, as well as what the software does is published – this means it’s possible to independently verify it, and monitor it.

Why would this be helpful for the label?

This is all well and good, but why would carbon.txt actually be useful for the Blue Angel in the first place? What benefits would this deliver to make it worth adopting? We identified 4 ways we thought it might help:

1. Increase the reach of the label – We thought this would make referring to the label in third-party sites and services easier, increasing its reach. Just like how domains and providers with carbon.txt files look different in our own Green Web Directory, and Green Web checks, other software consuming them could do the same.
2. Increase the trust over the lifetime of the label award – by linking out to demonstrations of the behaviour that earned the product the label in the first place.
3. Increase visibility of compliance with label criteria – by making continuous monitoring possible. We could automate the validation and verification steps of behaviour laid out as conditions of being awarded the Blue Angel label, so it can be run on a schedule, and with notifications sent to staff when conditions are no longer met.
4. Increased successful submissions for the label – there is a dedicated role for auditors of the Blue Angel labelling schemes, and while some of these steps have to be carried out manually, some can be automated. The same automated validators that confirm compliance above, could also be used to surface conformance issues early before external review, like a “pre-flight check” before submission.

For space reasons in this post, we’ll cover the just the DE-UTZ-215 label that covers software in more detail, to give an idea of how we thought it might work when investigating. We’ll conclude with a few notes about the DE-UTZ-228 label for datacentres when concluding.

What support for a Blue Angel for Software might look like with carbon.txt

To start off with, one reason we were looking into DE-UTZ-215 Blue Angel for Software label in the first place was how we saw it being used at a conference in late 2025 called Ecocompute.

The claim

There we saw the CEO of NextCloud – a company making a open source office product with the same name – talking about the “Green Gates” they had introduced into the way they build digital products, after earning the Blue Angel label. In the presentation, the speaker spoke about how the Blue Angel label required efficiency to be maintained or improved over the lifecycle of the product. The whole deck is online, but this pic should give an idea of what it looked like:

The independent verification

When looking through the published testing documentation for the software products awarded the Blue Angel, we found that five of the six products awarded the label were set up with tests that:

1. Are expressed as code
2. Can be run on an automated basis
3. Are run regularly as part of a continuous integration suite
4. Are run using freely available open source software – the Green Metrics tool from Green Coding Solutions

Of these five awarded products, four are open source products. It’s common for open source projects to also have the results of the testing runs in the public domain. If you know where to look, you can find them to independently verify what a CEO is showing off on stage, long after the conference is over.

For Nextcloud, the software is open source, so you can see their source code repository if you want – but these efficiency checks are run in a different source code repository

Why is this interesting? It means you can see these test results yourself, and you can independently verify that the product really is keeping to its efficiency goals, and keeping in that 10% threshold required by the label. You can see one of the charts below, on a site published by the makers of the open source software, Green Coding Solutions. Those who are truly committed can follow the link to the viewer page, but for the rest of us, the pic below should give you the general gist of readings being run and tracking that that they’re staying about the same:

Can we pull out just the info we need to see if the software still meets the label?

So far we’ve seen that there is information that has to be to published as a condition of getting a sustainability label, and there that it’s structured in a way that lets you build charts based on the continuous stream of test data as software is developed.

However, it’s also clear that this is a pretty intimidating interface. As an experiment, we looked into seeing if was possible to fetch just the info we need to show a simplified pass / fail check, for each of the main uses of Nextcloud.

The tests for the Nextcloud cover representative use, written in a number of usage scenario files: usage_scenario_video for video calling, usage_scenario_calendar for managing calendars, usage_scenario_text – for a notes tool and so on. We created a small program that could be run on the command line, to check this – gmt-blue-angel-utz-215-energy-checker – where we passed in the location of energy tracking repository, and it would return some simplified info as either text, or as JSON.

The code is open source so you can run it and change it yourself, but for convenience you can see the output below. When we check the same repo that was being checked yielding the intimidating charts, we get a simpler list of which scenarios are still passing, and how close they are to breaching their allowed 10% efficiency threshold:

$ check-energy --uri https://github.com/green-coding-solutions/nextcloud-gmt


Scenario                       Baseline(Wh) Recorded(Wh)      Var  Status
--------------------------------------------------------------------
usage_scenario_video                   0.65         0.65    +0.4%    PASS
usage_scenario_calendar                0.07         0.07    -1.0%    PASS
usage_scenario_text                    0.48         0.47    -2.3%    PASS
usage_scenario_talk                    0.25         0.26    +2.2%    PASS
usage_scenario_files                   0.11         0.11    +3.4%    PASS
usage_scenario_contacts                0.07         0.06    -7.7%    PASS

All Blue Angel energy metrics within expected threshold.

In text output above, we’re running the code in a terminal, running the “check-energy” command, and telling it where to look for published results (the https://github.com/green-coding-solutions/nextcloud-gmt bit) . We can then see that every usage scenario for Nextcloud is passing, and is well within the 10% threshold. We can actually see here that for the contacts lookup scenario, it’s improved by about 7.7%. Not bad!

What does this tell us so far?

One of the key lessons learned here is that where you have:

1. Testing for sustainability labels like the Blue Angel for Software,
2. A requirement to publish the information about how it was tested,
3. Open source testing tooling or (at least available to run with open interfaces),

…then it becomes possible to independently verify claims about a product, and do so on a schedule, whenever code changes.

This means we can move from certification for products based on annual testing to one based on continuous validation all through the year.

This won’t be able to independently verify everything about a piece of software that earned it a sustainability label, and this was an experiment mainly concerned with starting out with a single metric to track, but hopefully it gives an idea that continuous validation is possible, as long as you know data is being published.

An example of supporting Blue Angel for Software in carbon.txt

Earlier this month we started a consultation about adding support for certification schemes in carbon.txt.

Hopefully the code snippet below gives idea of what support for Blue Angel in carbon.txt might look like, to make it possible to discover when software products from an organisation have met certification standards, and then how to independently verify the claims.

Following the proposed syntax in the post we might have something like this in a file:

version="0.6"
last_updated=2026-06-27

[org]
certification_schemes = [
   {
    name="blue-angel-de-utz-215",
    url="https://www.blauer-engel.de/en/productworld/software"
   }
]

disclosures = [
   {
    doc_type="web-page",
    url="https://www.blauer-engel.de/en/products/nextcloud-server",
    title="Blue Angel label award for Nextcloud Server" ,
    certification_scheme="blue-angel-de-utz-215"
   },
   {
    doc_type="measurement-data",
    url="https://github.com/green-coding-solutions/nextcloud-gmt",
    title="Blue Angel label energy efficiency verification",
    certification_scheme="blue-angel-de-utz-215"
   },
]

See that second measurement-data disclosure in the code snippet? That is the same link as used in the simple energy checking script mentioned earlier in this post, that downloads data about the latest test runs and then shows you something easier to understand, like whether they’re still meeting the Blue Angel criteria or not.

Discovering carbon.txt files, and independently verifying on-demand

Little programmes like this are precisely the kind of software you could use to add new checking behaviour as a plugin to the existing open source carbon.txt validator we released last year. We make this validator available for anyone to download and run on their own computers and infrastructure, and this validator is what powers our new carbon.txt API.

The idea behind building plugins like this would be that so, you can use our API for convenience, to check any software mentioned in a carbon.txt file as a one off, or you could run this yourself to carry out checks like this on a schedule – moving from checking if software is still meeting the criteria once a year, to being able to check on a daily basis if need be.

However, we’re sharing this post before building too much more of this kind of functionality, because while we think this is an exciting idea, we’re not sure if it’s just us excited about it.

There are currently a relatively small number of software products that carry the Blue Angel label. We think this kind of discovery and continual validation would be useful addition to software certification schemes, but we’re not sure where the demand is. We want to test the waters before building too much.

So if this does seem interesting to you, we’d love to hear from you – let us know if this is a useful direction for carbon.txt, and if this makes certification schemes like the Blue Angel label more compelling to you.

Onwards!