Platforms

Platform Support

Understand how Wenlan runs on macOS, Linux, and Windows: service managers, local data paths, model backends, and Docker/VM caveats.

Qi-Xuan LuUpdated Jul 2, 20265 min read

At a glance

Wenlan's released runtime supports macOS arm64/x64, Linux x86_64/aarch64 with glibc, and Windows x86_64.

The daemon contract is the same across platforms, but service registration, data paths, and model acceleration differ.

Supported platforms

Wenlan v0.7.0 broadened the local runtime from macOS-first to cross-platform support across macOS, Linux, and Windows.

The same daemon, CLI, and MCP connector shape applies on each platform. The operating-system integration is what changes.

Runtime matrix

macOS    arm64, x64              launchd user agent
Linux    x86_64, aarch64 glibc  systemd user unit
Windows  x86_64                 Task Scheduler ONLOGON task

Service registration

Wenlan installs as a per-user service so the local daemon can be available to MCP clients without a manual terminal session.

macOS uses launchd. Linux uses a systemd user unit. Windows uses a per-user Task Scheduler ONLOGON task.

Data paths

The daemon keeps its database and application data in the OS application data location. Wenlan also exposes human-readable artifacts under ~/.wenlan so pages, sessions, status records, and local git history are easy to inspect.

Treat both locations as private application data. They can contain project decisions, preferences, client context, and old versions.

Data locations

macOS:   ~/Library/Application Support/wenlan/
Linux:   ~/.local/share/wenlan/ or $XDG_DATA_HOME/wenlan/
Windows: %LOCALAPPDATA%\origin\ (current runtime legacy directory)

Readable artifacts: ~/.wenlan/

Model backends

The core memory loop does not require a local model or API key. Store, embed, search, recall, MCP context, and the agent-side workflow still work without configuring daemon-side language models.

For optional local model paths, macOS keeps Metal acceleration. Linux and Windows release builds are CPU-only by default in the current public shape.

Docker and VMs

Normal laptop use should keep the daemon bound to 127.0.0.1:7878. That keeps the HTTP API local to the machine.

Use WENLAN_BIND_ADDR only when you intentionally need non-loopback access, such as a Docker or VM setup. Exposing the daemon changes the security boundary, so pair it with the security reporting and configuration guidance.

Bind address

WENLAN_BIND_ADDR=127.0.0.1:7878
WENLAN_BIND_ADDR=0.0.0.0:7878  # Docker or VM only

After setup

Whatever platform you use, verify setup the same way: run wenlan status and wenlan doctor, then do one capture/recall round trip from the client you care about.

If the daemon works but an MCP client does not, restart the client and rerun wenlan mcp add for that client before assuming the runtime is broken.

HTTP API

Know the local daemon surfaces that the CLI, MCP connector, plugin, and local tools call under the hood.