Installer reference

For anyone putting the install into configuration management, or who wants to read it before running it. The script itself is at https://dev.uptimecraft.com/install.sh and is meant to be read.

Variables

There is no variable that skips verification, of either the signature or the checksum. A switch that turns verification off is a switch that ends up turned off.

What lands where

The token is in a file rather than in the unit (world-readable) or on the command line (visible in ps to every user on the machine).

The agent's own options

The installer writes /etc/uptimecraft/agent.env and the unit reads it, so you will not normally touch these. Each is a flag with an environment variable behind it; the variable is what belongs in agent.env.

The enrollment token is only ever an environment variable, never a flag. A credential on the command line is visible in ps to every user on the machine.

The service

Runs as uptimecraft, Restart=always, and confined by systemd: NoNewPrivileges, ProtectSystem=strict, PrivateTmp, PrivateDevices, ProtectKernelTunables, ProtectKernelModules, ProtectControlGroups, RestrictAddressFamilies to IP only, and MemoryMax=128M with CPUQuota=10%.

The limits are generous by an order of magnitude for what it does. They exist so that an agent misbehaving is an agent that gets stopped, not one that takes your server with it.

Installing at scale

The installer is idempotent, so it can go straight into whatever you already use. One token, left with unlimited uses until it expires.

Ansible: fetch the script, then run it with the token from your vault, with a creates: guard on /usr/local/bin/uptimecraft-agent or a version check if you want converges to upgrade.

cloud-init: a runcmd entry with the token from your secret store. First boot is the right moment — see below.

Packer and golden images: install the binary and the unit, but do not enrol. Leave the token out of the image and supply it on first boot. An image that enrolled before being captured produces clones that all share one identity, and each one lands in Pending approval instead of being monitored.

Kubernetes: this agent monitors machines, not containers. Running it in a pod reports the node's figures from inside a namespace that may or may not see them correctly. Install it on the nodes, with whatever manages the nodes.

Verifying a release by hand

curl -fsSLO https://get.uptimecraft.com/agent/latest/uptimecraft-agent_linux_amd64.tar.gz
curl -fsSLO https://get.uptimecraft.com/agent/latest/SHA256SUMS
curl -fsSLO https://get.uptimecraft.com/agent/latest/SHA256SUMS.sig
curl -fsSL https://dev.uptimecraft.com/install.sh | sed -n '/BEGIN PUBLIC KEY/,/END PUBLIC KEY/p' > release.pub

openssl dgst -sha256 -verify release.pub -signature SHA256SUMS.sig SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

Both must pass. Verified OK from the first proves the checksum file is ours; the second proves the archive matches it.

Every release is built in CI from a tagged commit, signed with a key that exists only there, and then — as the last step of the release — downloaded anonymously and verified again, the way you would. A release that a stranger cannot install and verify does not get published.