Hub for publishing government and institutional open data on a self-hosted CKAN portal, and how open data law, metadata standards and sector change the build.
For EU public sector bodies publishing high-value datasets: the six categories, free and machine-readable publication through APIs and bulk download, CC0 or CC BY 4.0 licensing, and how a CKAN portal with the DataStore and DCAT-AP meets each requirement.
For federal agencies: the comprehensive data inventory the Act requires, publishing to the Federal data catalogue on data.gov through a DCAT-US data.json file, and running CKAN as the agency catalog that feeds it.
For portals that must exchange metadata with national and European catalogs: DCAT-AP versions and national profiles, mapping CKAN dataset fields with ckanext-dcat, RDF endpoints, harvesting from and to other catalogs and validating output.
For mapping agencies, environment departments and cities publishing spatial data: map-based dataset search, harvesting ISO 19139 metadata, CSW endpoints with pycsw, previews of GeoJSON and map services, and links to existing GIS servers.
For national ministries, regions and cities launching or replacing a data portal: publishing workflows across departments, organizations and roles, SSO for staff, accessibility, hosting within government infrastructure and support after launch.
For universities and research institutes sharing datasets: CKAN as a research data catalog, persistent identifiers and citation, access-controlled versus open datasets, metadata for funders' data sharing policies and campus SSO.
For grid operators, utilities and energy regulators publishing network, consumption and generation data: separating open from restricted data, data APIs for large time series through the DataStore, update automation and critical infrastructure security limits.
A requirements checklist for a self-hosted open data portal: functional must-haves, hosting and data residency, identity and access, privacy and retention, integrations, operations and support, so a team can compare self-hosted options before choosing a platform.
Questions to put in an RFP or vendor brief for a self-hosted open data portal: platform and edition fit, licence obligations, migration of existing data, hosting model, security evidence, support terms after go-live and how the fixed scope is defined.
Cost structure for a self-hosted open data portal: subscription pricing published by SaaS vendors against self-hosted infrastructure, implementation, support and internal staff time, which drivers move each line, and when bringing in an implementation partner costs less than building alone.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.