Skip to content

Development

Build from Source

Build the Wenlan daemon, CLI, MCP server, shared types, core crate, and plugin from the public repository.

Qi-Xuan LuUpdated 5 min read

At a glance

01

The main repo is a Rust workspace with wenlan-core, wenlan-server, wenlan CLI, wenlan-mcp, and wenlan-types.

02

Use the source build path for development; most users should install through the plugin or npx setup.

01

When to build

Build from source when you are developing Wenlan, testing a branch, debugging the daemon, or preparing a contribution.

If you only want to use Wenlan, install through the Claude Code plugin or npx setup instead. The release path installs prebuilt binaries into ~/.wenlan/bin.

02

Workspace build

The repository is a Cargo workspace. First builds can take several minutes, especially on macOS where llama.cpp compiles with Metal support.

Run the daemon directly during development. For product-path testing, build release binaries and use wenlan setup, install, status, and doctor.

Source build

git clone https://github.com/7xuanlu/wenlan.git
cd wenlan
cargo build --workspace
cargo run -p wenlan-server

# before a PR
cargo fmt --check --all
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

03

Crate boundaries

wenlan-core owns business logic and must stay free of Axum and Tauri dependencies. wenlan-server frames HTTP requests. wenlan-types stays lightweight because downstream clients consume it.

wenlan-mcp bridges MCP clients to the daemon. wenlan CLI manages setup, service state, recall, search, store, spaces, models, keys, and doctor checks.

04

Platform notes

Wenlan supports macOS arm64/x64, Linux x86_64/aarch64 with glibc, and Windows x86_64. The service manager differs by platform: launchd, systemd user units, or a Task Scheduler logon task.

Linux and Windows builds are CPU-only by default. macOS keeps Metal acceleration for local model paths.

05

Before opening a PR

Keep changes focused and evidence-backed. Add or update tests for behavior changes, run the relevant checks, and avoid unrelated refactors.

Docs changes should remove ambiguity or stale public language. Eval changes should follow the repository's citation discipline instead of publishing unsupported headline claims.

Read CONTRIBUTING.md

Next

Testing and CI

Understand which Wenlan checks run locally, which run in GitHub Actions, and which evals stay manual.

Read next