What does CKAN cost of ownership include when the license is free?
CKAN carries no license fee. It is licensed under the GNU Affero General Public License v3.0, so the money a self-hosted portal costs goes to infrastructure, storage and search, custom extensions and theming, upgrades, and the people who run it. Cost of ownership is the sum of those lines over the life of the portal, and the license is the one line that is zero. The useful question for a budget holder is not whether CKAN is free but how each remaining line is paid, by whom, and whether it recurs.
Four situations usually trigger a cost review. A new portal needs a one-time build plus a recurring run cost that must be funded from day one. A team moving off a hosted service replaces a subscription with cloud bills, staff time and on-call coverage, so the comparison has to include the full self-hosted cost, not just hosting. A budget renewal forces every recurring line into view. A legacy portal falling out of support is the most urgent case: CKAN supports the latest patch of the current minor version and the previous minor version, so an older portal may need an upgrade before any new feature work can be funded. Confirm the current support window in the CKAN release policy documentation before you set the schedule.
The infrastructure lines are the most concrete. A production install needs Python 3.10 or newer, PostgreSQL 12 or newer, Solr (version 9 is recommended), and Redis, with uWSGI and Nginx recommended for production. The DataStore keeps structured resource data in its own PostgreSQL database, so storage grows with the data that users upload and load, and XLoader is the supported loader for that work. Solr sizing affects both query performance and index rebuild time. Budget separate staging and backup environments, since those are often left out of early estimates. Ask any cloud provider or data center team to price each component against your own data volumes, because DeployOpen does not publish prices and no generic figure replaces your own sizing.
Extensions and upgrades are the lines most often underestimated. Each extension, such as ckanext-dcat for DCAT metadata or ckanext-saml2auth for single sign-on, is a dependency that must be tested against every CKAN upgrade. Patch releases are designed not to break backwards compatibility, but minor releases may include incompatible changes, so each minor upgrade carries a regression and extension testing effort. When you request a quote from a partner or ask internal staff to estimate, require the same breakdown: scope of the build, number of environments, hours for ongoing support, extension maintenance, upgrade cadence, backup and restore testing, and who is on call. A total without those lines cannot be compared with a hosted subscription or with another quote. DeployOpen works to fixed-scope written agreements, and ongoing support is available as a retainer, so a quote follows directly from the scope you agree in writing.
What a CKAN cost of ownership model covers
A written CKAN cost model should price each runtime component, each piece of custom work and each recurring activity separately, so the total can be traced to its assumptions. The cards below list the areas a quote should cover and the deliverable a reader should expect for each.
Application and supporting service hosting
Price the CKAN web application, Nginx and uWSGI, PostgreSQL, Solr and Redis as separate hosting lines, each with its compute, memory, storage and backup assumptions. CKAN's source install guide expects Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (or Solr 8) and Redis, so confirm which versions the quote assumes. Ask for a line-item hosting schedule with monthly and annual recurring costs.
DataStore and XLoader processing storage
The DataStore keeps structured resource data in a separate PostgreSQL database, and XLoader handles file loading, which DataPusher's legacy status makes the supported path. Storage and processing grow with the number and size of uploaded tabular resources. Ask the quote to state the assumed dataset volume, the expected growth and the compute used for loading jobs, with a recurring storage line.
Search index and cache capacity
Solr indexes datasets for search and Redis supports CKAN's runtime needs, and both need sizing as the catalog grows and traffic rises. Solr may run from a Docker image tagged for the CKAN version, which changes how it is hosted and patched. Ask for the index size assumption, the replica or failover approach and the cost of running and monitoring each service.
Custom extensions and theming
Custom extensions, schema changes and portal theming are usually the largest one-time cost after hosting. Each extension needs build, testing, documentation and a compatibility check against the CKAN minor version in use. Ask for a list of extensions with their scope, a per-extension effort estimate and whether the work includes handover to your team.
DCAT and SAML2 extension work
Where the portal must publish DCAT-AP metadata or sign users in through an identity provider, the ckanext-dcat and ckanext-saml2auth extensions are the starting points. Each needs configuration, attribute mapping, testing against your catalog or identity provider and support for the CKAN version in use. Ask for the DCAT-AP version targeted, the identity provider integration scope and any harvester work listed separately.
Publisher onboarding and support
Publishers who upload datasets need accounts, roles, guidance and a support route, and this effort recurs as new organizations join. Ask for the assumed number of publishing organizations, the onboarding materials to be produced and the expected helpdesk hours. Cost depends on how much of this your own staff absorb.
Upgrades and ongoing support
CKAN targets about two minor releases a year and supports the latest patch of the current minor version plus the previous minor version. Patch releases avoid schema changes, but minor releases may include backwards-incompatible changes that require extension and testing work. Ask for a recurring schedule covering patch application, minor upgrades, extension regression testing and the support hours and response terms in the contract.
Which factors push CKAN cost and duration up or down
This table lists the factors that most often move the price and timeline of a CKAN portal, with why each one matters and what the buyer can do to keep it manageable. Read each row as a question to answer in the scope before asking for a quote. The main takeaway is that custom code, identity and compliance evidence usually add more work than raw dataset volume.
| Driver | Why it moves cost or effort | How the buyer can reduce it |
|---|---|---|
| Number of datasets and resources | Each resource adds metadata to validate, migrate and index, and large catalogs need more search and indexing work during load and upgrades. | Agree a metadata schema and a publishing volume estimate up front, and load in phases by publisher group. |
| DataStore volume and uploaded file sizes | Larger tables and files need more PostgreSQL storage, longer XLoader jobs, backup time and disk planning for uploads. | Decide which files go into the DataStore, set upload limits and confirm storage growth with the data owners. |
| Number of publishers and organizations | Each publisher group needs roles, onboarding, training and sometimes its own review workflow, which scales with headcount rather than code. | Use a shared onboarding guide, a small set of publisher roles and a named contact per organization. |
| Custom extensions | Every custom extension is code to write, test, document and port to each new CKAN minor version, and it becomes a recurring maintenance line. | Prefer maintained extensions from the community, limit custom code to real gaps and record each extension's owner and supported versions. |
| Theming depth | A light theme reuses CKAN templates, while deep redesigns require template overrides that must be rechecked after each upgrade. | Keep the design within the standard template structure and approve a short list of page changes before build. |
| Identity integration | Connecting to an identity provider needs attribute mapping, test accounts, role rules and coordination with the identity team, as in SAML2 setups. | Confirm the identity provider, attribute names and role model before work starts, and decide early whether local registration stays on. |
| Harvesting sources | Each harvester needs source-specific mapping, scheduling, error handling and checks that harvested records match the metadata schema. | Limit the first release to the sources that matter most and document the expected source format for each one. |
| Number of environments | Development, test, staging and production each need their own installs, data copies, configuration and deployment steps, which multiply setup and upkeep. | Use one reproducible deployment method and keep only the environments the release process truly needs. |
| Compliance evidence needs | Assessors may ask for patch records, access reviews, backup restore tests and configuration baselines, which takes time to collect and keep current. | Ask early which controls and evidence formats the assessor expects, and plan evidence collection as part of routine operations. |
| CKAN minor versions behind | The portal must move across minor releases, which can include backwards-incompatible changes. Patch releases do not break compatibility, so a portal several minor versions behind needs more upgrade work and extension rework. | Stay on the latest patch of a supported minor version and plan upgrades on a regular schedule rather than in large jumps. |
How a CKAN cost model moves from scope to a signed estimate
This sequence turns a planned or existing CKAN portal into a written three-year cost view and a signed estimate that the buyer can test. Each phase produces a named artifact that the next phase depends on, so scope changes show up in cost before anything is signed.
Run discovery on infrastructure and data
The buyer's platform, data and publishing teams meet with DeployOpen to document the current catalog or planned portal. Topics include hosting location and cloud accounts, dataset and resource volumes, the number of publishing organizations, metadata standards, whether DataStore and XLoader are needed, and the sign-in model. Information comes from the people who run the infrastructure and publish the data. The output is a discovery record that separates what exists, what is planned, and what is still unknown. The step is done when the buyer confirms the record in writing.
Inventory extensions, integrations and custom code
Every installed or planned CKAN extension is listed with its version, whether it is maintained upstream, what it changes, and which CKAN minor versions it supports. Integrations such as harvesters, identity providers, DCAT endpoints and downstream reporting are recorded with their data flows and owners. Custom theming and custom code are noted separately because they usually carry the most upgrade effort. The output is an inventory that maps each item to a CKAN release line and a named owner. The step is done when the buyer confirms that no component is missing.
Size hosting, database, search and cache
Capacity is estimated for the web application, PostgreSQL (version 12 or newer), Solr (version 9 recommended, version 8 supported), Redis and the DataStore database, which is kept separate with its own read-only access path. Inputs include dataset counts, resource file sizes, DataStore volume, expected query load and backup retention. The output is a sizing sheet that states the chosen configuration for each component and the reasoning behind it. The step is done when the buyer's platform or cloud team has reviewed the sheet and raised no open questions.
Write the assumptions register
Every input the estimate depends on is written down: who operates the portal, which cloud or data center hosts it, the support hours expected, the staff who will publish datasets, the expected extension count, and the CKAN minor line being targeted. Each assumption gets an owner and a note on which costs change if it moves. The output is an assumptions register attached to the model. The step is done when the buyer has accepted or corrected every line.
Build the three-year recurring cost view
The model separates one-time work, such as discovery, build, configuration, data loading, extension changes and theming, from recurring costs. Recurring costs include hosting and storage, backups, monitoring, any vendor licenses that apply to the chosen stack, patch and upgrade work, extension maintenance and internal staff time. Upgrade windows are placed against CKAN's cadence of about two minor releases a year, and against the rule that outdated patch releases lose support once a newer patch ships, so each planned upgrade has its own line. The output is a three-year view by year and cost category, with the assumption behind each figure.
Review the model and sign the estimate
The buyer and DeployOpen walk through the model line by line, test the assumptions that drive the largest costs, and agree what is in and out of scope. Changes are recorded and the model is revised until both parties agree. DeployOpen does not publish a price list, so the estimate follows from the written scope. The output is a written, fixed-scope estimate tied to the assumptions register and signed before work begins. The step is done when both parties have signed.
Recurring costs after go-live on a self-hosted CKAN portal
This table lists the recurring cost lines a self-hosted CKAN portal carries after launch, with the driver behind each line and the points to confirm in writing. CKAN has no license fee, so recurring spend comes from hosting, database and search operations, upgrades, and staff time. Read the third column before signing a hosting or support agreement, because most gaps appear in who owns each task and how often it runs.
| Cost line | What drives it | Confirm in writing |
|---|---|---|
| Infrastructure and backups | Sizing of web, worker and database tiers; backup retention period; how often restores are tested | Hosting provider: instance and storage charges, backup retention, restore test support, and data residency |
| PostgreSQL and Solr operations | Size of the main and DataStore databases; Solr 9 or Solr 8 index size; reindex time after upgrades | Hosting provider or partner: who patches and backs up PostgreSQL 12 or newer and Solr, and who runs reindexing |
| Redis | Cache and session load as traffic grows; single instance or highly available setup | Hosting provider: whether Redis is managed, its persistence settings, and who handles failover |
| DataStore storage growth | Volume of tabular resources loaded through XLoader; retained resource versions in the DataStore | Hosting provider: how storage expands and what it costs per volume; partner: how old resource data is pruned |
| Patch and minor upgrades | Patch releases avoid schema changes; minor releases can include backwards-incompatible changes; two minor releases a year | Partner: upgrade scope per minor release, test environment use, and whether the retainer covers each cycle |
| Extension compatibility checks | Custom and third-party extensions, such as ckanext-dcat and ckanext-saml2auth, must match the CKAN minor version in use | Partner: which extensions are covered, version pinning approach, and who fixes breakages after an upgrade |
| Security patching | Operating system, Python, PostgreSQL, Solr, Redis and CKAN patches; outdated patch releases lose support once a newer one ships | Hosting provider and partner: patch window, emergency patch process, and who reviews vendor security advisories |
| Monitoring | Uptime, Solr and database health, disk growth, background job backlog, and certificate expiry | Hosting provider or partner: which alerts are included, who responds out of hours, and who owns each alert |
| Internal staff time | Portal administration, publisher support, metadata quality review, and coordination with vendors | Internal: named roles and monthly hours; partner: which tasks the retainer covers and which stay in-house |
Which parts of CKAN ownership teams keep in-house and which they outsource
Most teams keep the work that depends on knowing the data and the publishing organizations: content ownership, metadata governance, publisher onboarding and day-to-day dataset curation. Someone in the team should own each dataset, approve changes to the metadata schema and act as the contact for every publishing body. These tasks need data governance skills: knowing which fields are mandatory, how definitions are agreed and when a dataset is retired. If no one in the team holds these skills, datasets go stale, fields are used inconsistently and duplicate records accumulate. A practical first step is a short written list of who approves a new metadata field and who answers when a publisher asks for help.
Teams often outsource the early sizing and the infrastructure build, because both need Linux administration skills that many data teams do not hold in depth. A source install expects Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. The package install guide covers Ubuntu 20.04 and 22.04 (64-bit), while source installs can run on other systems such as Red Hat, Fedora and CentOS. Ask any provider to state which operating system and component versions the quote assumes, and confirm them against the current CKAN install documentation. Without Linux administration in the team, the portal ends up on servers that nobody patches, monitors or backs up.
Solr and PostgreSQL setup is another common outsourcing point, because both affect search quality and the DataStore. The DataStore keeps structured resource data in a separate PostgreSQL database with a write user and a read-only user, so the database configuration must be correct before any data is loaded. Solr needs its own tuning and index rebuilds when the schema changes. Custom extensions need Python developers who understand CKAN plugin interfaces. Extensions such as ckanext-dcat, which is supported on CKAN 2.10 and 2.11, still need testing against the version you run. If the team lacks these skills, search breaks silently and custom code becomes impossible to maintain.
Upgrade projects and security review are usually planned as separate, fixed-scope work. CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11. The project supports the latest patch of the current minor version and the previous minor version, so an outdated patch loses support once a newer one ships. Patch releases avoid schema changes and new features, while minor releases may include backward-incompatible changes that need a planned upgrade. Identity federation through a tool such as ckanext-saml2auth also needs identity and access skills that are often missing in data teams. Ask for the upgrade and review scope in writing, including which extensions and identity settings are covered.
What makes CKAN cost estimates wrong after the first year
Most CKAN estimates fail after the first year because they price a launch instead of a running service. The five items below recur in portal budgets, and each one maps to a line the model should carry from the start.
Treating CKAN as a one-time install
The first deployment is a project, but the portal then needs upgrades, patching, backups, monitoring and content support for as long as it runs. Prevention: ask for a recurring platform operations line with named owners and on-call hours, and separate one-time build work from annual support in any quote. Model line: the recurring operations section, not the build section.
Ignoring the two-minor-release cadence
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. A portal left on an older minor loses coverage, so an upgrade that looked optional becomes forced. Minor releases may include backwards-incompatible changes, while patch releases should not. Prevention: schedule one minor upgrade per year with a test cycle for each. Model line: the annual upgrade line. Confirm the current minor on the CKAN releases page before budgeting.
Underestimating extension maintenance after upgrades
Each custom or third-party extension must be checked against the new CKAN minor before the core upgrade goes live. Extensions carry their own version support: ckanext-dcat, for example, lists support for CKAN 2.10 and 2.11, so a newer minor can force a fork, a replacement or a rewrite. Prevention: inventory every extension with its version pin, upstream activity and theme overrides before quoting. Model line: an extension maintenance line that repeats with each minor release, sized to that inventory.
Sizing DataStore and search from day-one volumes
DataStore tables live in a separate PostgreSQL database, and Solr keeps its own search index. Both grow with every dataset, resource and harvest, so an estimate built on launch volumes understates storage and reindex effort over time. Prevention: model growth from expected publisher uploads and retention rules, and carry a capacity review in the recurring budget. Model line: hosting and storage, with the growth assumption stated. Ask the quote to name the dataset count and file sizes it assumes.
Missing the legacy DataPusher path
XLoader is the officially supported tool for loading files into the DataStore, and DataPusher is now legacy. A portal that still relies on DataPusher keeps a second loading path to test, patch and explain to publishers, and that path can fail without obvious alerts. Prevention: list the resources that depend on DataPusher and migrate them to XLoader before the next upgrade. Model line: the migration and testing line in the upgrade budget. Confirm the scope split in the written quote.
How the cost of ownership changes by starting point and environment
A hosted CKAN service moves servers, the database, the search index and patching into a provider contract, so most infrastructure becomes a recurring charge. Self-hosting keeps those lines on your own cloud invoices and staff time, so the cost is easier to see but also easier to underestimate.
The lines that change most between the two models are:
- Infrastructure: Hosted fees often bundle compute, storage and backups. Self-hosted costs cover application nodes, PostgreSQL, the DataStore database, Solr and Redis, sized for your traffic and dataset volume.
- Extensions and theming: Confirm whether the provider allows custom extensions and theme code. Self-hosting allows them, but review and upgrades then sit with your team.
- Upgrade timing: Ask who decides when CKAN minor and patch versions change, who tests extensions first and whether you can hold a version for a defined period.
- Exit terms: Ask how datasets, DataStore tables and configuration can be exported and what leaving the service costs.
- Support scope: Get written response expectations, including who handles Solr and DataStore incidents.
Before comparing quotes, ask each provider to list which of these lines are included, which are billed separately and how the total changes if your extension list grows.
A portal on an older CKAN 2.x release carries costs that a new deployment does not: extension rework, dependency changes and a period when two environments run side by side. The cost depends on how far the portal is behind and how many custom extensions it depends on.
The lines that change are:
- Support status: CKAN supports the latest patch of the current minor version and the previous minor version. Patch releases that are superseded lose support, so an older patch line is a security gap to close, not a stable baseline.
- Compatibility work: Patch releases do not break backwards compatibility. Minor releases can include backwards-incompatible changes, so each minor step needs its own extension testing.
- Runtime changes: Current source installs require Python 3.10 or newer and PostgreSQL 12 or newer. Older Python or database versions may need their own upgrade effort before CKAN itself moves.
- Parallel running: Budget for a staging environment and a cutover window, both of which add infrastructure and testing time.
- Data validation: Plan for checks that datasets, organizations, users and DataStore resources arrived intact.
Ask the team to map each custom extension to the target CKAN version and to name the minor releases that will be crossed, since that list drives most of the effort.
DataPusher is now legacy, and XLoader is the officially supported tool for loading uploaded or linked files into the CKAN DataStore. A portal that still relies on DataPusher has a loader change to fund, and the cost depends on how many resources depend on it and how they were loaded.
The cost lines that change are:
- Configuration and deployment: Replacing the loader adds configuration work and a change to how background jobs run on your workers.
- Reprocessing: Resources loaded earlier may need to be loaded again to match the new loader's output. Count how many DataStore resources exist before estimating this work.
- Failure handling: Review resources that failed under the old loader. Some may need a corrected source file rather than a rerun.
- Infrastructure sizing: Confirm file size limits and worker memory and disk for the new loader, since large uploads drive worker load.
- Documentation for publishers: Publishers who upload files may need updated guidance on formats and load status.
Ask the team which resources depend on the old loader, how many were loaded through it and whether the DataStore tables need to be rebuilt or only checked.
CKAN's package install guide covers Ubuntu 20.04 and 22.04 64-bit. Source installs also work on other operating systems, including Red Hat, Fedora and CentOS. The operating system choice changes how much of the install is packaged, how much your team builds by hand and how long your staff must maintain it.
The cost lines that change are:
- Install effort: The Ubuntu guide covers the documented path. On Red Hat, Fedora or CentOS, expect more manual steps for Python, PostgreSQL, Solr, Redis, uWSGI and Nginx, and document each one.
- Runtime versions: Confirm that the default Python and PostgreSQL packages on your chosen distribution meet CKAN's minimum versions. Missing versions may mean extra packages or source builds.
- Operating system lifecycle: Check the vendor's support window for each release you choose. The window determines when the OS must be replaced, which is a recurring cost independent of CKAN.
- Patching and skills: Your platform team needs skills for the chosen distribution, and each patch cycle covers the OS and the CKAN stack.
- Vendor support: If your OS subscription comes with support, confirm whether it covers the packages CKAN depends on.
Ask the platform team which distribution they already run in production, since matching that standard usually lowers the ongoing cost of operating CKAN.
Solr and Redis can run from Docker images tagged per CKAN version. Running them this way changes where the cost sits: less time on manual installs, but new costs for container platforms, image maintenance and persistent storage for the search index.
The cost lines that change are:
- Container platform: If you do not already operate a container platform, budget for the orchestration, registry and monitoring the containers need.
- Image maintenance: Each CKAN upgrade may need a matching image tag for Solr and Redis. Confirm who rebuilds, scans and approves images, and how often.
- Persistent storage: Solr index volumes need backup and capacity planning. Reindexing after an upgrade or failure takes time, so confirm the procedure and who runs it.
- Version alignment: Check each image's Solr version against CKAN's recommendation of Solr 9, with Solr 8 as the alternative, and confirm the Redis version your tag uses.
- Skills: Container operations skills are a cost when the team has none.
Ask the vendor or team to confirm that each image tag matches your CKAN version, who owns base image patching and how the search index is backed up and restored.
What the buyer must provide before a CKAN cost model can be priced
A CKAN cost model is only as good as the facts behind it. Before any partner can price hosting, search indexing, migration effort or support, the buyer needs to supply a baseline of the portal as it exists today, or as it is planned to exist. The most useful starting point is the size of the catalog: the current number of datasets and resources, the expected growth over the planning horizon, and the file size profile. Resources that are small CSV files behave very differently from large geospatial archives or pushed DataStore tables, and that difference drives storage, DataStore loading through XLoader, and the capacity of the PostgreSQL and Solr instances. Ask for the largest files, the total storage footprint and the number of resources that are linked rather than uploaded.
Next, list the people and workflows that put content into the portal. Give the number of publishers, which organizations they belong to, how they create datasets (web form, spreadsheet import, API script or harvesting), and how each publisher is onboarded and supported today. Publisher onboarding is one of the largest recurring costs in many open data programs, and it is rarely visible in an infrastructure estimate. Pair that list with the metadata schema in use, including any custom fields or DCAT profile requirements, because schema work changes both build effort and the test burden on every upgrade.
The technical inventory is the part most often incomplete. Record every installed extension with its exact version, whether it is maintained upstream, and whether it has local patches. Record the current CKAN version, the Python version, and the PostgreSQL and Solr versions in production. Confirm the Redis deployment and the web stack in front of CKAN. CKAN's supported version rules mean that the gap between the current release and the latest supported minor version sets the size of any upgrade, so an accurate version list is the input that decides whether a migration or an in-place upgrade is priced. Also describe the hosting model (cloud account, data center or air-gapped network), how backups are taken and restored, where they are stored, and who has tested a restore.
If single sign-on is planned, the identity provider must be documented before estimating work. Ask for the protocol the provider supports, the attributes it releases (for example, the user identifier, email, and any organization or role claims), how sysadmin rights should be granted, and whether local registration must remain available for some users. The mapping rules for organizations and roles are where a SAML2 integration takes most of its design time. Finally, name the owners who can make decisions. A quote needs a scope owner who can accept or change the written scope, a budget owner who approves spend and recurring support, and an upgrade owner who decides when the portal moves to a new minor release. Without named owners, scope changes stall and recurring costs are never agreed.
Questions buyers ask about CKAN cost and effort
Does CKAN cost anything to license?
CKAN is licensed under the GNU Affero General Public License v3.0, so there is no license fee for the software itself. The money goes to everything around it: the servers or cloud accounts that host the portal, PostgreSQL, Solr and Redis, storage for uploaded files and DataStore tables, and the people who install, customize, secure and run it. Those costs recur every year, so the model should list them as separate lines. Ask any partner to split one-time work (installation, theming, metadata schema setup, extension development) from recurring work (hosting, backups, monitoring, patch and minor upgrades, support). DeployOpen does not publish a price list, so a quote follows from the written scope. Also confirm with your legal team how AGPL obligations apply to any modifications you plan to publish.
What drives the yearly running cost of a CKAN portal?
The main drivers are how many datasets and resources the portal holds, how much data goes into the DataStore, how heavy search and API traffic is, and how many custom extensions you run. Each one increases the size of the database, the Solr index, storage and compute. Availability targets matter too. A portal that must stay up during public release cycles needs redundancy, backups that have been tested by restoring them, and monitoring that a small team can act on. Extension count drives upgrade effort, because each custom extension must be checked against every new CKAN minor release. No public price is given here. When you request a quote, ask for each recurring line item along with its assumptions about data volume, number of environments and support hours.
How long does it take to build a CKAN cost model?
The time depends on how much of the environment is already known. A model built from a finished requirements list, with an existing hosting account and known data volumes, takes less time than one that must first establish scope, the metadata schema, the number of publishers and the target hosting. The work usually includes an inventory of datasets and sources, a list of extensions and integrations such as DCAT harvesting or SAML2 single sign-on, a choice of hosting model, and a three-year projection that includes upgrade effort. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for the duration in the written scope instead of accepting an informal estimate in conversation.
Can our own team build a CKAN cost model without a partner?
Yes, a capable team can build the model internally, provided it has someone who understands CKAN's architecture and its release cycle. The model needs a component list (Python, PostgreSQL, Solr, Redis, web server and storage), the number of environments, an inventory of extensions, and a recurring labor estimate. The hardest parts are usually upgrade labor and the cost of keeping extensions compatible, because both depend on the version you run. CKAN's release policy supports the latest patch of the current minor version and the previous minor version, so an internal model should assume a steady cadence of upgrade work. Check the platform requirements in the official install documentation, then compare your model with a partner's written scope to find gaps in both.
What does our team need to provide for a CKAN implementation?
The client typically provides access to the target cloud accounts, data center or network, a named technical owner, decisions on the metadata schema and publisher roles, sample datasets and sources, and access to the existing identity provider if single sign-on is in scope. Someone must also approve hosting, backup and retention rules. Expect the work to need staff time for reviews and testing throughout the project, with sign-off as only one part of that time. The more of these inputs are ready at the start, the more accurate the written scope and quote will be. Ask the partner to list each input explicitly so you know who owns it and when it is needed.
How does a hosted CKAN service compare with self-hosting?
A hosted service moves infrastructure operation, and sometimes upgrades, to the provider, so your recurring cost shifts from servers and staff time toward a subscription. Self-hosting keeps the portal inside your own cloud accounts, data centers or air-gapped network, which matters for data residency and for control over which extensions run. Compare both options over the same three-year scope: hosting fees, storage, support hours, upgrade effort, extension support and the cost of leaving the provider. Hosting terms, service levels, data export rights and the CKAN versions a provider runs all vary, so confirm them in writing with each vendor. DeployOpen's work covers self-hosted platforms inside the client's own infrastructure.
How do CKAN upgrades change the three-year cost?
Upgrades recur, so they belong in the three-year view. CKAN targets about two minor releases a year, and the project supports the latest patch of the current minor version and the previous minor version for security and bug fixes. Outdated patch releases lose support once a newer patch is out, so patch work is continuous. Patch releases do not break backwards compatibility, but minor releases may include backwards-incompatible changes, which means extensions and theming need testing each time. The latest release, CKAN 2.12.0, came out on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11. At that cadence, the model should count every minor release across the three years, along with extension compatibility checks and any Solr or Python changes each one requires.
How DeployOpen scopes, delivers and supports CKAN ownership work
DeployOpen plans, implements, hardens and supports self-hosted CKAN inside your own cloud accounts, data centers or air-gapped networks. Ownership costs are set out in a written scope before work starts, and most engagements are fixed-scope. Ongoing support, upgrades and continuous testing are available as retainers, so recurring costs can be quoted separately from the build.
How we scope
- The written scope lists the CKAN components, extensions, DataStore, Solr, Redis and hosting targets in your environment.
- Cost drivers are mapped line by line: infrastructure, storage and search, theming, custom extensions, publisher support and upgrades.
- Recurring items such as patch cycles, extension maintenance and retainer terms are kept separate from one-time build work.
How we build
- The build follows the stack CKAN documents: Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 or 8, and Redis.
- DataStore is set up with separate write and read-only database users, and XLoader is configured for loading uploaded files.
- Custom extensions and theming are tested against the target CKAN version before they reach your production portal.
How we hand over
- Handover includes configuration records, installation steps, and a list of extensions with their versions and named owners.
- Operating runbooks cover patch application, backups, Solr reindexing and DataStore checks, written for your own staff.
- A cost review note lists which items your team keeps in house and which items sit under a support agreement.
How we support
- Retainers can cover patch releases, extension compatibility checks, and Solr or Python changes on your CKAN version.
- CKAN supports the latest patch of the current minor and the previous minor, so upgrade timing belongs in the scope.
- Security and functional regression testing can run alongside patching, with findings reported to you in writing.
