cncf/landscape: the data repository behind landscape.cncf.io

What cncf/landscape actually is, and what it is not

The README opens by describing the landscape as "a map through the previously uncharted terrain of cloud native technologies". That map is the website at landscape.cncf.io. This repository is not the map. It is the raw material: landscape.yml, the hosted_logos directory, a docs folder, and an out directory. The README states plainly that the software generating the site lives in cncf/landscape2, and directs readers there for how it works. So if you arrived expecting a static site generator, a build script or a local preview server, the repository layout will disappoint you. There is no package manifest at the top level, no Makefile, no CI workflow visible in the top-level entries other than .github.

The audience is narrower than the repository name suggests. It is for people who want a project or product to appear in a specific box on landscape.cncf.io, and for people who spot an error in an existing box and want it fixed. The README frames both cases as pull requests against landscape.yml. Everyone else, meaning anyone who wants to query the landscape, embed it, or fork the taxonomy, is working against a data file whose schema is documented in another repository entirely.

How landscape.yml, hosted_logos and Crunchbase combine into one page

The data flow is described in fragments rather than in one place. Entries live in landscape.yml, added in alphabetical order. Each entry references a logo file, and that file must sit in the hosted_logos directory in SVG format, referenced from the logo field. The README also explains that some information shown in the landscape is pulled from Crunchbase or GitHub at generation time, which is why it tells you that errors in that data should be fixed at the source rather than in the YAML. That is an important architectural detail: landscape.yml is not the single source of truth for everything rendered on the page. Stars, funding, first and last commit dates, contributor counts and headquarters location come from those external services, and a pull request editing them here would be the wrong fix.

Each entry can also carry an extra section. The README points to the Extra Fields Documentation in cncf/landscape2 for the full list rather than enumerating fields here. One field it does document is tag, which records which Technical Advisory Group owns a project. The accepted values are app-delivery, contributor-strategy, environmental-sustainability, network, observability, runtime, security and storage. When tag is absent, the generator falls back to a mapping between categories and TAGs defined in a settings file in cncf/landscape2-sites. The README admits that fallback "may not be accurate in some cases" and recommends setting the TAG manually. That is a candid admission that the automatic path is a heuristic, and it is the kind of thing worth knowing before you file a correction about a mislabelled project.

Adding an entry to landscape.yml: a first pull request

The README gives the workflow in one sentence: open a pull request to add the entry in alphabetical order to landscape.yml, put the logo in hosted_logos as SVG, and reference it from the logo field. There is no install step, because there is nothing to install. The README names the fields involved rather than printing an example, so what follows is a description of the change rather than a snippet to copy.

The README says the entry goes into landscape.yml in alphabetical order. It names the logo field, which must reference a file you add to the hosted_logos directory in SVG format. It also names the Crunchbase organization, and states that it should be the company or organization that controls the software, normally the owner of the trademark. Those are the fields the README documents for a new entry; the full list of additional fields lives in the Extra Fields Documentation in cncf/landscape2, which this README links to instead of reproducing.

If you know which TAG owns the project, the README says to set the tag field in the extra item's section. The accepted values it lists are app-delivery, contributor-strategy, environmental-sustainability, network, observability, runtime, security and storage. It recommends this manual route over the automatic detection, which it says "may not be accurate in some cases".

The README notes that the landscape is generated daily, so once a pull request is merged the change should be visible before 24 hours have passed. That is the only timing guarantee the documentation offers. It does not describe a preview build, a validation command, or a way to render your entry locally before submitting. Reviewers are reading the YAML diff.

The submission rules that send pull requests back

The guidelines are stricter than a casual reading of "open a pull request" suggests, and they are where most of the friction lives. Projects with at least 300 GitHub stars that clearly fit an existing category are generally included, and the instruction is to put the project in the single category where it best fits. The README gives its reason: allowing the same product in multiple boxes would multiply the over one thousand logos on the landscape many times over. New categories are unlikely to be created, because the maintainers prefer to find the best home among current options.

Commercial versions of open source software are generally excluded, with one stated exception: all Certified Kubernetes implementations are shown. Closed source products must link to a clear description, and stealth mode companies are out. The logo rules are the most mechanical and the most likely to block a merge. Logos must include the company, product or project name in English, though additional languages are fine. Reversed logos, meaning those with a non-white and non-transparent background colour, are not accepted. When multiple variants exist, use the stacked version rather than the horizontal one. Each of those is a concrete rejection criterion, and none of them is about the quality of your software.

The most consequential rule for large vendors is the one-product-one-box policy. A company gets one box to represent its major or best-known offering, with occasional exceptions for large companies. If your organization ships several distinct products, the landscape will not represent them the way your marketing site does.

Where the Apache-2.0 licence stops

The repository is Apache-2.0, but the generated landscape is not uniformly so, and the README is explicit about the split. Data received from Crunchbase is not licensed under Apache-2.0. It is subject to Crunchbase's Data Access Terms and, per the README, is only permitted to be used with Linux Foundation landscape projects. That is a real restriction on reuse, not a formality. If you were planning to extract the landscape data to build an internal catalogue or a competing directory, the Crunchbase-derived portion is the part to examine first.

Everything else is Apache-2.0, with one carve-out: project and product logos are generally copyrighted by the company that created them and are cached here for reliability rather than relicensed. The generated landscape and landscape.yml are alternatively available under Creative Commons Attribution 4.0. That dual availability is useful for anyone republishing the taxonomy with attribution. None of this is legal advice, and the practical step is to read the Crunchbase Data Access Terms directly before building anything commercial on top of the data.

Maintenance cost and the absence of a release process

The last push to the repository was on 2026-09-21, and the repository is not archived. There are no retrieved releases, which fits the shape of the project: it is a data repository, so versioned releases are not the delivery mechanism. What you depend on instead is the daily generation cycle that the README describes, plus the schema defined in cncf/landscape2 and the TAG mapping in cncf/landscape2-sites. Those are separate repositories, and changes there can affect how your entry renders without any commit to this one. That is the upgrade cost in practice: you do not pin a version, you track a moving data file and a generator you do not control.

For a contributor, the maintenance burden is low. Once an entry is merged, the only ongoing work is keeping the Crunchbase organization and the GitHub repository correct, and correcting the tag if the automatic mapping guessed wrong. For anyone consuming the repository as a dataset, the burden is higher, because the file's meaning depends on documentation hosted elsewhere and on external APIs that the README does not describe in detail.

Alternatives, and why the difference matters

The obvious alternative is cncf/landscape2, the generator. The split is deliberate: landscape2 is the software, this repository is the input. If you want to produce your own landscape with a different set of entries, you take landscape2 and write your own YAML and logos. What you lose by staying with cncf/landscape is any control over the taxonomy, the categories and the inclusion rules, all of which are governed here by the guidelines rather than by configuration.

A second alternative is to skip the landscape entirely and maintain your own list of cloud native projects. That gives you full control over categorisation and over how many boxes a single vendor occupies. The trade-off is that you inherit the editorial work the README describes: deciding what counts as cloud native, resolving duplicate listings, and curating logos. The landscape's value is that this work is already done and the result is published daily at a stable URL. Its limitation is that the same editorial decisions are not yours to make.

Editorial conclusion

Adopt this repository only if your goal is to get a project or product listed on landscape.cncf.io, or to correct an existing entry. It is not a library, not a CLI and not something you install to build your own map: the README points to cncf/landscape2 for the generator, and this repository is the input to it. If you maintain a cloud native project with at least 300 GitHub stars and an existing category that fits, open a pull request against landscape.yml in alphabetical order, add an SVG to hosted_logos, and set the logo field. If you want to reuse the data commercially, read the Crunchbase terms first, because the Apache-2.0 licence does not cover that portion. Verify before submitting that your logo is stacked, includes the English name, and has no reversed background, since those are the checks most likely to send a pull request back.

Frequently asked questions

Official sources

1. cncf/landscape on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README