Open data portal cost: what decides build, partner or SaaS
If your team has to publish datasets and needs a portal, the first question is what it will cost under each option. CKAN itself carries no licence fee, since it is licensed under the GNU Affero General Public License v3.0, so the real cost sits in infrastructure, implementation, ongoing support and internal staff time. How large those lines become depends on scope, where the portal is hosted, and how much your team already runs databases, search engines and web servers in production.
SaaS open data vendors publish subscription pricing, and that number is only one side of the comparison. To compare it fairly, put it next to the cost of your own cloud or data center capacity, the people who will patch and monitor the stack, and the time your publishing staff spend on metadata work that no platform does for you. Ask each SaaS vendor for the price basis in writing (per user, per dataset, per organization or per volume), the data residency terms, the export path if you leave, and what support is included. For a self-hosted build, check your own operating capacity against the components CKAN needs, such as Python 3.10 or newer, PostgreSQL 12 or newer, Solr and Redis, as listed in the CKAN installation documentation.
Building alone is usually the cheapest path only when your team already operates this kind of stack and can absorb upgrades. CKAN targets about two minor releases a year, and only the latest patch of the current minor version and the previous minor version receive security and bug fixes, so every upgrade is recurring labor. A partner tends to cost less than building alone when you lack staff with Python, PostgreSQL and search operations skills, when the portal must meet a deadline you cannot staff internally, or when you need a fixed-scope delivery with written deliverables. Confirm in any quote whether upgrades, backups, security patching and support after go-live are included or billed separately, because those recurring items often outweigh the one-time build.
Which cost components apply to each option
This table compares how each cost line lands under an in-house build, an implementation partner, and a SaaS subscription, and whether it is one-time or recurring. Read each row as a question to answer in your own quote: who carries the work, and what keeps coming back after go-live. CKAN 2.12.0 and its maintenance releases 2.11.6 and 2.10.11 were published August 26, 2026, so any version assumed in a quote should be checked against current releases.
| Cost component | In-house build | Implementation partner | SaaS subscription |
|---|---|---|---|
| Licence | CKAN is licensed under AGPL-3.0, so no per-seat fee applies, but AGPL obligations on modified code need legal review. One-time review, recurring if extensions change. | Same AGPL position. Partner fees cover the written scope, not a licence. Confirm who owns custom extensions. | Recurring subscription, typically priced by tier, users, datasets or traffic. Confirm what the price includes and what triggers overage. |
| Infrastructure | Your cloud or data center accounts. Recurring for compute, storage, backups and networking, sized to dataset volume and traffic. | Usually billed to your accounts under the same recurring model. Confirm whether the partner resells capacity or deploys into yours. | Included in the subscription, often with limits on storage, regions or data location. Recurring, and hard to move later. |
| Implementation | Internal engineers for installation, configuration, theming and DataStore setup. One-time, but it competes with other roadmap work. | Fixed-scope work agreed in writing before start. One-time, with a clear deliverable list. | Vendor onboarding and configuration services, often separate fees. Confirm which features need paid professional services. |
| Integrations and migration | Internal effort for harvesters, DCAT mapping, SSO and migration of legacy datasets. Scales with the number of source systems. | Priced by source system count, data quality and mapping depth. One-time, with re-work risk if requirements change mid-scope. | Connectors vary by vendor. Custom integrations are often quoted separately, and export of metadata may be limited. |
| Security testing and compliance evidence | Internal time for hardening, logging evidence and control documentation. Recurring testing is needed after each release. | Scoped testing and evidence preparation for an agreed assessment. One-time per cycle, with retesting as a recurring option. | Vendor security documentation and certifications are shared, but your own testing and evidence are still your cost. Confirm the audit rights. |
| Upgrades and patching | Internal staff track the CKAN minor release cycle and the latest patch of the current and previous minor versions. Recurring. | Retainer or per-release work for upgrades, testing and rollback plans. Recurring, sized to the agreed support scope. | Vendor applies upgrades on its schedule. Recurring cost is included, but timing and breaking changes are set by the vendor. |
| Support and operations | On-call, monitoring, backup restores and incident response in your own team. Recurring, often the largest hidden line. | Support retainer with defined response terms. Recurring, and terms should be written into the contract. | Vendor support tiers apply. Recurring, but service levels and data recovery terms vary by plan. |
| Internal staff time | Product owner, data stewards, platform engineers and security reviewers. Recurring for publishing workflows and governance. | Smaller internal oversight role, plus time for acceptance testing and data publishing. Recurring but lighter. | Business owners and stewards still publish and curate. Recurring, and the vendor roadmap shapes your change effort. |
Which drivers move each cost line
A self-hosted CKAN portal has few fixed costs. Most of the spend moves with the size of the catalog, the data services you run, the standards you must publish, the identity and accessibility scope, and where and how often you upgrade. Each driver below names the cost line it moves so you can ask a partner or your own team for the right numbers.
Dataset count and file size
The number and size of datasets and resources drive the storage, backup and harvesting work, and the time needed to migrate and check metadata at launch. A catalog of a few hundred well-described datasets and one with tens of thousands of files, each with its own update schedule, call for very different hosting and staff time. Ask for a written inventory of datasets, resource formats and expected growth per year before any quote. Storage and backup costs recur, while the one-time migration and cleanup effort does not.
DataStore and large time series
Loading tabular resources into the CKAN DataStore adds a separate PostgreSQL database, a loader service and query capacity for the Data API. XLoader is the officially supported loader, so budget for it and not the legacy DataPusher. Large time series, such as meter readings or sensor feeds, raise database size, indexing work and monitoring effort. Ask whether the scope includes DataStore load testing and how read and write users are provisioned.
Metadata profiles and DCAT-AP
Publishing to national or European catalogs means mapping CKAN fields to a DCAT profile, exposing RDF endpoints and validating output. The ckanext-dcat extension covers DCAT-AP v1, v2 and v3, but each national profile adds mapping rules, test cases and review by the catalog operator. This work is mostly one-time design and testing, with recurring effort each time the target profile changes. Ask which profile version your exchange partners use and who signs off on validation.
Identity integration with SAML
Staff logins through a corporate identity provider need a SAML integration, usually with the ckanext-saml2auth extension, plus role mapping for publishers and administrators. Identity work is a one-time build with recurring support whenever the identity provider changes certificates, claims or group names. Costs rise sharply if the portal must also serve external contributors through separate accounts. Confirm the identity provider, the attribute set it sends, and who owns the certificate renewal process.
Accessibility scope under ADA Title II
State and local government web content must meet WCAG 2.1 Level AA under the ADA Title II rule. The interim final rule published April 20, 2026 sets compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Accessibility testing, theme changes and remediation of custom templates are the cost lines this moves. Ask whether the quote covers an audit of the templates you customize and how retesting after each upgrade is handled.
Hosting location and upgrade cadence
Hosting inside government or regulated infrastructure, and the choice of cloud region or data center, sets the infrastructure and operations cost. CKAN targets about two minor releases a year, and patch releases do not add features, so each upgrade is a recurring cost line. Outdated patch releases lose support once a newer patch is out, so plan for a regular patch window. Ask whether the support retainer covers patching, test environments and rollback, and who pays for hosting capacity.
Why CKAN's recurring operations cost outweighs its licence
CKAN carries no licence fee, so the real cost sits in keeping the platform running. The stack the install guide describes is a set of moving parts: Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. Each component has its own patch cadence, its own configuration and its own failure modes, and all of them must stay compatible with the CKAN version you run. Budget for that operating work as a standing line item, not as a one-off launch cost.
The release policy turns this into a predictable workload. CKAN targets about two minor releases a year, and the tech team supports only the latest patch of the current minor version and the previous minor version. Patch releases do not break backwards compatibility and exclude schema changes, so they can be applied with routine testing. Minor releases may include backwards-incompatible changes, so each one needs a staging upgrade, a review of extensions such as ckanext-dcat and ckanext-saml2auth, and a rehearsed rollback before production. Ask any partner or internal team to show how they track which patch is current and how quickly they plan to move when an outdated patch loses support.
Search and the DataStore add services that must stay available. Solr indexes datasets for discovery, and the DataStore runs in its own PostgreSQL database with separate write and read-only users, so backup, restore and capacity planning cover two databases plus the index. Confirm in writing who owns Solr index rebuilds, DataStore backups, XLoader job monitoring and the Redis instance, and whether the quote includes these as monitored services with an agreed response process. These duties recur for the life of the portal and usually decide whether the total cost stays close to the licence-free figure or grows well beyond it.
How to build your own cost estimate
This sequence turns a vague budget question into a side-by-side comparison of one-time build, recurring run and SaaS subscription costs for the same portal scope, over a period you choose.
Define scope and dataset inventory
Start by listing the datasets the portal will publish, the publishing organizations, and which datasets are open, restricted or not yet decided. Include the number of publishing teams and whether any data is large enough to need the CKAN DataStore for API access. Owner: the portal sponsor with the data owners from each department. Done when every dataset has a named owner, a publication status and an estimated update frequency, written down in one shared inventory that every bidder and vendor will receive.
Inventory metadata and standards needs
Record which metadata schemas your publication obligations require, such as DCAT-AP profiles, a national profile or a US DCAT-based catalog file, and whether the portal must harvest from or expose metadata to other catalogs. Confirm with your legal and records teams which fields are mandatory and how many custom fields your datasets need. Each added schema or harvester adds configuration and testing work, so this list directly affects the one-time build. Done when the metadata requirements are signed off and mapped to the dataset inventory.
List hosting and identity requirements
Document where the portal must run, including cloud account, data center or air-gapped network, plus data residency rules, backup location and the identity provider staff will use for sign-in. Note whether public users need accounts at all, since anonymous download is cheaper to operate. Ask your security team which logging, monitoring and patching evidence they will require. Done when hosting, identity and security requirements are written as a single list that determines the infrastructure line in your estimate.
Cost the one-time build
Estimate the implementation work as separate items: installation and configuration, customization, metadata mapping, harvesting, migration of existing datasets, accessibility testing, security testing, documentation and launch. For each item, record who is paid for it (your staff, a contractor or a partner) and what it depends on. Request a fixed-scope written quote from each implementation partner that lists the same items, so totals can be compared. Done when every build item has one owner and one price source, and the total is tied to the scope from the earlier steps.
Cost the recurring run
Estimate the ongoing costs: cloud or data center capacity, backups, monitoring, CKAN upgrades (minor releases can include backwards-incompatible changes, while patch releases do not), security fixes, on-call coverage, content stewardship and any retainer for support. Separate internal staff time from paid external support, and state the hours your team can realistically allocate. Done when each recurring line has an annual or monthly figure from a named source and an assumption you can defend.
Price SaaS subscriptions for the same scope
Ask SaaS open data vendors for written subscription pricing based on the same dataset count, user roles, storage, API volume, custom metadata, identity integration and hosting location you listed earlier. Note what the subscription excludes, such as migration, custom schema work, extra environments, data residency options and support tiers. Where a vendor does not publish pricing, request a quote in writing and keep the response with your file. Done when each SaaS quote covers the same scope line by line, with exclusions recorded.
Compare totals over your chosen period
Pick the number of years you want to compare, then add one-time and recurring costs for the self-hosted build, the partner-delivered build and the SaaS option over that period. Add internal staff time at an agreed internal rate, and record the cost of exit or migration if you later change platform. Present the results with the assumptions beside each total so reviewers can change one input and see the effect. Done when a single comparison sheet shows all three options on the same scope, period and assumptions.
Request written inputs from partners and vendors
Before you accept any figure, ask each partner and vendor in writing for the same inputs: the scope they priced, the platform version and edition, licence obligations, hosting model, migration assumptions, security evidence they can provide, support terms after go-live, and how change requests are priced. Ask partners to confirm that the work is fixed-scope and to state what triggers a change order. Done when every response is in writing, uses the same scope definition and answers each input, so the comparison is based on evidence rather than verbal estimates.
When a partner costs less than building alone
A team without prior CKAN operations work usually underestimates the parts of the stack that sit outside the application itself. A source install involves Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, Redis, and uWSGI and Nginx for production, and each component needs its own patching, backup and monitoring. A partner can carry the initial build and runbooks so that internal staff spend their time learning the system rather than discovering its failure modes in production.
- Installation and configuration: the partner handles the source install, service wiring and the production web stack, so internal staff are not learning uWSGI and Nginx tuning on the critical path.
- DataStore setup: the separate PostgreSQL database, its write and read-only users, and XLoader configuration are set up and tested against sample resources.
- Upgrade planning: the team learns the CKAN release policy early, including that patch releases avoid schema changes while minor releases may be backwards-incompatible.
- Runbooks and handover: documented procedures for restore, search index rebuilds and incident response are written for the team that will run the portal.
What remains with the client: ownership of the data, the publication decisions, the on-call rota and the budget for ongoing operations. Ask any partner to show the runbooks they will hand over and who is trained to run them.
An organization with a platform or DevOps team already runs databases, container hosts and identity integrations, so the main cost is not the infrastructure itself but the CKAN-specific knowledge and the time to absorb it. A partner is most useful here for the parts that are unfamiliar: CKAN extensions, DCAT metadata mapping, and the upgrade cadence. Internal staff keep control of the environment they already operate.
- Extension work: the partner can take on ckanext-dcat configuration and custom extensions, which the platform team would otherwise learn from scratch.
- Hosting integration: existing cloud accounts, network policies and backup tooling stay internal, with the partner adapting the deployment to them.
- Upgrade rehearsal: the partner can run a staging upgrade across a CKAN minor release, so the platform team sees the change before production.
- Knowledge transfer: pairing sessions and written decisions reduce the time before the internal team can handle routine changes alone.
- Limited scope: a narrow engagement covering only the CKAN-specific gaps may cost less than a full build.
What remains with the client: the infrastructure, access control, change approval and the decision to keep or reduce outside help over time. Ask what the partner will leave in version control so the platform team can operate it without the partner.
A fixed launch date or a hosting requirement, such as government infrastructure or a regulated network, changes the calculation because schedule risk and evidence requirements become the main costs. Internal teams often must also complete approvals, security reviews and staffing decisions while building, which lengthens the timeline. A partner working under a fixed scope agreed in writing can reduce that risk, but only if the scope, deliverables and acceptance criteria are defined before work starts.
- Fixed scope: DeployOpen works on fixed scope agreed in writing, so the included deliverables, timelines and exclusions are visible before commitment.
- Evidence preparation: systems, controls and records for an assessment can be prepared in parallel with the build, though auditors issue the findings.
- Hosting within your boundary: the portal is deployed in the client's own cloud accounts, data center or air-gapped network.
- Post-launch support: ongoing support, upgrades and testing can be set up as a retainer rather than an open-ended engagement.
- No published price list: a quote follows from the written scope, so comparisons should use the same scope across bids.
What remains with the client: the legal obligations, the accountable owner, accepted residual risk and the internal approvals. Ask each bidder to state its assumptions, exclusions and what happens when the scope changes.
What SaaS subscriptions include and leave out
A SaaS subscription price only becomes comparable to a self-hosted cost once you have confirmed what it includes. Before setting a subscription against the infrastructure, staff time and support you would carry yourself, ask the vendor to confirm in writing where the portal and its DataStore data are hosted, which regions and sub-processors are involved, and whether the hosting location can be fixed in the contract. For a public body or a regulated institution, the answer to data residency can decide the question before price is considered. Also ask whether the subscription covers backups, restore testing, and the security logging your compliance team will need as evidence.
Next, test the features your portal depends on rather than accepting a general feature list. Ask whether the vendor supports DCAT-AP output and RDF endpoints at the profile version your national or sector rules require, how harvesting from and to other catalogs is handled, and whether single sign-on with your identity provider is included or priced separately. Ask which extensions can be installed, whether custom code runs on the vendor's platform, and who approves changes to the platform version. A subscription that limits customization can still be the right choice, but the limits should appear in your cost model as possible future projects, not as surprises after launch.
Finally, plan for the exit before you sign. Ask what happens to your datasets, metadata, resource files, users and historical versions at contract end, in what formats they can be exported, how long the vendor keeps data after termination, and whether deletion is certified. Estimate the effort to move a portal of your size to another host, including reconciling identifiers and redirecting links, and treat that effort as a one-time cost in the comparison. Get the export format and the termination terms written into the contract, because a portal that has grown over several years is far harder to move than one that has just launched.
Questions buyers ask about open data portal cost
What drives the cost of a self-hosted open data portal?
The biggest cost drivers are the number of datasets and the formats they arrive in, how many publishing organizations feed the portal, which metadata standards you must meet, and how much integration you need with existing systems. CKAN itself is licensed under the GNU Affero General Public License v3.0, so there is no per-user or per-dataset license fee to budget for. The cost sits in four places: infrastructure in your own cloud or data center, the initial build and configuration, ongoing support and upgrades, and internal staff time for publishing and governance. Each of these moves with scope, so ask any partner to price them as separate lines.
Can our internal team run a CKAN portal without outside help?
Yes, many teams do, provided they have people who can run Python web applications, PostgreSQL, Solr, Redis and a reverse proxy in production. The installation documentation lists Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. CKAN targets about two minor releases a year, and only the latest patch of the current minor and the previous minor receive security and bug fixes, so someone must own upgrades on that cycle. Confirm your staff's skills and on-call coverage before deciding to build in-house.
How long does it take to build an open data portal?
The duration depends on how many organizations must publish, how many metadata fields you must map, whether the DataStore and Data API are in scope, and how many integrations need testing. Your team's availability for content migration and approval workflows often matters as much as technical work. No general timeline applies, so ask a partner for a phased plan with dated milestones tied to named deliverables. Ask your internal team to list its own decision points, since these tend to set the pace.
What does the work require from our own staff?
Expect demands in four areas: a product owner who approves metadata and publishing rules, technical staff who provide hosting access and identity integration, data owners who prepare and review datasets, and a person who handles operations after launch. Dataset publishing is recurring work that continues long after the platform is live. Ask any implementation partner to list these roles in the written scope and to state which tasks transfer to your team at handover. Staff time is a real cost line even when no invoice shows it.
Is a SaaS open data portal cheaper than self-hosting CKAN?
It depends on your data location rules, volume and how much control you need, so compare total cost rather than subscription fees alone. SaaS vendors publish subscription pricing, but that figure rarely includes integration, custom metadata mapping, identity setup or staff time for publishing. Self-hosting on CKAN removes per-seat fees but adds infrastructure, upgrades and support costs that you carry. Request a written three-year cost comparison from each vendor and partner, listing one-time and recurring items, and check whether data residency or air-gapped hosting is available from the SaaS option.
How is a fixed-scope quote for an open data portal defined?
A fixed-scope quote is defined by a written statement of scope, deliverables and timelines agreed before work starts. DeployOpen works this way for most engagements. Ask for the quote to name the platform version, the number of organizations and datasets in scope, the metadata standards and any DCAT profile, the integrations, testing, documentation and handover items, and what is excluded. Also ask which items recur after go-live, such as support, upgrades and security testing, and whether they are covered by a separate retainer. Price is set from that written scope, and DeployOpen does not publish a price list.
How DeployOpen scopes and delivers a fixed-scope portal
DeployOpen plans, implements, hardens and documents self-hosted CKAN portals inside your own cloud accounts, data centers or air-gapped networks. For the build, partner or SaaS decision, we set out each cost line in writing so your team can compare internal effort, infrastructure and partner scope on equal terms before any work starts.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists which cost lines we cover, such as hosting setup, CKAN installation, customization and integration.
- Scope also names what stays with your team, such as publishing staff time, data curation and licensing decisions.
How we build
- We install and configure CKAN with PostgreSQL, Solr, Redis and the DataStore inside your environment.
- We customize and integrate the portal with your identity provider, metadata standards and existing data sources.
- We test the build, harden it, and set up backups and upgrade procedures before publication.
How we hand over
- We document the architecture, configuration, runbooks and upgrade steps so your team can operate the portal.
- We prepare controls and evidence that your auditors or assessors can review, without issuing any attestation ourselves.
- We walk your team through operations and agree the handover checklist in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, priced separately from the build.
- Retainers can cover CKAN patch and minor release upgrades, so recurring cost stays predictable against your scope.
- Before you choose a retainer, ask us to confirm response terms and what the retainer excludes.
