Installation

Every release archive contains two binaries:

• sealr — the recorder. Proxies, hooks, the CLI wrapper, export.
• sealr-verify — the offline verifier for .seal bundles. No network, no trust in us.

They are self-contained. There is no installer, no daemon, no background service.

Install

Archives are named sealr-<version>-<target>.tar.gz (.zip on Windows) and unpack into a directory of the same name holding the two binaries. Replace 0.1.0 with the version you downloaded.

VERSION=0.1.0
TARGET=aarch64-apple-darwin
curl -fsSLO "https://github.com/sealr-labs/sealr/releases/download/v${VERSION}/sealr-${VERSION}-${TARGET}.tar.gz"
tar xzf "sealr-${VERSION}-${TARGET}.tar.gz"
sudo install -m 0755 "sealr-${VERSION}-${TARGET}/sealr" /usr/local/bin/sealr
sudo install -m 0755 "sealr-${VERSION}-${TARGET}/sealr-verify" /usr/local/bin/sealr-verify
sealr --version

mkdir -p ~/.local/bin
install -m 0755 "sealr-${VERSION}-${TARGET}/sealr" "sealr-${VERSION}-${TARGET}/sealr-verify" ~/.local/bin/
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc

xattr -d -r com.apple.quarantine "sealr-${VERSION}-${TARGET}"

Confirm it works

sealr --version
sealr-verify --version

sealr version additionally prints how updates work. Neither command touches the network or creates any state.

The next command, sealr init, is where the recorder writes its home directory and a local identity. That is covered in the quickstart — five minutes to a recorded, blocked operation, no account.

Platform limits

Stated plainly, because finding out at deploy time is worse:

• Linux ARM has no published build. The release matrix covers x86_64 Linux, both macOS architectures and x86_64 Windows. On aarch64 Linux — Graviton, ARM CI runners, a Pi — build from source.
• The Linux binary is glibc-linked, not static. It is built on GitHub's ubuntu-latest runner, so it will not run on a distribution with an older glibc (Debian 12, RHEL/UBI 8, Amazon Linux 2) or on musl (Alpine). Build from source there, or run on a newer base. A missing or too-old glibc shows up as version 'GLIBC_2.xx' not found on first run.
• 32-bit is not supported on any platform.

Upgrading

There is no sealr self-update, and there will not be one. To upgrade, download the new archive, verify it, and overwrite the binaries — the same steps as a first install.

VERSION=0.2.0
TARGET=x86_64-unknown-linux-gnu
curl -fsSLO "https://github.com/sealr-labs/sealr/releases/download/v${VERSION}/sealr-${VERSION}-${TARGET}.tar.gz"
tar xzf "sealr-${VERSION}-${TARGET}.tar.gz"
sudo install -m 0755 "sealr-${VERSION}-${TARGET}/sealr" /usr/local/bin/sealr
sudo install -m 0755 "sealr-${VERSION}-${TARGET}/sealr-verify" /usr/local/bin/sealr-verify

Why no self-update. A self-updater is a permanent remote code execution channel into every host that runs the recorder, triggered by a server we control. Sealr's whole claim is that it records what your agents actually did; a binary that can silently replace itself is exactly the component an attacker would target to break that claim, and you would have no opportunity to check what arrived. Manual replacement keeps the checksum and provenance check in your hands, on your schedule, once per version.

Practical notes:

• Replacing the binary does not touch the recorder home. Config, identity key and spooled records stay where they are.
• Long-running processes keep the old binary. Restart any sealr proxy mcp process — in practice, restart the agent — for the new version to take effect.
• To find out whether there is a newer release: watch the releases page, or run gh release list -R sealr-labs/sealr -L 5.

Uninstall

sudo rm -f /usr/local/bin/sealr /usr/local/bin/sealr-verify

Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Programs\sealr"

rm -rf ~/.local/share/sealr

Next