Get started

Getting started

Complete a minimum viable clmbot deployment in order: download, verify, initialize, discover certificates, and run the first update.

Last reviewed: 2026-08-31Language: English

This guide walks through a minimum viable clmbot deployment. It uses Linux amd64 throughout; see Installation for other platforms.

Credential security: Never put AccessKey, AccessSecret, or other credentials in screenshots, example repositories, public Issues, or analytics events. Documentation examples always use placeholders such as <YOUR_ACCESS_KEY>.

Step 1: Choose the operating system and architecture

clmbot v0.6.6 provides five builds: macOS amd64, macOS arm64, Linux amd64, Linux arm64, and Windows amd64.

Open the download page and choose the build that matches your server.

Step 2: Download and verify SHA256

After downloading the package, verify its integrity against the SHA256 value on the download page. Treat that page as the source for both the verification command and official checksum.

Step 3: Extract the package and make the binary executable

Upload and extract the package, then add execute permission to the binary:

chmod 755 clm-bot-linux-amd64

Use the binary name in the downloaded release. clm-bot-linux-amd64 is a currently compatible example.

Step 4: View help

Run --help to confirm that the binary works and to review available subcommands:

./clm-bot-linux-amd64 --help

Step 5: Configure the upstream address and credentials

The clmbot upstream can be Certificate as a Service (CaaS) or another certificate service. When using CaaS, initialize the connection with:

./clm-bot-linux-amd64 login

Enter the Endpoint, AccessKey, and AccessSecret when prompted, then activate the node in the upstream management panel. See Configuration.

This login workflow applies only to a CaaS upstream. A private CLM or another certificate service must use the adapter instructions for that upstream. If the current release does not document that upstream, request an adapter instead of reusing the CaaS credential workflow.

Step 6: Discover certificates

Let clmbot scan the server for existing certificates:

./clm-bot-linux-amd64 discover-certificate

The command lists discovered certificate information and paths. After you enter Y, it generates config.yaml. See Certificate discovery.

Step 7: Review the generated config.yaml

Open config.yaml and confirm that certificate paths and format values, such as PEM or JKS, in servers[] match the actual environment. See the configuration reference.

Step 8: Review before_script and after_script

before_script runs before an update. after_script runs afterward and usually reloads the target service. Both execute with the privileges of the clmbot runtime account. Review every line of both scripts before production use and grant permissions according to the least-privilege guide.

Step 9: Run one update manually

Before creating a scheduled task, validate the update workflow manually:

./clm-bot-linux-amd64 update-certificate

The command checks for a new certificate, retrieves and replaces it, then runs after_script to reload the service. See Automatic updates and service reloads.

Step 10: Configure scheduled pull or remote push

Choose a long-running mode:

  • Scheduled pull (recommended): run update-certificate through crontab or Windows Task Scheduler without opening an inbound port.
  • Remote push (advanced): run in Server mode so the upstream service can push over mutual TLS. This requires a controlled inbound port; the current example uses 8862/TCP.

See Operating modes for a comparison.

Next steps