# Installation

> The npm launcher, the direct binary download, the supported platforms, and how to check the version.

Canonical URL: https://www.slivingdoc.dev/docs/installation/ · Version: 0.1 · Updated: 2026-09-21

Full site index: https://www.slivingdoc.dev/llms.txt

slivingdoc is one native executable. There are two ways to get it: the
npm launcher, which most MCP hosts can start for you, and a direct
download of the release binary.

## The npm launcher

The `slivingdoc` npm package contains no native code. It selects the
binary for its own exact version and for your platform, downloads it from
the matching GitHub release, verifies the published SHA-256, caches the
verified bytes, and then runs the binary with your arguments:

```text
export SLIVINGDOC_BUCKET=my-notes
npx -y slivingdoc version
npx -y slivingdoc serve
```

Requirement: Node.js 22 or newer, on one of the supported platforms
below. An unsupported platform fails before any download, with an error
that names the supported targets.

This is the form to put in an MCP host configuration. The host starts the
launcher as a child process, and the launcher becomes the server:

- Arguments are forwarded to the binary as written, and standard input
  stays connected.
- The launcher never writes to standard output. Standard output belongs
  to the MCP protocol and to the binary; launcher diagnostics go to
  standard error.
- The binary's exit status, or its terminating signal, becomes the
  launcher's.

### The cache

Downloads live under the npm cache, at a path specific to the version,
the operating system, the architecture, and the asset, and they are
verified again on every run. A corrupt or partial download is deleted and
fetched again; it is never executed. Transient network failures are
retried with exponential backoff, and a missing release asset is reported
at once.

| Variable                  | Effect                                                                  |
| ------------------------- | ----------------------------------------------------------------------- |
| `SLIVINGDOC_CACHE`        | Use this directory as the cache root instead of npm's.                  |
| `SLIVINGDOC_RELEASE_BASE` | Fetch release assets from a mirror of the GitHub release download URLs. |

> **Tip:** A machine that must not reach GitHub at run time can be
> pre-warmed once, or pointed at an internal mirror with
> `SLIVINGDOC_RELEASE_BASE`. The checksum is still verified on every run.

## Supported platforms

| Operating system | Architectures                                                 |
| ---------------- | ------------------------------------------------------------- |
| Linux            | `amd64`, `arm` (32-bit ARMv7, Raspberry Pi OS armhf), `arm64` |
| macOS            | `amd64`, `arm64`                                              |
| Windows          | `amd64`                                                       |

## Direct download

Every release publishes one binary per target, plus a `SHA256SUMS`
checksum file and the third-party `NOTICE`. The asset name is
`slivingdoc-v<semver>-<os>-<arch>`, with `.exe` added on Windows. The
operating-system values are `linux`, `darwin`, and `windows`; the
architecture values are `amd64`, `arm`, and `arm64`.

Download the asset for your platform from the
[GitHub releases page](https://github.com/baalimago/slivingdoc/releases),
check it against the `SHA256SUMS` line for that asset, make it
executable, and run it in place. The binary is self-contained: it needs
no libgit2, no Git executable, and no toolchain on the target machine.

## Check the version

```text
slivingdoc version
```

`version` prints `slivingdoc <semver>` and exits. It touches nothing
else: no bucket, no network, no configuration. It is the safe first
command after an install, and the one to put in a support report.

## Build from source

Building the native executable yourself means building the pinned
libgit2 first — the repository's
[`docs/build.md`](https://github.com/baalimago/slivingdoc/blob/master/docs/build.md)
is the procedure, from the pinned source tarball to the dependency
check. There is no pure-Go build: the Git engine needs CGo, so a build
with CGo disabled fails to compile instead of producing an executable
that starts and then fails every operation.

## Next

- [Quickstart](/docs/quickstart/) — from nothing to a shared notebook.
- [Connect an MCP host](/docs/guides/mcp-hosts/) — where the launcher
  command goes for each host.
- [Configuration](/docs/reference/configuration/) — every flag,
  environment variable, and default.