All about carbon.txt

A carbon.txt is the file served at /carbon.txt on your domain — a known location where third parties (auditors, customers, procurement teams) look when they want to see your environmental disclosures and the upstream services your site depends on. Create one in Core, then attach it to as many domain routers as you like.

Wondering what carbon.txt is for and how it works? This article explains why carbon.txt exists, what each field does, how it attaches to domain routers, and the per-cluster default that's applied to new domain routers automatically.

The format itself is defined by carbontxt.org.

Why carbon.txt is a good idea

Sustainability data tends to be scattered — an annual report PDF, a separate sustainability page, an ISO certificate from an auditor, a CSRD filing, an AI model card. Anyone trying to find or verify it — a procurement team running a supply-chain audit, a researcher comparing providers, an automated aggregator pulling data across companies — has to track down each document by hand.

carbon.txt fixes this with one machine-readable file at a known location: https://yourdomain.com/carbon.txt. The file does two things:

Disclosures — pointers to your sustainability documents (annual reports, sustainability pages, CSRD filings, ISO certificates, AI model cards).
Upstream services — the third-party services your site depends on (CDN, hosting, AI providers), so readers can see your supply chain.

The format is designed for automated tooling: aggregators and supply-chain scanners can pull disclosures from many domains without manual searching. Regulations like the EU's Corporate Sustainability Reporting Directive (CSRD) are pushing more organisations to publish sustainability data; carbon.txt is one way to make that data discoverable.

Set once, apply to many

The usual way to publish a carbon.txt is to put a text file at the root of every site you operate — one copy per document root. When a report is replaced, a certificate expires, or you switch CDN, you have to touch every site again. Miss one and that file goes stale.

In Core, you create the carbon.txt once and attach it to as many domain routers as you like. Update the carbon.txt and every attached domain serves the new file immediately. There's nothing on disk — Cyberfusion serves carbon.txt dynamically based on the carbon.txt attached to the domain router handling the request.

You can also mark one carbon.txt per cluster as the default. Every new domain router on that cluster is attached to it automatically.

Where to find carbon.txts

In Core, the top-level 'Carbon.txts' page lists every carbon.txt across your clusters. Each row shows:

'Name' — the label you gave the carbon.txt (Core-internal, not visible to auditors).
'Disclosures' — number of disclosures on the carbon.txt.
'Upstream Services' — number of upstream services on the carbon.txt.
'Used by' — how many domain routers reference this carbon.txt. Hover for the full domain list.
'Default' — whether this carbon.txt is the cluster's default.
'Cluster' — which cluster the carbon.txt belongs to.

Click 'Create Carbon.txt' to open the create form.

Per-carbon.txt fields

Name

A short label (up to 32 characters, letters, digits, dashes, underscores, spaces) used to pick the carbon.txt in lists inside Core. Not part of the served file — auditors never see it.

Default for cluster

Toggle on to make this carbon.txt the cluster's default. New domain routers on this cluster will then have it attached automatically when they're created.

Only one carbon.txt per cluster can be the default. If the cluster already has a default, the toggle is locked and a link to the existing default is shown — turn the toggle off on the current default first, then on for the new one.

Disclosures

Public documents that back up your sustainability claims — your annual report, a CSRD disclosure, an ISO certificate, an AI model card. Each disclosure has:

'Document Type' — one of web-page, annual-report, sustainability-page, certificate, csrd-report, ai-model-card, other.
'URL' — link to the document. Must be HTTPS.
'Valid Until' (optional) — date after which the document should be considered stale. Auditors use this to verify the disclosure is current.
'Title' (optional) — short label shown next to the URL.

At least one document type and URL are required per disclosure.

Upstream Services

Third-party services your site depends on — typically a CDN, a hosting provider, an AI model provider. Listing them lets an auditor follow your chain of dependencies upstream and check each provider's own disclosures.

Each upstream service has:

'Domain' (optional) — the provider's domain, e.g. cyberfusion.io.
'Service Type' — one or more service types as a comma-separated list, e.g. cdn, hosting.

By default, every new carbon.txt is pre-filled with cyberfusion.io as a hosting upstream service — the cluster you're running on. Add the rest of your providers (CDN, AI, payments, mail) on top.

Attaching a carbon.txt to domain routers

On the carbon.txt's detail page, the 'Domain Routers' section lists every domain router in the same cluster, each with a toggle. Flip on the ones that should serve this carbon.txt, then click 'Save'.

For long lists, the 'Bulk select' switch at the top toggles every row on or off at once.

A row that's toggled off but shows a small link to another carbon.txt ('X is attached') means that domain router is currently using a different carbon.txt — toggling on here moves it from that one to this one.

Same cluster only

Carbon.txts and domain routers are paired per cluster. A carbon.txt in cluster A can only be attached to domain routers in cluster A. If you run multiple clusters and want the same carbon.txt everywhere, create one per cluster.

What gets served

When a visitor requests https://yourdomain.com/carbon.txt, Cyberfusion looks up the carbon.txt attached to the domain router for yourdomain.com and returns a carbontxt.org-formatted text file built from the fields you set.

If no carbon.txt is attached, no file is served — visitors get the same 404 they'd get for any other missing path.