meshfox

ghcr.io/orofarne/meshfox runs meshfox serve --http (see "Serving canvases over HTTP" in INTERFACES.canvas.md) on Debian 13, for linux/amd64 and linux/arm64. Mount the directory with your canvases at /work:

docker run --name meshfox --user "$(id -u):$(id -g)" \
  -p 127.0.0.1:4590:4590 -e MESHFOX_TOKEN=change-me \
  -v "$PWD":/work ghcr.io/orofarne/meshfox

or, with Python, Node.js and Chromium in the image:

docker run --name meshfox --user "$(id -u):$(id -g)" \
  -p 127.0.0.1:4590:4590 -e MESHFOX_TOKEN=change-me \
  -v "$PWD":/work ghcr.io/orofarne/meshfox:full

Open http://localhost:4590/ and sign in with the token. Without MESHFOX_TOKEN the container generates one and prints it once, in the output above (or in docker logs meshfox if you run it detached with -d). Publish the port on 127.0.0.1 unless you mean to expose it, and read the security notes above first: the token is a shell on the container.

• Tags. slim (the default: latest, X.Y.Z, X.Y, slim) is meshfox, bash, git, curl, DuckDB (for display="table") and tini. full (X.Y.Z-full, X.Y-full, full) adds Python 3 with venv and pip, Node.js with npm, and Chromium (for meshfox pdf; its sandbox is off in the image, the container is the boundary: MESHFOX_CHROME_NO_SANDBOX=1). A pre-release gets only its exact tags.
• User. --user "$(id -u):$(id -g)" makes blocks write files as you. Without it the container runs as uid 1000. Nothing in the image is world-writable: the home directory (/tmp/meshfox-home, which holds ~/.meshfox — config, plaintext secrets, session state) and the coordinator's socket (/tmp/meshfox/) are created at start by whichever uid runs it, so mount a volume at /tmp/meshfox-home if that state should outlive the container.
• Driving it from the host. MESHFOX_SERVER_SOCKET is set inside the image, so docker exec -it meshfox meshfox tui /work/notes.canvas.md, … run … and … cores ls talk to the serve that is already running instead of starting their own. Paths are the container's (/work/...). Mount the directory at the path you use on the host if you want the two to match.
• Opening canvases. meshfox view / cores open inside the container print the address (meshfox serve: open http://localhost:4590/c/<slug>/), since there is no browser. Pass --public-url (after the image name) when you reach it by another address.
• Behind a reverse proxy, add --trust-proxy and --allowed-host to the command: docker run … ghcr.io/orofarne/meshfox serve --http 0.0.0.0:4590 --root /work --trust-proxy --allowed-host notes.example.
• Updating means pulling a newer image and recreating the container: meshfox check-updates says so instead of replacing the binary.

The image wraps the binary from the GitHub release of the same tag. To build one yourself: docker build -f docker/Dockerfile --build-arg MESHFOX_VERSION=0.27.0 --target slim -t meshfox:slim docker/ (or --target full); docker/smoke.sh <image> slim|full <version> runs the checks CI runs before it pushes. The Debian base has to be at least as new as the release runners' glibc (2.39), which is why it is 13 (trixie) and not 12. .github/workflows/docker.yml builds both variants natively on both architectures and publishes the multi-arch manifests after a release; run it by hand with push off for a dry run.

There is no native Windows build; meshfox runs on Windows inside WSL2, as the Linux binary. scripts/meshfox-wsl.ps1 does the setup and starts meshfox serve --http (see "Serving canvases over HTTP" in INTERFACES.canvas.md) for you. In PowerShell:

.\scripts\meshfox-wsl.ps1 -CanvasDir D:\notes

On every run it:

1. checks that WSL and the distribution (-Distro, default Ubuntu-24.04) are installed, and installs the distribution if not (finish its first-run setup, then run the script again);
2. installs meshfox into ~/.local/bin inside the distribution with scripts/install.sh, or runs meshfox check-updates -y if it is already there (-SkipUpdate skips the check);
3. installs the DuckDB CLI (for display="table") with its official installer, which always puts it in ~/.duckdb/cli/<version>/, and passes that path to meshfox as MESHFOX_DUCKDB; -DuckDbVersion 2.0.0 pins a version instead of the latest stable;
4. creates an access token once and keeps it in %LOCALAPPDATA%\meshfox\token, so the sign-in does not change between runs;
5. runs meshfox serve --http 127.0.0.1:4590 --root <canvas dir> in the foreground and opens http://localhost:4590/ in the Windows browser (-Port changes the port, -NoBrowser skips opening it). Ctrl+C stops it; while the window is open WSL does not shut the distribution down.

• Distribution. The release binary needs glibc 2.39 or newer: Ubuntu 24.04 or Debian 13, not Ubuntu 22.04 or Debian 12. It is the same binary as on any Linux, so nothing is rebuilt for WSL.
• Canvases on the Windows drive. -CanvasDir is a Windows path, reached as /mnt/c/... (or /mnt/d/...) from WSL, so the files can be opened from Windows tools too. That filesystem is much slower for tree walks than the distribution's own (see "Serving canvases over HTTP" in INTERFACES.canvas.md; add a .meshfoxignore for big trees), and file-change events from Windows-side edits may not reach the watchers. For many files, keep the canvases inside the distribution and open them from Windows as \\wsl$\<distro>\... instead.
• Socket. The coordinator's socket is ~/.meshfox/serve.sock inside the distribution, not on /mnt/c, where unix sockets and mode 0600 are unreliable. To drive it from a WSL shell (meshfox tui, cores ls, run), set MESHFOX_SERVER_SOCKET=$HOME/.meshfox/serve.sock there.
• Not available. There is no systemd in this setup (the script runs serve itself), the macOS menu-bar app is macOS only, and secret_store = "keychain" needs a Secret Service (gnome-keyring, dbus-user-session) running in the distribution; without one, keep the default plaintext.