Install

nanook ships as a single static binary. No daemon directory, no service unit. You set up the rest.

One-liner

curl -fsSL https://nanook.cstef.dev/install.sh | sh

Detects arch, downloads the matching release tarball, verifies its sha256, picks an install dir (walks $PATH, prefers a writable user-owned entry under $HOME, falls back to a system dir with sudo, then ~/.local/bin), and runs nanook --version to confirm. Linux x86_64 and aarch64. Build from source on macOS and Windows.

If you already have a nanook binary handy, nanook install does the local-copy version of the same dance with no download. See the CLI reference.

Knobs:

After install, install.sh fetches keys/release.pub from the source tree and adds it to [self.signature].signers via nanook self trust add, so subsequent nanook self update runs will refuse a binary that doesn't carry a trailer signed by the project release key. See Trust for the full story.

Pin a version (recommended for CI):

curl -fsSL https://nanook.cstef.dev/install.sh | NANOOK_VERSION=v0.1.0 sh

Inspect before running:

curl -fsSL https://nanook.cstef.dev/install.sh -o install.sh
less install.sh
sh install.sh

Manual download

Grab the latest release and unpack it somewhere on your $PATH.

curl -L https://codeberg.org/cstef/nanook/releases/latest/download/nanook-linux-x86_64.tar.gz | tar xz
mv nanook /usr/local/bin/
nanook --version

Builds exist for Linux x86_64 and aarch64. For macOS and Windows, build from source.

From source

The workspace pins a toolchain via rust-toolchain.toml, so once you have rustup it just works.

git clone https://codeberg.org/cstef/nanook
cd nanook
cargo build --release
./target/release/nanook --version

Collectors, adapters, and channel actions are feature-gated. Drop the ones you do not need with --no-default-features and an explicit feature list:

cargo build -p nanook-cli --release \
  --no-default-features \
  --features "collector-cpu collector-mem collector-disk adapter-prometheus action-log"

Build presets

For common shapes, use one of the four bundled presets instead of hand-picking features. Pick exactly one:

cargo build -p nanook-cli --release --no-default-features --features preset-slim

Top-level toggles

Beyond per-kind features, nanook-cli exposes coarse switches you can mix into any feature set:

Configs that reference plugin = "..." will fail at build time with nanook::collectors::plugins_disabled (or the matching adapters / actions code) when the plugins feature is off.

For the full per-feature catalogue, see Collectors → Slim builds. For loading extras at runtime as cdylibs, see Plugins.

What lives where

Running as a service

Linux with systemd, the bare-minimum unit:

[Unit]
Description=nanook monitoring agent
After=network.target

[Service]
ExecStart=/usr/local/bin/nanook --config /etc/nanook/nanook.toml
Restart=on-failure
User=nanook
Group=nanook

[Install]
WantedBy=multi-user.target

For macOS use a launchd plist; for Windows use the service manager (sc create). The binary is the same on each.

Verifying it works

nanook check --config /etc/nanook/nanook.toml

check parses your config, builds every collector, adapter, action, and rule, and exits zero if it's all good. No metrics get collected, nothing fires. Use it before reloading a live agent so a typo never takes down monitoring.

Verifying the release

install.sh does this for you. Manual flow:

nanook self trust add https://codeberg.org/cstef/nanook/raw/branch/main/keys/release.pub
nanook self verify

What this proves and what it doesn't: the signature check matches the binary on disk against the publisher key, which catches corruption in transit and an unsigned or wrong-signer build. It does not prove that an already-malicious binary is genuine, because the verifier and the artifact are the same bits — a tampered binary can fake the verdict. Bootstrapping the very first install rests on trust in how you fetched the binary and the key URL above, not on this command. From there on, nanook self update is the verification path with real teeth: the running (presumed-trusted) nanook verifies the new candidate before swap, so verifier and artifact are different bits. See Trust for the full picture.

nanook self update --skip-trust bypasses the signature check on update; use only when you have anchored trust outside nanook (e.g. distro-packaged binary already verified by your package manager).

Next: Quickstart.