clickhousectl est la CLI de ClickHouse, en local et dans le cloud.
Avec clickhousectl, vous pouvez :
- Installer et gérer des versions locales de ClickHouse
- Démarrer et gérer des serveurs ClickHouse locaux
- Exécuter et gérer des instances Postgres locales
- Exécuter des requêtes sur des serveurs ClickHouse
- Configurer ClickHouse Cloud et créer des clusters ClickHouse gérés dans le cloud
- Créer et gérer des services Postgres dans ClickHouse Cloud
- Gérer des ressources ClickHouse Cloud
- Créer et gérer des ClickPipes pour l’ingestion de données (S3, Kafka, Kinesis, Postgres, MySQL, MongoDB, BigQuery)
- Installer les ClickHouse agent skills officiels dans des agents de développement assisté pris en charge
- Transférer vers le cloud votre environnement de développement ClickHouse local
clickhousectl aide les humains comme les agents IA à développer avec ClickHouse.
Installation
Installation rapide
~/.local/bin/clickhousectl. Un alias chctl est également créé automatiquement pour plus de commodité.
Prérequis
- macOS (aarch64, x86_64) ou Linux (aarch64, x86_64)
- Les commandes Cloud nécessitent une clé API ClickHouse Cloud
En local
Installation et gestion des versions de ClickHouse
clickhousectl télécharge les binaires ClickHouse depuis builds.clickhouse.com, et se rabat sur packages.clickhouse.com (Linux) ou les versions publiées sur GitHub (macOS) lorsqu’aucun build n’y est disponible.
local use crée également un lien symbolique à l’emplacement ~/.local/bin/clickhouse vers le binaire de la version sélectionnée, afin que la simple commande clickhouse (par exemple clickhouse local, clickhouse client) soit disponible dans le PATH. Passez --no-global pour l’éviter. Si un fichier ordinaire existe déjà à cet emplacement, il est laissé tel quel et un avertissement est affiché. local remove appliqué à la version par défaut active supprime également le lien symbolique.
Stockage des binaires ClickHouse
Les binaires ClickHouse sont stockés dans un dépôt global afin de pouvoir être utilisés par plusieurs projets sans dupliquer l’espace de stockage. Les binaires sont stockés dans~/.clickhouse/ :
Initialisation d’un projet
init initialise votre répertoire de travail courant avec une arborescence de dossiers standard pour vos fichiers de projet ClickHouse et Postgres. Cette étape est facultative ; vous pouvez utiliser votre propre structure de dossiers si vous le préférez.
Il crée la structure suivante :
Exécuter des requêtes
Création et gestion des serveurs ClickHouse
Démarrez et gérez des instances de serveur ClickHouse. Chaque serveur possède son propre répertoire de données isolé dans.clickhouse/servers/<name>/data/.
--name, le premier serveur s’appelle “default”. Si “default” est déjà en cours d’exécution, un nom aléatoire est généré (par ex. “bold-crane”). Utilisez --name pour attribuer des identifiants stables que vous pourrez démarrer/arrêter à plusieurs reprises.
Ports : Par défaut, les ports utilisés sont HTTP 8123 et TCP 9000. S’ils sont déjà utilisés, des ports libres sont automatiquement attribués et affichés dans la sortie. Utilisez --http-port et --tcp-port pour définir explicitement les ports.
Gestion globale des serveurs : Utilisez --global avec list, stop et stop-all pour agir sur tous les projets à l’échelle du système. server list --global affiche tous les serveurs ClickHouse en cours d’exécution, avec une colonne Project indiquant à quel répertoire chacun appartient.
Fichiers de config personnalisés pour les serveurs locaux
Les serveurs locaux démarrent avec des paramètres par défaut bien choisis, mais il faut parfois en modifier un. Placez un fichier de config dans~/.clickhouse/configs/ et appliquez-le par son nom au démarrage d’un serveur :
config.d) ; il n’a donc besoin de contenir que les paramètres que vous souhaitez modifier, et il n’est pas nécessaire de reproduire une config complète. Les fichiers peuvent être au format .xml, .yaml ou .yml, et vous pouvez les référencer par leur nom, avec ou sans l’extension.
Répertoire de données propre au projet
Toutes les données du serveur se trouvent dans.clickhouse/, dans le répertoire de votre projet :
clickhousectl local server remove <name> pour supprimer définitivement les données d’un serveur.
Exécuter Postgres en local
En plus de ClickHouse,clickhousectl peut lancer et gérer des instances Postgres locales. Postgres en local s’appuie sur Docker ; Docker doit donc être installé et en cours d’exécution. Chaque instance est identifiée par son nom et sa version majeure, ce qui permet d’exécuter côte à côte plusieurs versions de Postgres avec des répertoires de données distincts.
Authentification
Authentifiez-vous auprès de ClickHouse Cloud à l’aide de clés API (recommandé) ou d’OAuth (via le navigateur). Si vous n’avez pas encore de compte ClickHouse Cloud,clickhousectl cloud auth signup ouvre la page d’inscription dans votre navigateur.
Clé/secret d’API (recommandé)
Les clés d’API sont le mode d’authentification recommandé, en particulier lorsque vous utilisez la CLI via un agent d’IA. Vous pouvez créer des clés d’API à portée restreinte qui n’accordent que les permissions de votre choix (lecture seule ou lecture/écriture), et chaque clé est associée à une seule organisation. C’est donc une façon sûre de donner à la CLI un accès conforme au principe du moindre privilège..clickhouse/credentials.json (propres au projet).
Vous pouvez également utiliser des variables d’environnement, soit exportées dans votre session :
.env de votre répertoire courant :
Connexion avec OAuth
.clickhouse/tokens.json (propre au projet).
L’accès OAuth est actuellement en lecture seule et donne accès à toutes les organisations auxquelles vous appartenez. Pour obtenir un accès en écriture, ou pour limiter le CLI à une seule organisation, créez plutôt une clé d’API à portée restreinte.
Statut d’authentification et déconnexion
.clickhouse/credentials.json > variables d’environnement exportées > fichier .env > jetons OAuth.
Débogage de la source d’identifiants utilisée
Ajoutez--debug à n’importe quelle commande cloud pour afficher sur stderr la source d’identifiants résolue (ainsi que l’URL de l’API) avant l’exécution de la commande.
Cloud
Gérez les services ClickHouse Cloud à l’aide de l’API.Organisations
Services
Options de création du service
Modes d’authentification de la Query API
cloud service query est la méthode de référence pour exécuter du SQL sur un service cloud via HTTP, sans binaire clickhouse et sans mot de passe de service. Elle fonctionne avec les deux modes d’authentification suivants :
- authentification par clé d’API (SQL en lecture + écriture) : la première fois que
cloud service queryest lancé sur un service sans clé stockée, il provisionne un point de terminaison Query API pour ce service et crée une clé d’API dédiée qui lui est associée. La clé (keyId,keySecretetendpointId) est stockée dans.clickhouse/credentials.jsonsousservice_query_keys.<service-id>. Limitée à un seul service, elle peut lire et écrire (SELECT, INSERT, DDL) sur ce service, mais ne peut accéder à aucun autre service de l’org. Passez--no-auto-enablepour échouer au lieu de provisionner. - OAuth (
cloud auth login) : la requête s’exécute sous votre propre identité, comme dans la console SQL web. Vos permissions SQL sur le service sont en lecture seule lorsque vous utilisez OAuth. Aucune clé d’API de Query API n’est provisionnée ni stockée.--no-auto-enablen’a aucun effet dans ce mode.
cloud service start. Définissez CLICKHOUSE_CLOUD_QUERY_HOST pour remplacer l’hôte de Query API dérivé.
Gestion des points de terminaison de requête
Gestion des points de terminaison privés
Configuration de sauvegarde
Services Postgres
clickhousectl peut également créer et gérer des services Postgres dans ClickHouse Cloud, à l’instar des commandes du service ClickHouse ci-dessus. GCP est en private preview ; passez --provider gcp avec une région et une taille d’instance GCP.
Options de création du service Postgres
Sauvegardes
ClickPipes
Gérez ClickPipes pour importer des données dans ClickHouse Cloud depuis des sources externes.Créer des ClickPipes
Chaque type de source dispose de sa propre sous-commande dansclickpipe create :
clickhousectl cloud clickpipe create <source> --help pour obtenir la liste complète des options selon le type de source.
Membres
Invitations
Clés
Activité
Sortie JSON
Utilisez l’option--json pour afficher les réponses au format JSON.
clickhousectl détecte automatiquement les contextes d’agents de code (Claude Code, Cursor, Codex, Gemini CLI, Goose, Devin et tout outil qui définit la variable d’environnement standard AGENT) et produit automatiquement du JSON sur stdout sans avoir à définir --json.
Codes de sortie
Les codes de sortie suivent les conventions de la CLIgh :
Skills
Installez les ClickHouse Agent Skills officiels à partir de ClickHouse/agent-skills.Options non interactives
Mise à jour automatique
clickhousectl peut se mettre à jour vers la dernière version :
Télémétrie
clickhousectl collecte des données d’utilisation anonymes afin de nous aider à comprendre comment la CLI est utilisée. Elle est activée par défaut, mais aucune donnée n’est envoyée avant que vous en soyez informé : lors de la première exécution, la CLI affiche un avis expliquant les données collectées et comment la désactiver, sans rien envoyer. La collecte ne commence qu’aux exécutions suivantes ; vous avez donc toujours la possibilité de vous y opposer avant que la moindre donnée ne soit collectée.
Chaque événement contient uniquement :
- La commande exécutée (par ex.
local start) et les noms des options utilisées — jamais les valeurs des options, les arguments positionnels ou toute autre entrée fournie par l’utilisateur. Les requêtes, noms de tables, identifiants et chemins de fichiers ne sont donc jamais collectés. - Le code de sortie (par ex.
0,1,2,4) et le résultat (par ex.ok,error,cancelled) - Pour les commandes mal saisies, la suggestion « did you mean » affichée par la CLI — enregistrée uniquement lorsqu’elle correspond exactement au nom d’une commande ou d’une option existante, elle ne peut donc jamais contenir ce que vous avez saisi
- La version de
clickhousectl, le système d’exploitation, l’architecture, et si la CLI a été invoquée par un agent d’IA (et lequel) ou dans le cadre de l’intégration continue
- Exécutez
clickhousectl telemetry disable(réactivez-la avecenable, vérifiez son statut avecstatus) - Définissez la variable d’environnement
DO_NOT_TRACK=1
CHCTL_TELEMETRY_DEBUG=1 pour afficher la charge utile exacte sur stderr sans rien envoyer.