Installing ClickHouse from deb and rpm packages on hosts you control
A platform team that needs ClickHouse running on Linux hosts it manages should start with the official deb and rpm packages. The packages are the most direct path for a self-managed server on Debian, Ubuntu or an rpm-based distribution, because they install the server and client binaries, a default configuration tree and a systemd service that your team can version, patch and monitor with the tools it already uses. ClickHouse server is open source under the Apache License 2.0 (SPDX: Apache-2.0), so the package is yours to run inside your own infrastructure. ClickHouse Cloud is a separate managed service from ClickHouse Inc. and is out of scope for this page.
The package layout matters more than the install command itself. The configuration lives under /etc/clickhouse-server/, where site-specific settings belong in config.d and users.d drop-in files, so your overrides survive package upgrades instead of being edited into the main config.xml. The server runs as the clickhouse-server service, and the clickhouse-client package provides the command-line client. Confirm the exact file paths and service names against the version you install, because they can change between releases.
A package install fits best when your team manages the hosts directly, has a configuration management tool, and wants the server close to the operating system. Docker suits teams standardizing on container images, Kubernetes suits teams already running clusters they operate, and an air-gapped mirror suits networks with no outbound access, where packages are copied in through an internal repository. Choose the path before you write provisioning code, because the repository, signing key and version pinning decisions differ for each one.
Which release line and install method fit your environment
This table compares the release line to pin for three common situations: general production, regulated change control and pre-production testing. Read each row as a starting position, then check the current supported list on the ClickHouse releases page before you pin a package version. The main takeaway is that the security policy's supported list and the release cadence should drive your pin, not the newest version alone.
| Environment | Release line to consider | What the team must watch |
|---|---|---|
| General production | Stable releases, moving to the newer stable line as it ships, with the latest stable release or a recent supported line pinned | Monthly stable releases, so schedule a regular package review; read the changelog before each upgrade because minor backward-incompatible changes can occur |
| Regulated change control | An LTS line such as v26.8.29.10-lts or v26.3.53.4-lts, pinned to an exact package version | LTS releases ship twice a year and are supported for a year; confirm each pinned version is still on the security policy's supported list |
| Pre-production test | The newest stable release, matching the version planned for production | Test with representative data and queries so the version you validate is the one you install in production |
| Security-only patch path | The exact supported version currently on your pin, updated within its supported line | Versions outside the security policy's supported list receive no security updates; check that list at each review |
| Version pinning in apt or yum | Pin the exact package version in your package manager so routine updates do not move the server | Hold or lock packages during change windows and record the pinned version in configuration management |
| Repository signing key | Verify the repository signing key and package signatures before adding the source | Confirm the key fingerprint against the official documentation, and rotate the trusted key list when the vendor announces changes |
| Current version list | Confirm the current stable and LTS versions on the ClickHouse releases page before you choose | The version names in this table are examples from the releases page at the time of writing and will change |
How to install ClickHouse from the official repositories
This sequence takes a Debian, Ubuntu or rpm-based server from a supported ClickHouse version choice to a running, pinned, verified service. Each step ends with a check so the platform team knows the install is correct before any data arrives.
Confirm distribution and supported version
The platform owner checks the ClickHouse security policy to see which release lines currently receive security updates, and matches that list against the production FAQ guidance on choosing stable or LTS releases. Confirm the operating system release is one the official install documentation covers, and record the exact version to deploy. Done when the team has a written version decision and a named owner for upgrades. Ask the vendor or your own security team which lines your policy allows.
Add the official repository and verify its key
On each server, the administrator adds the ClickHouse package repository using the exact repository lines from the official install documentation for the distribution, not lines copied from forum posts or mirrors. Import the repository signing key and compare its fingerprint with the value published in the official documentation before trusting it. Done when the package manager refreshes its index without signature errors and lists ClickHouse packages from the official source.
Pin the chosen version for server and client
Using the package manager's standard version selection (apt or dnf/yum), the administrator pins the server and client packages to the same release chosen in the first step, so that a routine system update cannot move them to a newer line. Install both packages at that version. Done when the package manager lists the pinned version as held or locked and the server and client report identical version strings.
Install the server and client packages
The administrator runs the standard install command for the package manager with the pinned versions, which places the server binary, the default configuration under the config directory, and the client. The installer may prompt for a default user password, so decide how it is set before running the command. Done when the package manager reports a successful install and the files exist under the expected configuration path.
Configure config.d and users.d overrides
Keep the vendor defaults untouched and place local changes in override files under the config.d directory for server settings, and the users.d directory for user and profile settings, following the layout described in the official documentation. Restrict the default user as recommended in the access control documentation, and create named administrative users through the SQL-driven workflow. Done when the configuration files parse without errors on a dry run of the service and the default user no longer has unrestricted access.
Enable and start the systemd service
The administrator enables the ClickHouse server unit with systemd so it starts at boot, then starts it and reads the status output. Review the server log for startup errors, such as configuration parse failures or ports already in use. Done when systemd reports the unit as active and the log shows a clean startup without repeated restart attempts.
Check the running version and listening ports
The administrator connects with the client and runs a version query to confirm the running release matches the pinned version, then checks which ports the server listens on against the network plan. Confirm that the administrative and client interfaces are reachable only from intended networks, and that TLS settings, if required by policy, are active. Done when the version matches the pin, the expected ports are open, and no unintended interface is exposed.
Securing the package install before any data arrives
A fresh ClickHouse server accepts connections and runs queries as soon as it starts, so the controls below belong in the install plan rather than a later hardening pass. Together they decide who can reach the server, who can act as which user, and which patches you apply and when.
Verify keys and package sources
Before installing, confirm that the repository you add and the signing key it uses come from ClickHouse's own published instructions, and record the key fingerprint in your change record. Mirror the repository into your internal package store so every host installs the same signed artifacts. Check the signature on each package during install, and keep a copy of the key you verified so later reinstalls cannot pull in a substitute.
Restrict the default user
ClickHouse's default user starts with all permissions and no password unless you set one. Create named administrative users with roles through SQL, then remove the default user's rights or disable it before any application connects. The access control documentation describes this SQL-driven workflow, and it is worth confirming the exact default-user settings for your release with the docs before go-live.
Keep the server off public interfaces
Bind the HTTP, native and inter-node ports to the private addresses your applications and replicas use, and enforce that with host firewalls and security groups. Keep ClickHouse Keeper ports reachable only from Keeper and ClickHouse peers. Confirm the listen settings in your config.d files after install, since a default listen address can expose the service wider than you intended.
TLS and external authenticators
Enable TLS on client and inter-node connections with certificates issued by your own CA, and decide early whether users authenticate by password, client certificate or an external directory. ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators. Choose one model per user type and test it with a non-administrative account before rollout.
File ownership and log handling
Run the server under its service account and make sure configuration files holding credentials are readable only by that account and administrators. Keep the data, log and configuration directories separate so permissions can differ, and decide where logs go and who can read them. Query logs can contain sensitive literals, so confirm your retention and masking rules before enabling broad log access.
Track the security policy for patches
Record which release lines ClickHouse lists as receiving security updates and set a calendar check against the project's security policy. Any version outside that list no longer receives security fixes, so an install that falls behind has a deadline you need to plan around. Pair this check with the release pages so you know which patch versions carry the fix you need.
Running package-installed ClickHouse after go-live
Patching a package-installed ClickHouse server is a deliberate change, not a background update. Pin the server and client to a specific version in your package manager so that a routine apt upgrade or dnf update cannot move a production node to a new release on its own. Choose the release line first: the ClickHouse security policy lists which versions receive security updates, and the production FAQ describes stable releases and LTS releases with different support windows. Confirm the current list in the ClickHouse security policy before you pin, and reread it at each patch cycle, because a version that is supported today may not stay supported.
Run every version change on a pre-production copy loaded with representative data and your real query workload. The production FAQ recommends this step and warns that minor releases can contain backward-incompatible changes, so read the release notes and changelog for every version between your current build and the target before you schedule the change. Record the rollout order for replicas, the rollback package version, and the checks you will run after each node restarts. Keep config.d and users.d overrides in version control with the rest of your infrastructure code, and diff them against the package defaults before each upgrade so that a package update does not silently drop or conflict with a local setting.
A package install by itself gives you neither replication nor backups. Replication depends on ReplicatedMergeTree tables and a ClickHouse Keeper ensemble, which you configure, size and monitor separately, and the replication guide describes how a recovered replica resyncs from a healthy peer. Backups require a BACKUP and RESTORE schedule, a destination such as local disk or object storage, and regular restore tests, because the backup documentation warns that an untested backup will probably fail when you need it. Plan these as their own deliverables with owners, and confirm with your team which parts of the operational runbook they will maintain after go-live.
Questions teams ask before installing ClickHouse from packages
Can our own team install ClickHouse from deb or rpm packages without outside help?
Yes, a team with Linux administration experience can install ClickHouse server and client from the official repositories on a single host, and many do. The harder question is whether the team can run the result as a production system: configuring the config.d and users.d layout, pinning versions, setting up replication with ClickHouse Keeper, scheduling backups and proving restores work, and keeping up with releases. Ask yourself whether someone on the team will own each of those tasks after the first install, because the initial installation is the smallest part of the work. A partner is most useful when you want those controls designed and written down before the first production table exists.
What makes a ClickHouse package installation take more effort?
Effort rises with the number of hosts, the variety of operating systems, and how formal your change control is. Each additional server needs the same repository setup, version pin, configuration files and service checks, so drift between hosts becomes the main risk. Mixed Debian, Ubuntu and rpm-based fleets need separate repository definitions and signing key handling. Change control adds approvals, maintenance windows and evidence for each change. Identity integration is often the largest driver: LDAP, Kerberos, X.509 certificates, HTTP authenticators and JWT authentication are all supported as external authenticators, and each one needs directory access, certificate lifecycles and testing before it can carry production logins.
What do we need to provide before a ClickHouse package installation starts?
You need three things: Linux administrators who can make changes on the target hosts, a pre-production environment, and a data sample. The administrators provide access to the servers, network paths to any directory or certificate services, and approval for repository and firewall changes. The ClickHouse production guidance recommends a pre-production environment with representative data and queries, so the sample should reflect your real table shapes, event volumes and typical queries, not a few synthetic rows. Ask the team that owns your identity and certificate systems to join early, because their availability often sets the schedule.
How long does a ClickHouse package installation take?
Duration depends on the written scope, and no figure is given here. The main inputs are the number of server and Keeper hosts, whether replication and backups are included, how many authentication methods must be integrated, and how many environments (pre-production and production) need matching configuration. Ask any provider, including DeployOpen, to state the milestones, the environments covered, what the client must supply and by when, and what counts as done. A fixed-scope engagement records these items in writing before work begins, so the timeline should follow from that document rather than from a general estimate.
Should we install ClickHouse from packages or run it in Docker?
Packages suit teams that manage hosts directly, want the service under the operating system's package and service tooling, and prefer configuration files on disk they can review and back up. Docker suits teams already standardized on container platforms, where image tags, volumes and orchestration are the normal operating model. Packages make the host the unit of management, so OS patching, kernel settings and disk layout are your responsibility on each machine. Containers move some of that work into image builds and volume mounts. Choose based on how your organization already patches and audits servers, not on which install is quicker on day one. Confirm the approach with your platform team before you commit.
How should we schedule ClickHouse upgrades after the first install?
Plan upgrades as a recurring process, not an occasional project. ClickHouse stable releases ship roughly monthly, the three latest stable releases receive diagnostics and bug fix backports, and LTS releases ship twice a year and are supported for a year after release. The security policy lists the currently supported versions, and any other version is unsupported. Choose between the stable and LTS tracks, then test each target version in pre-production with representative data, read the changelog for backward-incompatible changes, and upgrade replicas in a planned order with a rollback path. Your schedule should follow the support windows and your change calendar, so decide the cadence before the first production upgrade.
What should a written quote for ClickHouse package installation include?
A useful quote lists scope, deliverables, assumptions and exclusions, plus a clear split between one-time and recurring costs. Ask for:
- The list of hosts, operating systems and environments in scope
- Whether replication with ClickHouse Keeper, backups with BACKUP and RESTORE, and restore tests are included
- Each authentication method to be configured and the directories or certificate services it depends on
- The documentation handed over, such as configuration standards and runbooks
- The client responsibilities and dates, including access and sample data
- Acceptance criteria and the process for changes to scope
- Whether ongoing upgrades, monitoring or support are a separate retainer
DeployOpen works from a written, fixed scope, so every line above should appear in the agreed document before work starts.
What to confirm in your environment before you install
Packages look simple, but the install only succeeds smoothly when the platform, versions, network path, server capacity and change process have been checked first. The cards below cover the six items to settle before any package is installed on a production host.
Distribution and architecture support
Confirm in the official ClickHouse install documentation that your Debian, Ubuntu or rpm-based release and CPU architecture appear in the supported matrix. An unsupported combination can install but leave you with unexpected library or service behavior. Record the exact OS version, kernel and architecture in your build sheet so the package choice is traceable during audit and incident review.
Version support status
Check the target version against the security policy before you pin it. Only the versions listed as supported receive security updates, so a pinned release that falls off that list becomes a standing exposure. Also decide whether you want a stable line that ships roughly monthly or an LTS line that ships twice a year, since that choice sets how often you will need to repeat this check.
Repository access and mirroring
Determine whether your servers can reach the official package repositories directly. If they cannot, or if your policy requires internal sourcing, plan an internal mirror that is refreshed on the same cadence as your upgrade plan. Ask who owns that mirror, how signing keys are imported and verified, and how packages are promoted from test to production.
Memory and disk for your data volume
Package installation does not tell you whether a host can hold your data. Estimate memory, CPU, disk and replica counts from your concurrency, ingestion rate and retention before you provision. The sizing topic covers the method in detail. Keeper nodes have their own footprint, so count them separately if you run a replicated setup on the same hosts.
Kernel and operating system tuning
Review the operating system settings ClickHouse expects, including CPU governor, transparent huge pages, memory overcommit, swap behavior and kernel version. These settings are set outside the package and are often missed in golden images. Document each value you change, and confirm that your configuration management tool applies it on every new host, not only on the first one.
Change control and package acceptance
Check whether your change process accepts a vendor package, a signed repository and a service restart on a defined schedule. Confirm who approves version pins, who reviews the changelog for backward-incompatible changes, and where the rollback artifact lives. Agree this before the first install so the first production change does not stall on process.
How DeployOpen scopes and delivers a ClickHouse package install
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and a ClickHouse package install follows the same pattern: the work starts from a written, fixed scope with agreed deliverables before any server is touched. The scope names the target distributions, the server and client packages, the version line you will run (stable or LTS), the number of nodes, and who approves the change. Because ClickHouse is open source under the Apache License 2.0, the software itself carries no license fee, so what you pay for is the planning, configuration, verification and handover work around it. Ask for that breakdown explicitly in any quote.
The delivered package usually includes the configuration layout under config.d and users.d, the repository and signing-key setup, the version pin, service management checks, and evidence that the install behaves as documented. Access is handled in the same scope: the default user starts with all permissions, so the plan should cover restricting it and creating named accounts through the SQL access control workflow. You receive a runbook, the configuration files and records of the checks run, while your team keeps ownership of the production hosts. Confirm with us which artifacts will be handed over and in what format before work begins.
Ongoing work such as upgrades, security patch rollouts and support is available under a retainer, separate from the fixed-scope install. A quote follows from the written scope, so the more precisely you define hosts, release line, replication goals and change windows up front, the more precisely the quote can reflect them. DeployOpen is not a ClickHouse partner or reseller. We are not an official vendor partner, and we do not issue audit reports or certifications, so any compliance evidence we prepare is input for your own assessors. For release timing, check the current stable and LTS lines on the ClickHouse releases page before fixing the version in scope.
