clicklink; the commands you run live under clicklink clctl. This page covers the commands used during installation and day-to-day operation. Run any command with --help for its full help text.
Flags in the troubleshoot, scraper, preflight, executor, instances create, and platform subtrees, plus the global --endpoint and --cluster, can also come from CLCTL_* environment variables (named in each flag’s help output) or ~/.clicklink/clctl.yaml. The global -v logs the admin API requests a command makes; -vv adds request bodies.
The instances and commands commands, and executor teardown, read the executor’s local API. Two global flags select it: --endpoint <url> (default http://127.0.0.1:9999, env CLCTL_ENDPOINT) and --cluster <name> (env CLCTL_CLUSTER), which names the managed cluster when a command needs one. On Kubernetes, open a kubectl port-forward to the executor Deployment first; see managed services.
clicklink clctl init
Bootstraps the connector from an enrollment token, a saved enrollment bundle, or an out-of-band signed certificate. One invocation stages configuration, provisions ClickHouse access, obtains the mTLS client certificate, deploys (Helm chart or systemd units), and verifies health. With--managed it also enables the executor for the EKS cluster it detects and grants the executor’s cluster-wide access. Re-running is safe: init preserves the config and the cluster UUID, overwrites credentials atomically, and reuses an existing client key unless you pass --force. See onboarding for the full flow and managed services for what the executor does.
Entry points
Exactly one entry point is required.Common flags
Signing flags (phase 1 only)
Kubernetes-only flags
Valid only with--target helm.
VM-only flags
Valid only with--target systemd.
Flag conflicts
--handoff,--enroll, and--signed-certare mutually exclusive; exactly one is required.- The Kubernetes-only flags are rejected unless
--target helm;--server,--ca-data,--cluster-name, and--no-instanceare rejected under--target helm(the Helm flow reads the workstation’s kubeconfig and detects the in-cluster instance). --no-instanceand--instanceare mutually exclusive.--managedand--no-managedare mutually exclusive, and--cluster-nameis rejected with--no-managed. Under--target helm,--instanceand--instance-namespaceare rejected with--managed.--no-auto-signand--sign-endpointare mutually exclusive with each other, and both (plus--api-private-ca,--managed,--no-managed, and--cluster-name) are rejected with--signed-cert.--operatorsand--no-gatewayare mutually exclusive.--skip-provisionrejects--ch-pod,--ch-user-suffix,--server,--ca-data, and--ch-admin-password-stdin(nothing provisions).
clicklink clctl preflight
Runs the connector’s check suite, grouped by category: config, files, network, clickhouse, systemd, access, disk, redaction. Each check reports pass, warn, fail, or skip. Exit code 0 means all checks passed (warnings are non-blocking); exit code 2 means at least one failed. The command runs locally by default. With--k8s-namespace it runs the connector pod’s own binary via kubectl exec and renders the report locally (systemd checks are always skipped in pods). With the remote channel flags it runs the installed binary on a remote VM instead.
The
--k8s-* flags and the remote channel flags are mutually exclusive; pick one target.
clicklink clctl troubleshoot session
Enables, disables, and inspects the support session: the time-boxed window during which the troubleshooter accepts commands. Without an active session the daemon refuses every command, even while its WebSocket is connected. See support sessions. The commands run in one of two modes:- Local file (default): reads and writes the session state file on the host the troubleshooter runs on (default
/var/lib/clicklink/session.json). - Gateway: with
--gateway-url, acquires an OIDC ID token and calls the troubleshooter’s session gateway instead, from your workstation.
Shared flags
session enable
Enabling fails while a session is already active; disable it first or wait for expiry.
session disable
Deactivates the session immediately. A no-op when no session is active.session status
Shows whether the session is active, who enabled it, and when it expires.--output (-o) selects table (default) or json.
On Kubernetes, reach the gateway over a port-forward:
clicklink clctl troubleshoot gateway trust
On a VM the session gateway serves a self-signed TLS certificate. This command records the certificate’s SHA-256 fingerprint in~/.clicklink/clctl.yaml so the session commands can verify it; a pinned fingerprint that stops matching fails closed. Trust is established out of band in one of two ways:
- With the remote channel flags, the command reads the certificate off the VM over the already-authenticated channel and pins it.
- Without a channel, pass
--gateway-fingerprintwith the SHA-256 value the connector logged when it generated the certificate; the command pins the fetched certificate only if it matches. Omitting the flag prints the presented fingerprint without pinning anything.
clicklink clctl troubleshoot audit tail
Prints the last entries of the troubleshooter audit log: newline-delimited JSON, one entry per command the daemon accepted or blocked. It opens the log read-only.
The connector’s runtime image has no shell, so on Kubernetes this command is the supported reader:
Access provisioning
clicklink clctl scraper access provision and clicklink clctl troubleshoot access provision create, and with --force rotate, a component’s per-instance access bundle: the read-only ClickHouse user and its grants, plus the Kubernetes ServiceAccount, RBAC, and token the component uses. init runs this inline during install; the standalone commands are the re-run and rotation path.
Rotate one component’s credentials for an instance:
clicklink clctl executor access
init --managed applies the executor’s cluster-wide grant with your credentials. When it cannot, init prints the commands to run from a kubeconfig with cluster admin: access apply alone on a VM (the bundle is already staged), access grant then access apply on Kubernetes. See onboarding.
executor access grant
Renders the executor’s cluster-wide access bundle under<output-dir>/_cluster/: one ServiceAccount, a ClusterRole and ClusterRoleBinding, and a ValidatingAdmissionPolicy that confines the ServiceAccount to namespaces under the executor’s namespace prefix. Review the rendered RBAC before applying it.
executor access apply
Applies the cluster-wide bundlegrant rendered: the ServiceAccount’s home Namespace, the ServiceAccount, the ClusterRole and ClusterRoleBinding, and the admission policy, then mints the ServiceAccount token into the bundle. It registers no service.
clicklink clctl executor prepare
Prepares everything on your side that a managed service create needs, in one idempotent run that stops at the first failure. It picks or validates the service name and creates the data and backup buckets and the IAM role (or verifies a role you bring). On a VM it also renders and applies the executor’s access bundle for the service namespace; on Kubernetes it skips the bundle because the executor runs as its pod ServiceAccount. It then mints thedefault user’s password (shown once) and writes the create body for instances create. See managed services.
On a VM it runs on the connector host. For a Kubernetes install it runs on a workstation with AWS credentials and a kube context for the managed cluster. That workstation also needs a copy of the connector configuration (--config), a port-forward to the executor’s local API, and a writable --output-dir.
clicklink clctl executor teardown
Removes whatprepare created for a service that ClickHouse Cloud has deleted. That is the IAM role, the recorded name, and the executor’s record of the service; on a VM, also the service’s ClusterRole and ClusterRoleBinding, the local access bundle, and the registry entry. The executor must be running and the service terminated (or stale); the run refuses while the service namespace still holds a ClickHouse cluster. The buckets prepare created, with their data and backups, are kept unless you ask for deletion, and kept buckets are re-tagged clicklink:retained-from=<name>. The command reads everything before it deletes anything. See delete a service.
clicklink clctl instances
instances create
Submits a prepared create to ClickHouse Cloud through your connector endpoint, with the connector’s own credentials. Creation is enabled per environment; see create a service. It prints the spoken name ClickHouse Cloud assigned, the state, and awatch: hint that uses your service name. The create body comes from the file prepare wrote, or from the four --deployed-name, --data-bucket, --backup-bucket, and --irsa-role-arn flags together. A retry with the same inputs returns the first create.
instances list
Prints every service the executor knows, as JSON.--cluster <name> filters by managed cluster.
instances get
Prints one service, as JSON, with the storage it was created with.--name <name> is required, and so is the cluster: pass --cluster, set CLCTL_CLUSTER, or put it in ~/.clicklink/clctl.yaml.
The three subcommands below post commands straight to the executor’s local API, bypassing ClickHouse Cloud. Run them only when your account team asks. Each needs --name <name> and the cluster (--cluster, CLCTL_CLUSTER, or ~/.clicklink/clctl.yaml), and each prints the command as JSON. Pass its id to commands get to track it; a failed command’s result holds its error.
instances scale
Sets the server replica count of one service through aScalingOverride. --server-replicas <n> is required and must be above zero. The executor reports the command as running when it applies the override and as completed when the replicas are ready.
instances patch
Changes one service in place.--create-nlb is the only patch; without it the command refuses with nothing to patch. It provisions an internal NLB as a Kubernetes Service, on AWS only, so a scraper outside the cluster can reach the servers. The executor backfills the scraper’s host from the load balancer on its next sync.
instances delete
Removes one service from the cluster. It stops the service and waits for the operator’s ordered shutdown. It then uninstalls the workload, deletes thens-<name> namespace and the scraper’s artifacts, waits for the namespace to be gone, and marks the service terminated. The service’s buckets and IAM role stay; executor teardown removes them with your credentials. A retry of a completed delete is a no-op. The normal path is to delete the service in ClickHouse Cloud; see delete a service.
clicklink clctl commands
commands list
Prints the commands the executor has recorded, as JSON, newest first. A failed command’sresult holds its error; a platform sync that is waiting for your approval names the exact platform approve command there.
commands get
clicklink clctl commands get <id> prints one command, with its stage and result.
clicklink clctl platform approve
Authorizes one platform change with your own cluster credentials. It reads the bundle the executor staged, hashes it, and renders every chart in it exactly as the executor will. It applies the permission half with the kube context you choose, creates the executor’spcm-platform identity if needed, and mints its token. It makes no request to your connector endpoint. The permission half is Namespaces, CustomResourceDefinitions, ServiceAccounts, ClusterRoles and bindings, Roles and bindings, webhook and admission configurations, PriorityClasses, and the StorageClass. The executor then applies only the workload half, and only while that token is valid. See platform updates.
For direct access to ClickHouse’s registry, run approval on the connector EC2 VM: the CLI uses its instance profile to assume the read-only pull role, independently of your kubeconfig credentials. Other ECR chart registries use ambient AWS credentials. See registry credentials.
clicklink clctl platform reset
For test clusters with no services: uninstalls the platform releases in reverse dependency order and removes the executor’s platform token bundle, so the first installation can be exercised again. Before changing anything it lists the ClickHouse clusters in the namespaces this connector owns and refuses if any exist. CustomResourceDefinitions, RBAC, and the StorageClass stay. Runplatform approve again before the next platform sync.
Remote channel flags
preflight, gateway trust, and access provision share a set of flags that select how a VM target is reached: