Skip to main content
The connector ships as a single binary named 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-cert are mutually exclusive; exactly one is required.
  • The Kubernetes-only flags are rejected unless --target helm; --server, --ca-data, --cluster-name, and --no-instance are rejected under --target helm (the Helm flow reads the workstation’s kubeconfig and detects the in-cluster instance).
  • --no-instance and --instance are mutually exclusive.
  • --managed and --no-managed are mutually exclusive, and --cluster-name is rejected with --no-managed. Under --target helm, --instance and --instance-namespace are rejected with --managed.
  • --no-auto-sign and --sign-endpoint are mutually exclusive with each other, and both (plus --api-private-ca, --managed, --no-managed, and --cluster-name) are rejected with --signed-cert.
  • --operators and --no-gateway are mutually exclusive.
  • --skip-provision rejects --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-fingerprint with 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.
On Kubernetes, pinning is not used: expose the gateway through an Ingress with a CA-issued certificate, or use a port-forward.

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 bundle grant 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 the default 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 what prepare 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 a watch: 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 a ScalingOverride. --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 the ns-<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’s result 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’s pcm-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. Run platform 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:
Last modified on September 22, 2026