Install

Drop the binary on a host, point it at a config, run it.

nanook ships as a single static binary — drop it on a host and run it.

Quick install

The install script automates: detect arch, fetch release tarball from codeberg, verify sha256, extract binary, pick writable $PATH dir, copy, confirm version, bootstrap trust key. Review the source at /install.sh.

Inspect first (recommended)

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

One-liner

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

Flags and env

Env / flag	What
`NANOOK_VERSION=v0.1.0` or `--version v0.1.0`	pin a release tag (default: latest)
`NANOOK_INSTALL_DIR=/opt/bin` or `--dir /opt/bin`	install location
`NANOOK_PRESET=slim` or `--preset slim`	build preset: `full`, `server`, `slim`, `minimal` (default: `full`)
`NANOOK_REPO=owner/repo`	source repo (default: `cstef/nanook`)
`NANOOK_BASE_URL=https://git.example.com/owner/repo`	full base URL for any Forgejo/Gitea host
`NANOOK_OS`, `NANOOK_ARCH`	override platform detection
`NANOOK_SKIP_VERIFY=1` or `--skip-verify`	skip sha256 check (use only for offline mirrors)
`NANOOK_NO_TRUST=1` or `--no-trust`	skip release-key trust bootstrap
`NO_COLOR=1`	plain text output

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:

curl -fsSL https://nanook.cstef.dev/install.sh -o install.sh
NANOOK_VERSION=v0.1.0 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:

Preset	What it includes	Stripped size (x86_64)
`preset-full` (default)	every collector / adapter / action, admin server + ctl, tui dashboard, tls, discover, installer, plugins	5.7 MB
`preset-server`	full collector / adapter / action set, admin server + tls, plugins; no tui / discover / installer	5.4 MB
`preset-slim`	core system collectors (cpu/mem/disk/net/load/uptime), prometheus + stdout adapters, log action, admin (no tls)	3.7 MB
`preset-minimal`	cpu + mem collectors, stdout adapter, log action; no admin / tui / plugins	1.7 MB

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:

Feature	What it gates	Default
`admin`	REST/WS server + `nanook ctl` client	on
`tui`	`nanook tui` dashboard + interactive `nanook init` wizard	on
`tls`	admin TLS (rustls + `--ca` flag)	on
`discover`	`nanook discover` subcommand + interactive picker	on
`installer`	`nanook install` / `uninstall` / `update` subcommands	on
`plugins`	dynamic plugin loading + `nanook plugins` subcommand surface	on

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

Thing	Default
Binary	wherever you put it
Config	resolved in this order: explicit `--config <path>` → `./nanook.toml` → `~/.nanook/nanook.toml` → `/etc/nanook/nanook.toml`. When none of those exist, write-side commands (`nanook init`, `nanook self trust add`, etc.) default to `~/.nanook/nanook.toml`.
Plugin search	the `[plugins].dirs` array in your config
Admin HTTP	disabled by default; set `[admin].enabled = true` and `[admin].addr` to expose it
Admin Unix socket	disabled by default; set `[admin].socket` to a path to expose it

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, save a launchd plist and load it:

sudo nano /Library/LaunchDaemons/dev.nanook.plist
sudo launchctl load /Library/LaunchDaemons/dev.nanook.plist

For Windows, register with the service manager:

sc create nanook binPath= "C:\Program Files\nanook\nanook.exe --config C:\ProgramData\nanook\nanook.toml"

The binary is the same on every platform.

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 the check proves

The signature check matches the binary on disk against the publisher key — this 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 trust

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. a distro-packaged binary already verified by your package manager).