ClickHouse for public sector and government

Why government teams self-host ClickHouse for public sector analytics

A statistics office, an agency logging team or a citizen service unit often needs fast analytics over large event and log datasets, but cannot send that data to a service where someone else decides where it is stored, who can reach it or how long it is kept. Self-hosting ClickHouse keeps the analytical store inside infrastructure the agency controls. The ClickHouse server is open source under the Apache License 2.0, so the software can be installed in government data centers, sovereign cloud accounts or networks with no internet path, and the agency does not depend on a vendor's managed service to hold its records.

The trade-off is that the agency takes on work a managed cloud service would otherwise handle. Someone must own the release cadence, the replication layout built on ReplicatedMergeTree tables with ClickHouse Keeper, backups tested by restoring them to a spare cluster, and the authentication design, including LDAP or Kerberos integration, certificates and role-based access with the default user restricted. The ClickHouse security policy lists which versions receive security updates, so the agency should confirm its chosen version appears on that list before go-live. Procurement should also ask who supplies patches for an isolated network and how they are verified before they cross the boundary.

This page explains how to build that environment: the sovereignty and accreditation questions to settle first, the deployment and replication choices, access control, air-gapped installation and the support contract. Before any design work starts, the team should confirm which regulatory baseline applies to the data, because that determines which hosting and control decisions are mandatory rather than optional.

Which public sector requirements shape the ClickHouse build

This table compares the public sector requirements most likely to affect a self-hosted ClickHouse analytics build, the source of each obligation, and what it changes in design. Whether each one applies depends on the agency's data, authority and service model, so a legal or compliance review should confirm applicability before design starts.

Requirement	What it asks for	Build impact for ClickHouse
FedRAMP scope	Applies to cloud products that handle federal information on behalf of an agency. Systems used only for one agency's operations on cloud infrastructure, not offered as a shared service, are out of scope.	A ClickHouse cluster run only for one agency in its own cloud or data center may fall outside FedRAMP. Confirm whether the service is shared with other agencies or offered as a managed service.
CJIS Security Policy v6.1 encryption	Requires FIPS 140-3 validated modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations.	Set TLS for client, inter-node and Keeper traffic and encryption at rest for disks and backups to meet the key and module requirements. Confirm the crypto module validation with your assessor.
CJIS vulnerability scanning	Requires vulnerability scanning at least monthly, mapped to control RA-5 in the policy's control structure.	Plan scanning of ClickHouse hosts, containers and Keeper nodes into the monthly cycle, and track upgrades against the supported version list in the security policy.
32 CFR 2002.14(h)(2) for CUI	Federal agencies use NIST SP 800-171 requirements to protect controlled unclassified information on non-federal systems, unless the CUI category sets other safeguards.	If CUI lands in ClickHouse on a contractor or state-run system, the access controls, logging and boundary protections of SP 800-171 shape roles, row policies and audit settings. Confirm the CUI category's authority.
WCAG 2.1 AA for citizen dashboards	Under the ADA Title II rule, state and local government web content and apps, including contracted ones, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200).	Public dashboards built on Superset, Grafana or custom front ends need accessible charts, color contrast and keyboard navigation. Ask the dashboard vendor or developer to demonstrate conformance.
NIS2 public administration scope	Covers central government entities of all sizes as a high-criticality sector. Member States may extend it to local administration. It excludes entities working in national security, public security, defense or law enforcement.	Applies to EU public bodies in scope, so incident reporting, supply chain security and backup resilience apply to the ClickHouse service. Confirm with national transposition rules whether the agency is in scope.
SP 800-53B baseline sizes	Release 5.2.0 of SP 800-53 is current. The low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively.	The baseline chosen for the system sets how much access control, audit, configuration management and contingency work the build must document. Use the OSCAL baseline profiles to map controls to ClickHouse settings.

On-premises, sovereign or air-gapped: choosing the hosting model

Hosting in an agency-owned data center keeps the hardware, the operators and the data under the agency's own physical and administrative control. Internet access may still exist, but most agencies route package and image pulls through an internal repository so that every version entering the cluster is one the change process has approved.

Internal mirrors: Keep ClickHouse server packages, container images and Keeper images in an internal repository, and pin the versions you have tested in pre-production.
Keeper placement: The replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM, so reserve those hosts in the rack plan rather than sharing them with data nodes.
Update intake: Stable releases ship roughly monthly and LTS releases twice a year. Choose a line, confirm it is on the security policy's supported list, and read the changelog before each upgrade.
Backup targets: BACKUP can write to local disk, S3-compatible storage or Azure Blob Storage, so choose a target that sits on separate storage from the cluster.
What the operator carries: Agency staff or an integrator own patching, identity integration, restore tests on a spare cluster and replica monitoring.

Before committing, confirm with ClickHouse directly what offline packaging and documentation it provides for on-premises installs.

In a fully air-gapped network nothing reaches the internet, so every package, image, rule and fix must cross a controlled boundary and be verified before it is installed. The cluster can run indefinitely without outside access, but every upgrade and every security response depends on the transfer process working.

Complete offline set: Carry ClickHouse server packages, container images and Keeper images. If Kubernetes hosts the cluster, the kubeadm workflow can pre-pull control plane images and point kubeadm init at a private registry through --image-repository.
Controlled media process: Each release goes through download, integrity check, malware scan, approval and import, with a record kept for assessors. NERC CIP-013-2 is a useful model for verifying vendor software and patches before they cross a boundary.
Cadence planning: Stable releases ship roughly monthly, so the transfer process must handle a steady stream, and an LTS line may suit an intake that runs less often.
Keeper and backups inside the boundary: Keeper nodes stay on dedicated hosts, and backups go to local disk or an internal S3-compatible store, since replication alone does not protect against human error or corruption.
What the operator carries: The operator owns the transfer workflow, a rebuild procedure that needs no outside access, regular restore tests and key management.

Confirm with ClickHouse directly which offline packaging, documentation and security notices it supplies to disconnected customers, and how those notices reach you.

Which ClickHouse settings and integrations matter in government

Government ClickHouse deployments succeed or fail on a small set of settings: how the cluster replicates, who can sign in and with what authority, what each team is allowed to query, and how data is restored after a failure. The cards below cover those decisions in the order a platform team usually meets them. Ingestion sources are listed last because they are integration points to confirm, not settings to assume.

Replication with Keeper on three nodes

ReplicatedMergeTree tables coordinate through ClickHouse Keeper, which replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. For an agency, that means three separate failure domains inside the boundary, not Keeper running on the same hosts as the data nodes. Confirm rack or site placement before sizing starts, and confirm how a recovered replica resyncs in your environment.

External authenticators tied to the directory

ClickHouse supports LDAP authentication and directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators. Choose the method that matches the agency directory so that leaver and transfer events in that directory reach ClickHouse without manual user creation. Test each method with the agency's own identity team, including what happens when the directory is unreachable and whether service accounts for pipelines are covered.

Restricting the default user

The default user starts with all permissions, so it must be restricted before any data is loaded. Create named users, assign roles, and use row policies where one dataset holds records from several departments or case types. Ask the security team to review who holds administrative roles and whether those grants are reviewed on a fixed cycle. Keep the SQL-driven workflow in version control so that access changes can be audited.

Quotas and settings profiles per team

Settings profiles and quotas let each team have predictable limits on query time, memory and volume, so one team's heavy dashboard cannot starve a citizen-facing service. Map profiles to the agency's own teams and service classes, and agree who approves an increase. Quotas are also a control for shared analytics, because they limit what a compromised account can pull in one window. Record the limits in the same change log as the role grants.

BACKUP and RESTORE inside the boundary

BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. Choose a target that stays inside the agency boundary and is protected with its own access controls. Replication does not protect against human error or corruption, so schedule restores to a spare cluster and record how long each restore takes. A backup that has never been restored is not yet a proven control.

Ingestion sources to confirm

Log and event pipelines often arrive through Kafka or OpenTelemetry collectors. Treat each as an integration point to confirm, not a default. Ask which brokers, collectors and topics the agency already operates, whether they run inside the boundary, and who owns credentials and TLS certificates for each connection. Confirm version support with the vendor for each component before the ingestion design is fixed.

How an air-gapped ClickHouse install is staged and verified

The safest way to bring ClickHouse into an isolated network is to treat the crossing as a controlled change with four stages: build an offline bundle on the connected side, verify it, install it inside the boundary, and then prove that replication and restore work on an isolated spare cluster before any citizen or case data arrives. Start by choosing the release line, because it determines what you carry across. ClickHouse's security policy lists 26.9, 26.8, 26.7 and 26.3 as the versions that currently receive security updates, so choose one of those. The GitHub releases page identifies the LTS lines (26.8 and 26.3 in the current listing) as the lines to consider for a slower change cadence. Confirm the status of each line on the day you build the bundle, since support windows move.

Before the bundle crosses the boundary, apply the idea behind NERC CIP-013-2 as a general practice: verify the software integrity and authenticity of every package, not just the server binary. Record checksums and signatures for the ClickHouse packages, Keeper components, and any operating system, container or monitoring dependencies, and have someone outside the build team check them against the vendor's published values. Keep the bundle, its manifest and the verification log together so an auditor can trace each artifact. Read the changelog for every release between your current version and the target before the transfer, because the production guidance notes that minor backward-incompatible changes can occur. Record any change that affects queries, settings or table engines, and decide whether it needs a pre-production check.

Inside the boundary, install the verified packages on the spare cluster first, then run the replication and restore tests against it. Confirm that a ReplicatedMergeTree table replicates across at least three ClickHouse Keeper nodes on dedicated hosts, and that a replica you stop and restart resyncs from a healthy peer without manual steps. Then run BACKUP and RESTORE to the local disk or an S3-compatible store inside your network, and restore into a separate cluster. The backup documentation warns that a backup never test-restored will probably not restore when needed, so make this restore a scheduled exercise with a written pass criterion. Confirm the external authenticator and access control configuration on the spare cluster too, including restricting the default user, before production data moves in. Only then approve the production install.

Rollout phases for a government ClickHouse platform

This sequence moves a government ClickHouse platform from dataset classification to evidence-backed onboarding, with a gate at each phase so that no team receives access before the controls, backups and restore tests are proven. Each phase names the output the next phase depends on.

Scope and classify datasets
Inventory the event, log and statistical datasets the platform will hold, then classify each one by sensitivity, including whether it contains personal data, criminal justice information or controlled unclassified information. Agency data owners, the security team and the records officer sign off on the classification. The step closes when every dataset has a named owner, a sensitivity label and a stated retention requirement, and any dataset that falls under a regime with extra hosting rules is flagged for legal review before design begins.
Map controls to the chosen baseline
Select the control baseline that applies to the highest classification in scope, such as a NIST SP 800-53 baseline or a state criminal justice policy, and map each control to a ClickHouse setting, an infrastructure component or a documented process. Record where a control is inherited from the hosting environment and where the platform team owns it. The step closes with a control matrix reviewed by the agency's security officer, showing an owner and a planned evidence artifact for every control that applies.
Validate in pre-production with representative data
Build a pre-production environment that matches the intended topology as closely as the budget allows, load representative data with realistic volumes and skew, and run the queries analysts will actually use. Confirm the ClickHouse version against the supported-versions list in the security policy and read the changelog for backward-incompatible changes before the build is frozen. The step closes when query behavior, ingestion rates and access patterns are recorded and any version or configuration issue is resolved or accepted in writing.
Build the hardened cluster and Keeper topology
Deploy the production cluster inside the agency's own network or sovereign facility, with ClickHouse Keeper on at least three dedicated nodes, TLS on all listeners, external authentication wired to the agency directory, the default user restricted, and roles, row policies and quotas defined through SQL. Document each configuration file and keep it under version control. The step closes when a failover test shows a replica rejoining and syncing from a healthy peer, and when a hardening checklist signed by the platform lead is attached to the build record.
Test restores on spare clusters
Take full and incremental backups to the storage target approved for the classification, then restore them to a spare cluster that is isolated from production. Compare row counts, checksums on key tables and a sample of queries against the source. Repeat the restore on a schedule defined by the data owner. Because replication does not protect against human error or corruption, the step is only complete when a restore has succeeded on a spare cluster and the elapsed recovery time has been recorded against the agency's stated recovery objective.
Assemble accreditation evidence
Collect the artifacts that an assessor or authorizing official will ask for: the control matrix, configuration baselines, access reviews, backup and restore test records, vulnerability scan results, patch records and the supply chain record for every package brought across any isolated boundary. Confirm with the assessor which format and level of detail they expect. DeployOpen prepares these artifacts, but accreditation decisions and any audit or certification remain with the authorizing body and independent assessors. The step closes when the evidence set is indexed and the gaps list is either closed or formally accepted.
Onboard teams in stages
Grant access to one team at a time, starting with the team whose data has the lowest classification, and use role-based access, row policies and quotas to limit each team to its own datasets. Review access logs and query quotas after each stage before adding the next team. Confirm the support route, escalation contacts and on-call arrangements for the platform, and check whether the support contract satisfies the agency's procurement and sovereignty requirements. The sequence closes when every planned team is onboarded and the first access review is complete.

Compliance controls the agency must evidence

A self-hosted ClickHouse cluster can support several public sector control frameworks, but none of them is satisfied by the software alone. The cards below cover the decisions and records that connect ClickHouse to each framework. DeployOpen prepares that evidence; independent assessors and authorizing officials decide whether it is sufficient.

NIST SP 800-53B baseline selection

Start by agreeing which impact baseline applies to each dataset: low, moderate or high. SP 800-53B selects 149, 287 and 370 controls and enhancements for those baselines, and OSCAL profiles let teams map them to ClickHouse components in machine-readable form. Record which controls the database, Keeper nodes, backup storage and access layer each inherit, and which remain with the agency. Confirm the baseline with your authorizing official before building the control matrix.

FedRAMP applicability check

FedRAMP applies to cloud products that handle federal information on behalf of an agency, and systems used only for one agency's own operations on cloud infrastructure may fall outside it. Self-hosting ClickHouse in your own accounts or data center often changes the question, but a managed cloud service, or a shared service offered to several agencies, does not. Document who operates the platform, who holds the keys and whether any vendor touches the data. Have counsel or your FedRAMP program office confirm the determination in writing.

CJIS encryption and scanning

Where criminal justice information is stored or moves outside physically secure locations, CJIS Security Policy version 6.1 expects FIPS 140-3 validated modules or AES with 256-bit keys, applied both in transit and at rest. Configure ClickHouse TLS and disk encryption accordingly, and confirm which cryptographic modules the build actually uses. Vulnerability scanning must run at least monthly, so include the ClickHouse hosts, Keeper nodes and backup targets in the scan scope and keep the reports as evidence.

CUI handling under NIST SP 800-171

When a dataset contains controlled unclassified information, federal agencies apply NIST SP 800-171 requirements to non-federal systems that hold it. For ClickHouse, this means defining which tables hold CUI, restricting them with roles and row policies, and keeping access logs for those tables. If a contractor runs the cluster, the contract should state which CUI handling requirements flow down. Confirm the category's governing authority, because some categories prescribe different safeguards.

GDPR transfers and CLOUD Act exposure

Any remote access from a third country, including screen-sharing for support, counts as a transfer under EDPB Guidelines 05/2021, and so does storage in a cloud outside the EEA. Where a non-EU provider supports or hosts the cluster, the U.S. CLOUD Act can require disclosure regardless of data location. Map every support path, including vendor VPN access and backup replication, and assess whether each provider could be compelled to disclose. EDPB Recommendations 01/2020 say no technical measure is effective where the provider must access data in the clear.

Audit logs and access records

Evidence assessors ask for includes who queried which tables, who changed users, roles and row policies, and when backups ran and were restored. ClickHouse access control covers users, roles, row policies, settings profiles and quotas, and the default user starts with all permissions, so disable or restrict it before go-live and keep the change history. Forward query and authentication logs to a store the operations team cannot silently edit, and test that the logs answer a real access question during the restore drill.

Questions government buyers ask before hiring a ClickHouse partner

What drives the cost and effort of an air-gapped ClickHouse build?

The main drivers are how many isolated environments you need, how many packages and images must be carried across the boundary, and how much of the platform you must verify before it goes in. A one-time build covers the offline package bundle, internal mirrors or registries, the Keeper and replica layout, and acceptance testing. Recurring cost comes from patch cycles, because each release must be re-verified and transferred. ClickHouse server is open source under the Apache License 2.0, so the software itself carries no license fee, but the services work is priced separately. Ask any partner to break the quote into build, verification, transfer process and recurring patch work, and to state which items are fixed in the written scope.

How long does a sovereign ClickHouse rollout take, and what sets the pace?

The pace is set by approvals and access rather than by installing ClickHouse itself. The schedule usually depends on how quickly the agency confirms the hosting location, network zones, identity source, and the data owners who sign off on which datasets load first. Hardware lead times, change control windows and the security assessment your authorizing official requires can also dominate. The replication guide recommends at least three ClickHouse Keeper nodes on dedicated hosts in production, so procurement of those hosts belongs early in the plan. Ask for a milestone plan tied to written scope, with each dependency named as the agency's responsibility or the partner's.

What must the agency provide before implementation starts?

The agency provides the parts only it can supply: a directory for user identity, network segments and firewall change approval, hardware or virtual capacity in its own data center, and named data owners who decide what is loaded and who may query it. The ClickHouse external authenticators documentation covers LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication, so the team should confirm which of these its directory supports before design begins. Ask the partner for a written responsibility matrix listing each input, its owner and the date it is needed.

Can our own team run ClickHouse after handover?

Yes, if the handover includes runbooks, restore tests and trained operators, and your team has the skills to act on them. Routine operation covers replica health, Keeper health, backups, access changes and upgrades. The backup documentation warns that a backup never test-restored will probably not restore properly, so the team needs a recurring restore exercise on a spare cluster. Access control is managed through SQL, with users, roles, row policies, settings profiles and quotas, and the default user should be restricted. Ask the partner which tasks will be transferred, which remain under a support arrangement, and what your staff must demonstrate before handover is accepted.

How does support procurement work when vendor-paid editions are involved?

Support procurement depends on which parts of the stack are community software and which sit behind a paid edition. ClickHouse server is open source under the Apache License 2.0, while ClickHouse Inc. sells ClickHouse Cloud as a managed service, which is a different product and not what a self-hosted, air-gapped build uses. Other components in a wider data stack, such as visualization or chat tools, often reserve air-gapped deployment for paid editions, so check each component separately. Ask the partner to list every component, its license, whether the edition you need is free or paid, and who holds the vendor contract. Also confirm whether the agency's procurement rules allow a fixed-scope services contract separate from any software subscription.

How are upgrades handled across supported ClickHouse versions?

Upgrades depend on which versions are still supported and on your change-control cadence. The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions are unsupported. Stable releases ship roughly monthly, with the three latest getting diagnostics and bug fix backports, while LTS releases ship twice a year and are supported for a year. The production FAQ recommends a pre-production environment with representative data and queries, and reading the changelog first, because minor backward-incompatible changes can occur. For air-gapped sites, each release must be verified and carried across the boundary, so the upgrade calendar should be set with that transfer time in mind.

What audit and compliance evidence can the partner prepare for an assessment?

A partner can prepare systems, configuration records and test results for an assessment, but it cannot issue an audit report, attestation or certification. For federal and criminal justice work, the controls come from frameworks such as NIST SP 800-53 Rev. 5, whose baselines are defined in SP 800-53B, and the FBI CJIS Security Policy, where version 6.1 took effect on 26 June 2026. Ask for a control mapping that identifies which evidence the agency's assessor will need, such as access reviews, encryption settings and vulnerability scan results. Confirm early with your authorizing official and assessor which evidence format they accept.

How to procure ClickHouse support without losing sovereignty

A government buyer should compare support models by who holds the data, who can read the logs and who can take the system over later. Three options are common. An implementation partner sells fixed-scope written work, such as design, deployment, backup and restore testing and handover. A retainer covers ongoing upgrades, security patching and recurring restore tests. Vendor support from ClickHouse Inc. belongs to its managed service, ClickHouse Cloud, which is a different path from the self-hosted server the open-source Apache-2.0 release supports. Buying ClickHouse Cloud moves hosting outside the environment you control, so it should be assessed as a separate decision and not treated as support for a self-hosted install. Confirm in writing which of these your procurement is actually buying.

Ask for contract terms that match the sovereignty goal. The statement of work should name the physical sites, cloud accounts or air-gapped networks where ClickHouse servers, Keeper nodes and backup repositories will run, and it should state that no operator access or data copies leave those locations without written approval. Require access logs for every administrative session by the partner, including remote sessions, and agree who holds the keys for backup encryption. Define exit terms: a delivered copy of configuration, schema, access control definitions and tested backups, plus a handover of runbooks. Where EU customers are involved, check the switching rights in the EU Data Act (Regulation (EU) 2023/2854). Its switching provisions apply from 12 September 2025, allow a switch to another provider or to on-premises infrastructure with a maximum two-month notice period and a 30-day transition, and ban switching charges from 12 January 2027. Have counsel confirm how these rights apply to your contract.

Make the price comparison depend on what recurs. Fixed-scope work is one-time and should list deliverables, acceptance tests and the restore test you will witness. Retainers recur and should state response scope, which upgrades are included, how the partner handles the ClickHouse release cadence and which security updates are covered. Check the supported-version list in the ClickHouse security policy before signing, because only listed versions receive security updates. Ask every bidder for the same written scope, the same assumptions about your environment and the same acceptance criteria. A quote that cannot be compared line by line against the others is a risk in itself.

How DeployOpen scopes and delivers government ClickHouse work

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted ClickHouse inside the agency's or public body's own infrastructure, including on-premises, sovereign and air-gapped environments. Work starts with a written scope that names the datasets, controls and evidence the programme needs before any build begins.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The scope records which datasets, log sources and citizen service workloads move into ClickHouse and where they will run.
We confirm which control baselines and assessment bodies apply, and which evidence the authorizing body will expect from the ClickHouse layer.

How we build

We design replicated tables, Keeper placement and retention in a pre-production environment with representative data and queries.
Authentication is wired to the agency's directory and certificate authority, with the default user restricted and roles defined through SQL.
Every package and container image carried across an isolated boundary is verified for integrity and authenticity before installation.

How we hand over

Deliverables include architecture records, configuration, access model documentation and the backup and restore runbook.
We run a restore test on a spare cluster and record the results, since an untested backup is unlikely to restore when needed.
Operators are trained on monitoring, upgrade procedure and the changelog review step before each planned version change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Upgrade plans follow the supported version list in ClickHouse's security policy and the production guidance on stable and LTS releases.
We prepare systems, controls and evidence for assessments, while independent auditors and certification bodies issue any formal determination.