Install

Nauka is a single binary called nauka (~18 MB). It has no runtime dependencies, no configuration file and no database to provision: everything a node needs lives in its data directory. The engine serves an HTTP API and nothing else — there is no bundled web interface.

The install script

curl -sSfL https://sh.getnauka.com | sh

The script detects your platform, resolves the latest published release, downloads the matching tarball, verifies its SHA256 checksum against the SHA256SUMS.txt published with the release, and moves the binary into /usr/local/bin (escalating with sudo only if that directory is not already writable).

Then, on a systemd Linux run as root, it finishes the job: it runs nauka init, which creates a dedicated nauka user, writes the cluster identity into /etc/nauka/nauka.env, installs a hardened systemd unit and starts it. The machine is the first node of a new cluster, back after every reboot, restarted on failure. That is why the canonical flow is two commands:

# first machine — installs nauka AND founds the cluster:
curl -sSfL https://sh.getnauka.com | sh

# grow it from that machine — provisions the target over SSH and joins it:
nauka node add <ip>:7311

Set NAUKA_NO_INIT=1 to keep the script to the binary alone. Without root, without systemd, or on macOS, the script installs the binary and stops there — found the cluster yourself when you are ready:

sudo nauka init

A machine that already runs the service is never re-founded: the script replaces the binary and tells you to systemctl restart nauka to pick it up.

Check that it worked:

nauka --help

Updating

The binary updates itself:

nauka update           # install the latest release
nauka update --check   # only tell whether one exists

update queries the latest release, downloads the tarball for the current platform, verifies its SHA256 against the published SHA256SUMS.txt and swaps the binary atomically (written next to it, then renamed over — the running process keeps its inode). A running node keeps executing the old version until it restarts — on a systemd deployment, follow with systemctl restart nauka. If the binary lives in a root-owned directory, run sudo nauka update.

Re-running the install script performs the same upgrade; nauka update is the same thing without a shell pipeline, usable from cron or a fleet runner.

Environment variables

The script reads four variables, all optional:

Variable	Default	Effect
VERSION	latest release	Install a specific tag, e.g. VERSION=v0.5.24. Also the escape hatch when the GitHub API is unreachable.
INSTALL_DIR	/usr/local/bin	Where the binary is placed.
NO_SUDO	unset	Set to 1 to never escalate. If the target directory is not writable, the binary falls back to ~/.local/bin.
NAUKA_NO_INIT	unset	Set to 1 to only install the binary — the script then never runs nauka init, even as root on a systemd Linux.

# Pin a version, install for the current user only, do not found anything
curl -sSfL https://sh.getnauka.com | VERSION=v0.5.24 NO_SUDO=1 NAUKA_NO_INIT=1 sh

Reading the script before running it

Piping a script into a shell is only as trustworthy as the host serving it. curl -sSfL https://sh.getnauka.com prints the script instead of running it — it is under 200 lines, and it is the same file as install.sh in the repository.

Packages

Linux packages are attached to every GitHub release, for x86_64 and aarch64. They install the binary in /usr/bin/nauka, add the systemd unit, create an unprivileged nauka system user, and prepare /etc/nauka for the cluster identity and /var/lib/nauka for the data.

Debian / Ubuntu

# Download the .deb for your architecture from the releases page
curl -fsSLO https://github.com/sifrah/nauka/releases/latest/download/nauka_0.5.24-1_amd64.deb

# apt resolves dependencies; dpkg -i also works
sudo apt install ./nauka_0.5.24-1_amd64.deb

Fedora / RHEL

curl -fsSLO https://github.com/sifrah/nauka/releases/latest/download/nauka-0.5.24-1.x86_64.rpm

sudo dnf install ./nauka-0.5.24-1.x86_64.rpm

The package installs but does not found a cluster and does not start the service: a node with no cluster identity would run unauthenticated. Give it one first — put a token (nauka token) in /etc/nauka/nauka.env as NAUKA_TOKEN=, or copy the cluster’s key files into /etc/nauka — then systemctl enable --now nauka. The full flow is on Deploy a cluster. Machines added with nauka node add need none of this: provisioning installs the binary, the unit and the identity in one go.

From source

1. Install Rust (stable).

2. Clone the repository:

   git clone https://github.com/sifrah/nauka
   cd nauka

3. Build the binary:

   cargo build --release

   It lands in target/release/nauka. Copy it wherever you keep local binaries.

   The S3-compatible endpoint is a compile-time feature, off by default — the released binaries do not carry it. If you want it:

   cargo build --release --features s3

4. Optionally, run the test suite — it spins up real QUIC clusters on loopback, kills nodes and corrupts shards:

   cargo test --workspace

Rebuild before you benchmark

cargo test --release does not rebuild the binaries used by the integration tests. Run cargo build --release -p nauka-node first, or you will be measuring a stale binary — a mistake that cost us an hour, recorded in Design decisions.

Verifying provenance

Every release artifact carries a signed build provenance attestation produced by the release workflow. It ties the file you hold to the exact workflow run and the exact commit that built it:

gh attestation verify nauka-0.5.24-x86_64-unknown-linux-gnu.tar.gz \
  --repo sifrah/nauka

A successful verification means the bytes on your disk were produced by .github/workflows/release.yml in sifrah/nauka, at a specific commit, signed by GitHub’s transparency log at build time. Nobody — not even someone holding the repository’s credentials — can retroactively forge that record for a file built elsewhere.

Checksums alone prove nothing

SHA256SUMS.txt is served from the same release page as the binaries. An attacker who can replace a binary can replace the checksum file next to it, and both will agree. Checksums protect against a truncated download, not against a compromised release. Attestations are the only check here that survives the release page itself being tampered with — use them for anything you are about to run as a service.

Supported platforms

Platform	Target
Linux, x86_64 (glibc)	x86_64-unknown-linux-gnu
Linux, aarch64 (glibc)	aarch64-unknown-linux-gnu
macOS, Intel	x86_64-apple-darwin
macOS, Apple Silicon	aarch64-apple-darwin

Linux builds are produced on Ubuntu 22.04, which sets the oldest glibc supported. There is no musl build yet, so Alpine and other musl distributions need a source build. Windows is not supported; build from source under WSL if you need it. nauka init needs a systemd Linux — elsewhere it refuses and tells you so; macOS machines can still run every client command and serve by hand.

Next

Installing a binary is not deploying a cluster: the interesting part is the cluster identity, the ports, and how many machines you need before losing one stops mattering. That is Deploy a cluster.