CKAN is open-source software for building and running a data portal — a public, searchable catalog where an organization publishes datasets with structured metadata, downloadable resources, and a query-ready API. Originating at the Open Knowledge Foundation and released under the GNU Affero General Public License (AGPL v3.0), it is the software layer behind a number of well-known government open-data portals, including the United States’ catalog.data.gov, the Government of Canada’s open.canada.ca/data, and the UN OCHA-run Humanitarian Data Exchange. It is also used by some national and institutional research-data catalogs. This guide covers what CKAN actually is, how it differs from a hosted repository a researcher might deposit into directly, and where it fits in the broader research-data-infrastructure landscape.
What CKAN actually is
CKAN (originally an acronym for “Comprehensive Knowledge Archive Network”) is a web application, written in Python, that implements the core functions of a data catalog: dataset and resource records, organization and group structures, faceted full-text search, user and permissions management, and a full REST-style Action API for both reading and writing catalog content programmatically. It is free, open-source software licensed under AGPL v3.0, maintained by the Open Knowledge Foundation together with a global community of contributors on GitHub. Because it is source-available and self-hostable, any organization — a national government, a city, a university, a research consortium — can install, brand, and run its own CKAN instance on infrastructure it controls, rather than depositing data into infrastructure someone else operates.
Software you deploy, not a repository you deposit into
This is the operational distinction that matters most for a research administrator evaluating CKAN: it is a piece of software, not a hosted service or a single repository. A researcher does not “submit to CKAN” the way they would submit a dataset to Dryad, Figshare, or Zenodo — there is no single central CKAN instance that plays that role. Instead, an institution stands up its own CKAN deployment, configures its metadata schema, organizational structure, and access controls, and then researchers or data stewards at that institution publish into it. This is the same self-hosted-open-source-platform pattern as Dataverse in the research-repository space (see CASRAI’s Dryad vs. Dataverse comparison and Dataverse vs. Figshare comparison for the general self-hosted-vs-hosted trade-off) — except CKAN’s primary constituency has historically been government and civic open-data programs rather than academic research repositories specifically, with research-sector adoption being a secondary, smaller use case layered on top of the same software.
A practical consequence: “does CKAN have CoreTrustSeal certification” or “what is CKAN’s retention policy” are not answerable questions in the way they are for a named repository like Dryad or a national archive like DANS. Certification, retention commitments, and preservation guarantees are properties of a specific CKAN instance and the institution operating it, not of the CKAN software itself. Two government portals both built on CKAN can have completely different data-retention, licensing-default, and access-control postures depending on how their operators configured them.
Core features and architecture
A CKAN installation organizes content around a small number of core concepts:
- Datasets — the top-level catalog entry, carrying descriptive metadata (title, description, license, tags, organization, update frequency) and one or more attached resources (the actual downloadable files, or links to an external data file, API endpoint, or visualization).
- Organizations and groups — used to structure who can publish what, and to let portal visitors browse by publishing agency, department, or topic.
- Full-text and faceted search, built on Apache Solr, letting visitors filter the catalog by tag, format, organization, license, or date.
- The Action API — a JSON-based API exposing essentially every catalog operation (dataset creation, search, metadata retrieval) programmatically, which is what allows a CKAN portal’s catalog to be queried or harvested by other systems rather than only browsed by humans.
- An extension ecosystem — CKAN’s core is deliberately minimal, with most domain-specific functionality added via extensions. Two are directly relevant to interoperability:
ckanext-harvest, a common framework for pulling in (or pushing out) datasets from other catalogs on a schedule, andckanext-dcat, which exposes and consumes catalog metadata using the W3C DCAT (Data Catalog Vocabulary) RDF vocabulary — the same standard national open-data policies (including the EU’s DCAT Application Profile and the US’s Project Open Data schema) require for cross-portal metadata exchange. This is how a CKAN-based portal can be harvested into, or harvest from, another catalog without a human re-entering metadata by hand.
One thing CKAN does not do out of the box: it has no built-in curation-review workflow gating what gets published, and no bit-level digital-preservation guarantees comparable to a certified preservation repository. Those have to be layered on by whoever administers a given instance, either through internal process, custom extensions, or by treating CKAN as the public catalog/discovery layer in front of storage that is preserved elsewhere.
CKAN as part of the research-data-infrastructure landscape
Within research data management specifically, CKAN’s role is usually as a catalog and discovery layer rather than a certified preservation repository in the sense CASRAI’s repository guides use the term. A useful way to place it: CASRAI’s own comparison of a data catalog vs. a data dictionary describes a catalog as an inventory of what datasets exist and where — that is precisely CKAN’s core function, extended with an open API and a harvesting layer so the inventory can be machine-read at scale. It is well suited to publishing structured, discoverable metadata about many datasets across many contributing organizations, which is exactly the government open-data use case it was originally built for, and exactly why some national research-data portals and open-government-adjacent research catalogs use it as their public-facing layer.
It is less well suited to, and does not by itself provide, the things a discipline-specific or generalist research repository is usually chosen for: DOI minting through a registration agency such as DataCite, formal curation review of deposited data, long-term bit preservation commitments, or repository-level trust certification such as CoreTrustSeal. A research data infrastructure built around CKAN typically pairs it with, rather than substitutes for, that kind of repository — using CKAN as the searchable public catalog and cross-portal metadata-exchange point, while the underlying data files and their preservation commitments live in a dedicated repository. See CASRAI’s guide to data curation tools for how CKAN sits alongside tools like OpenRefine and the Data Curation Network in a typical RDM workflow, and CASRAI’s guide on choosing a metadata schema for a dataset for how a portal’s schema choice (Dublin Core, DCAT, DataCite, or a locally extended schema) affects what a CKAN instance can expose to harvesters.
Default dataset licensing on a CKAN instance commonly draws from open-data-friendly licenses such as the Open Database License (ODbL) or a Creative Commons license, reflecting CKAN’s open-government-data origins — though, as above, the actual license options offered are configured per instance, not fixed by the software.
Should a research institution deploy its own CKAN instance?
The honest trade-off is the same one that applies to any self-hosted open-source platform versus a hosted commercial or non-profit service: deploying CKAN gives an institution full control over branding, metadata schema, access policy, and long-term hosting costs, but it also means the institution takes on the ongoing engineering, security-patching, and Solr/PostgreSQL infrastructure maintenance that a hosted repository vendor would otherwise absorb. For an institution that already runs (or wants to run) a public, cross-departmental open-data catalog — a university publishing datasets from many departments and research groups under one discoverable index, or a government research funder cataloging outputs across grantee institutions — CKAN is a proven, widely deployed option built specifically for that catalog role. For an individual research group or a single lab that simply needs to deposit a dataset and get a citable DOI, a hosted repository such as Dryad, Figshare, or an institutional Dataverse instance is very likely the simpler and more appropriate choice; those platforms exist precisely to remove the self-hosting burden CKAN otherwise requires.
Frequently asked questions
Is CKAN free to use?
The CKAN software itself is free and open source (AGPL v3.0) — there is no license fee to install and run it. An institution still bears the cost of hosting infrastructure and the staff time to install, configure, and maintain an instance, whether done in-house or through a third-party CKAN hosting/support vendor.
Is CKAN a data repository?
Not in the sense CASRAI uses the term for certified, DOI-issuing preservation repositories like Dryad or Dataverse. CKAN is data catalog/portal software: it is very good at making datasets discoverable and machine-readable across an organization or a network of contributing organizations, but curation review, DOI minting, and preservation guarantees are not built in — they depend on what the operating institution layers on top, or on pairing CKAN with a separate repository for the underlying files.
What is the difference between CKAN and a platform like Dataverse?
Both are open-source and self-hostable, but they were built for different primary jobs: Dataverse was built specifically as a research-dataset repository, with DOI minting, dataset versioning, and citation metadata as core features from the start. CKAN was built as general-purpose data-portal/catalog software, first for government open-data programs, with dataset cataloging and cross-portal metadata harvesting (via DCAT) as its core strength. See CASRAI’s Dryad vs. Dataverse comparison for how a purpose-built research repository like Dataverse compares to a curated hosted option.
Does CKAN support DCAT and metadata harvesting?
Yes, via the ckanext-dcat extension, which lets a CKAN instance expose its catalog as DCAT-compliant RDF and consume DCAT metadata from other catalogs, and the ckanext-harvest extension, which provides the scheduling framework for pulling datasets in from external sources on an ongoing basis. This is the mechanism that lets government open-data policies requiring DCAT-based metadata exchange (such as the EU’s DCAT Application Profile and the US Project Open Data schema) actually interoperate across CKAN-based portals.
Who maintains CKAN?
CKAN originated at, and continues to be maintained by, the Open Knowledge Foundation, together with an open community of contributors who develop the core software and its extensions in public on GitHub.
