opendata.cern.ch: the content repository behind CERN's open data portal

A content repository, not a portal

The About section makes a distinction that is easy to skim past. This repository is part of the CERN Open Data portal, and it hosts the source versions of the content, notably the data records and the associated documentation pages. The infrastructure code of the portal is living in a separate repository, cernopendata-portal, and the portal itself is built upon the Invenio digital repository framework. So the three pieces are distinct. The content, which is what this repository holds, is the part that changes when a dataset is published or a documentation page is edited. The infrastructure, which is the application that serves it, lives elsewhere. And the framework underneath, Invenio, is what turns that content into a searchable repository. For an adopter this matters, because the thing you would clone is not a running portal, it is the editorial half of one.

Why the split exists and what it costs you locally

The split is visible in the smallest file in the repository. The docker-compose.yml is five lines long, and it does nothing but include other files:

include:
  - path:
      - ../cernopendata-portal/docker-compose.yml
      - docker-compose-override.yml

The first included file lives in the sibling repository, with the path going up one level, and the second is the local override that sits in this repository. That is a compact statement of the whole architecture. The compose stack is defined by the infrastructure repository, and this repository only adds its own overrides on top, so a developer working on the portal needs both checkouts side by side. The data directory in this repository holds the records, and the .inveniorc file at the root is the Invenio configuration that points the application at them. The topic tags on the repository say the same thing in shorthand, with digital library, digital repository, research data management, open research data, big data, json schema, Flask and Invenio among them.

Running a local instance for your own changes

The Developing section is short and points at a document rather than repeating itself. If you want to install a local site of the CERN Open Data portal for personal development, the README sends you to the developing guide, DEVELOPING.rst, for more information, and the contributing guide is pointed at the same way. The shape of the workflow follows from the structure above. The stack comes from the compose files, the records come from the data directory in this checkout, and the Invenio configuration ties them together. The repository also carries a run-tests.sh script at the root, which is the entry point for the test suite, alongside the scripts directory. Nothing about the process is hidden in the README, which is a sign of a project whose contributors are expected to read the guides rather than guess, and the CI badge at the top of the README points at the GitHub Actions workflow that runs those checks on every push.

Records, documentation pages and the data directory

The content itself is the interesting part of the repository, and it is the part that is hardest to reproduce elsewhere. The data directory holds the source of the data records, and each record is accompanied by a documentation page, which is the combination that makes a research data portal usable rather than a file dump. The topic tags mention json schema, which is how these repositories describe the structure of a record so that a machine can check it, and the record plus its documentation is the unit that a depositor cares about. A schema check is what lets a portal reject a malformed record at submission time instead of discovering the problem years later, and the presence of a schema in the tag list is a reasonable signal that the records here are described rather than merely stored.

The repository's own configuration files

The top level of the tree is mostly tooling, and reading it tells you what the project expects of a contributor. There is a .commitlintrc.yaml for commit message rules, an .editorconfig, a .flake8 for Python linting, a .markdownlint.yaml for the documentation files, and a .yamllint.yaml for the YAML. The docker-compose-override.yml and .dockerignore belong to the local stack, babel.ini configures translations, and .inveniorc is the Invenio configuration. Then there is the documentation set, with README.rst itself, DEVELOPING.rst, CONTRIBUTING.rst, CHANGES.rst and AUTHORS.rst, which the README points at for the contributing process and the alphabetical list of contributors. A .github directory holds the workflows, and a scripts directory holds the helper scripts the root level run-tests.sh calls into. The mix of a changelog file, a commit message convention and four separate linters is a shape you see in a repository that takes review seriously, and the CHANGES.rst file is the version history to read before you plan an upgrade.

Where the community asks questions

The Support section lists two places to go, and both are institutional rather than a generic issue tracker. You can ask questions at the Open Data forum, which lives at opendata-forum.cern.ch, or get in touch through the Mattermost chat room that CERN runs for the project, in the town-square channel of the opendata team. The Contributing section is brief, saying that bug reports, feature requests and contributions are encouraged and welcome, and pointing at the contributing guide in CONTRIBUTING.rst. Together those three documents, the developing guide, the contributing guide and the forum, are the whole onboarding story for a new contributor, and the AUTHORS.rst file is the list of everyone who has been added to it.

Licence, releases and what you are actually adopting

The licence is the GNU General Public License, with the text in the LICENSE file at the root and a GPL 2 badge in the README, and for an institutional data portal that is the expected and appropriate choice, since the content includes research data that others are expected to build on under the same terms. On the state of the repository, the last push was on 2026-10-05, the repository is not archived, and it publishes no GitHub releases, so the CHANGES.rst file is the version history you have to work from. What you would adopt here, in short, is the editorial layer of a research data portal built on Invenio, together with the conventions that come with it, and the honest way to evaluate it is to read the records in the data directory and the documentation in DEVELOPING.rst, since the code itself is the least interesting part of what CERN publishes here.

Editorial conclusion

opendata.cern.ch fits an institution running a research data portal on the Invenio framework, because it is the working arrangement CERN itself uses, with the records under version control and the deployment code kept apart. It is the wrong choice if you want a ready made data portal you can install, since this repository carries content rather than a product, and it is a poor fit for a solo project, because the local setup expects the sibling infrastructure repository to be present next to it. Before you start, read DEVELOPING.rst and clone cernopendata-portal alongside this one, and check the CHANGES.rst file, since the repository publishes no GitHub releases and the changelog is the only version history on offer.

Frequently asked questions

Official sources

1. cernopendata/opendata.cern.ch on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README