Install DeepSeek Harness on ARM: DSH plugin native deps

Installing DeepSeek Harness on ARM is less about whether it runs and more about which route you pick. The three arm64 environments differ: the CLI path works almost everywhere because it is a Node tool, the desktop app generally exists only for Apple silicon, and the real blocker is DSH plugin native dependencies — a plugin with native modules and no arm64 artifact must compile on a Raspberry Pi, which is slow and prone to OOM. So the right sequence on ARM is choose a route first (local CLI, containerized build, or remote host with a local client), then decide which plugins to install.

Three things to check before installing DeepSeek Harness on ARM

Bottom line: on ARM, check only three numbers — a supported Node version, enough memory to install dependencies, and whether your target DSH plugin ships arm64 artifacts. If any fails, change route before installing.

1. Node version: run node -v and compare against the engines requirement in the official CLI docs and npm package page.
2. Memory and disk: dependency installation peaks in memory. On devices under 4 GB, enable swap first.
3. Plugin artifacts: check the dependency notes for your target DSH plugin in DSH Plugin Hub — faster than discovering it mid-install.

Path A: install the DeepSeek Harness CLI directly on ARM

Bottom line: when Node is supported and your plugins have arm64 artifacts, the plain CLI is the leanest route — no container layer, no emulation overhead.

1. Install Node with your distro package manager or nvm, then confirm the architecture:

uname -m        # expected: aarch64 or arm64
node -v && npm -v

2. Install the DeepSeek Harness CLI globally:

npm i -g @deepseek-ai/dsh
dsh --version

3. Fix the data directory on internal storage, not a slow SD card partition:

export DSH_HOME="$HOME/.dsh"
mkdir -p "$DSH_HOME"

4. Install DSH plugin packages one at a time with dsh plugin add, verifying each. This lowers the memory peak and isolates the incompatible one.
5. Start dsh web if you need the UI, checking flag names with dsh web --help and limiting concurrent sessions on low-power devices.

Path B: containerize to normalize ARM differences

Bottom line: containers turn "every plugin install might fail" into "solved once at build time" — the biggest win on boards you rebuild often.

1. Build on the matching architecture to avoid emulation:

docker build --platform linux/arm64 -t dsh-arm:0.2.0-rc.2 .

2. Do heavy work at build time: preinstall DSH plugin packages in the image so the running container only starts. This removes runtime compilation, the worst risk on low-power boards.
3. Mount data and workspace volumes so state survives container deletion (see installing DeepSeek Harness in Docker).
4. Use emulation only when you truly need x86 artifacts (--platform linux/amd64 on arm64), and expect slower CPU-bound work, higher memory use and more OOM risk.

Path C: run DeepSeek Harness remotely, use ARM as a client

Bottom line: on a genuinely low-spec board, run DeepSeek Harness on a server and use the board through a browser. You keep the portability and lose the hardware limit.

1. Server side: install DeepSeek Harness and start dsh web bound to an address reachable on your network.
2. Client side: open the address in the board's browser and install nothing — this removes nearly every dependency trap on that device.
3. Two networking options: direct access on the same LAN (see accessing dsh web on your LAN) or a reverse proxy with HTTPS (see dsh web behind a reverse proxy).
4. Stated cost: the session lives on the server, so no network means no access, and the board cannot touch its own files. Choose paths A or B if local files matter.

DSH plugin native dependencies on ARM: three ways to handle them

Bottom line: when arm64 artifacts are missing, try in this order — swap the plugin, add a toolchain, then cross-architecture hosting. The first is cheapest; the last costs the most.

1. Swap the plugin (preferred). The same need often has multiple implementations; pick a pure-JavaScript one or a version with arm64 artifacts. Find candidates by scenario in the Hub instead of guessing names.
2. Install a toolchain and compile. Run sudo apt-get install -y build-essential python3 then reinstall. Expect long builds and half-finished artifacts after an OOM, so enable swap first:

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
free -h      # expected: the Swap line shows the new size

3. Host the x86 part elsewhere and keep only non-native plugins on the board.
4. Verify after install: list the plugin and actually call its core function. The classic ARM failure is "installed but reports an architecture mismatch at runtime."

Running DeepSeek Harness on low-power ARM devices

Bottom line: subtract — fewer concurrent sessions, fewer DSH plugins, shorter conversations. Prefer "it runs" over "feature complete."

1. Fewer concurrent sessions: minimize simultaneous sessions, subagents and background jobs; move heavy work off the device.
2. Fewer plugins: uninstall everything unrelated; more plugins means more load and index work at startup.
3. Shorter sessions: long conversations cost the most memory and rendering time on low-power devices. Split them or compact context.
4. Measure before cutting: free -h and top tell you whether CPU or memory is the bottleneck.

DSH plugin troubleshooting on ARM

Bottom line: nine out of ten ARM failures are architecture or dependency problems, not configuration. Look for an architecture or compile hint in the error before choosing a path.

1. Architecture mismatch (incompatible architecture, wrong ELF class) — swap the plugin or host it elsewhere.
2. Compile failure — add the toolchain and swap, or abandon source compilation on this device.
3. Process killed — OOM; enable swap, batch installs, remove plugins.
4. Installs but fails at runtime — suspect Node or npm running as an x64 build under translation; switch to native arm64 builds.
5. Simply slow — identify CPU versus memory first, then apply the right subtraction.
6. Repair status, stated honestly: the desktop app has no official Linux arm64 package while Apple silicon does. These conclusions come from the official repository and npm metadata; support matrices change, so confirm against the official README before installing.

Sources: apps/cli/README.md, apps/desktop/README.zh.md, npm @deepseek-ai/dsh.