Building From Source

Building from a git clone gets you the latest, possibly-unreleased code, useful if you’re contributing or want a fix that hasn’t shipped in a release yet. Just want the last published version, without cloning anything? See Install with Cargo.

git clone https://github.com/emmaglorypraise/ObsidianLog
cd ObsidianLog

Building

Default (local test)
With Sia

cargo build --release

Builds the whole workspace without Sia support. obsidianlog init still defaults to the local backend, and serve/query/verify work fully against it. Sia isn’t reachable from this build at all: if a config points at a Sia indexer anyway, those commands fail with a clear error instead of silently using local storage.

cargo build -p obsidianlog-cli --release --features sia

Builds obsidianlog with Sia support included. The official release binaries already include this, so most people don’t need this command at all, it only matters if you’re building from source.

Either way, the binary lands at target/release/obsidianlog. Want it on your PATH instead of just built locally? Use cargo install --path crates/obsidianlog-cli (add --features sia for Sia support) to install it into your Cargo bin directory.

Testing

# Default features: the Sia code isn't compiled or exercised.
cargo test --workspace

# Everything, including the Sia integration code paths.
cargo test --workspace --all-features

See Contributing for the full set of checks CI runs before a PR is reviewed. --all-features compiles and exercises the Sia code paths, but skips the live-network test without real credentials. To actually run it against a real Sia indexer, see Testing Against a Live Sia Indexer.

Feature flags

Flag	What it enables	Default
`sia`	The real Sia backend for `serve`/`query`/`verify`, and the `onboard` example used to connect an app to a Sia indexer. Without it, a Sia-configured install fails with a clear error rather than silently falling back to local.	Off

Sia is kept behind a flag instead of being on by default because the underlying SDK is pre-1.0. See ADR-0006 for the full reasoning, it’s not required reading to use this page.

Running the standalone ingest server directly

obsidianlog-ingest is a standalone binary you can run without the CLI. Unlike obsidianlog serve (which manages the key for you), the standalone binary never reads its encryption key from the config file. It refuses to start until you pass one via OBSIDIANLOG_ENCRYPTION_KEY (a 64-character hex string) or OBSIDIANLOG_ENCRYPTION_KEY_FILE (a path to a file containing that string, the convention for a mounted Docker/Kubernetes secret):

OBSIDIANLOG_ENCRYPTION_KEY=$(openssl rand -hex 32) ./target/release/obsidianlog-ingest

The obsidianlog CLI’s init/serve manage this key for you instead. See obsidianlog init and obsidianlog serve.

Get Started

Tutorials

Using the CLI

Storage Backends

Deployment

Integrations

Architecture & Security

Contributing & Support

Building

Testing

Feature flags

Running the standalone ingest server directly

​Building

​Testing

​Feature flags

​Running the standalone ingest server directly

Building

Testing

Feature flags

Running the standalone ingest server directly