From 5a04aa4981054cab324674ceb81ce894c1b01a7b Mon Sep 17 00:00:00 2001 From: Brian Miller Date: Sat, 22 Aug 2026 21:17:57 +0000 Subject: [PATCH] docs: install the CLI and the Agent from their releases Both components now publish prebuilt archives, and neither page said so. The Stone CLI page opened its install section with `go build -o stone`, and the Agent page had no install section at all -- it went from "what the Agent is" straight to the credential lifecycle, leaving the reader to work out where a binary comes from. The Agent's subsection is deliberately unnumbered. Numbering it would renumber every section below it on that page, and the numbers are how the other pages refer to it. Co-Authored-By: Claude Opus 5 (1M context) --- docs/agent.md | 16 ++++++++++++++++ docs/stone-cli.md | 13 +++++++++++-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/docs/agent.md b/docs/agent.md index 0782630..034e29a 100644 --- a/docs/agent.md +++ b/docs/agent.md @@ -18,6 +18,22 @@ The agent is a single Go binary with zero external dependencies (other than the !!! note "Not to be confused with `leaf-sync`" The Agent is a **per-Thing** executor — it manages one device or server. `leaf-sync` is a **per-site** config-mirroring agent that bootstraps a NATS leaf node and syncs an org's configuration into local KV. A site often runs both. See [Leaf Nodes](./leaf-nodes.md). +### Getting the binary + +Prebuilt archives are attached to every [release](https://github.com/stone-age-io/agent/releases) — Linux amd64/arm64, Windows amd64, FreeBSD amd64. Each one carries the binary, the per-OS example configs under `configs/`, and the install guides under `docs/`: + +```sh +VERSION=0.1.0 +wget https://github.com/stone-age-io/agent/releases/download/v${VERSION}/agent_${VERSION}_linux_amd64.tar.gz +tar xzf agent_${VERSION}_linux_amd64.tar.gz +sudo mv agent /usr/local/bin/agent && sudo chmod +x /usr/local/bin/agent +sudo mkdir -p /etc/agent && sudo cp configs/linux/config.yaml.example /etc/agent/config.yaml +``` + +The agent then installs itself as a service on the host's own service manager — `agent -service install`, which resolves to systemd, a Windows service, or rc.d. There are no unit files to place by hand. `agent -version` reports what a host is running without starting it. + +The per-platform guides in the agent repository (`docs/linux.md`, `docs/windows.md`, `docs/freebsd.md`) cover directory layout, permissions and service registration in full. + --- ## 2. Provisioning & Credential Lifecycle diff --git a/docs/stone-cli.md b/docs/stone-cli.md index 2b60875..19bac94 100644 --- a/docs/stone-cli.md +++ b/docs/stone-cli.md @@ -49,14 +49,23 @@ The division of labor in practice: ## 2. Install & build -`stone` is a standalone Go module (`github.com/stone-age-io/stone-cli`, Go 1.25+ — its own module, tracked separately from the platform binary). +Prebuilt binaries are attached to every release — linux, darwin and windows, amd64 and arm64 each: + +```sh +VERSION=0.1.0 +curl -sSLO https://github.com/stone-age-io/stone-cli/releases/download/v${VERSION}/stone_${VERSION}_linux_amd64.tar.gz +tar xzf stone_${VERSION}_linux_amd64.tar.gz # unpacks ./stone, LICENSE, README.md, SKILLS.md +./stone --version +``` + +Or build it yourself. `stone` is a standalone Go module (`github.com/stone-age-io/stone-cli`, Go 1.25+ — its own module, tracked separately from the platform binary), so a checkout and one command is the whole thing: ```sh go build -o stone # local binary go vet ./... ``` -There's no daemon and nothing to install server-side — the binary is the whole client. +A source build reports `dev` from `--version`; a release build reports the tag. Either way there's no daemon and nothing to install server-side — the binary is the whole client. ---