Building and packaging

Prerequisites

Git, Rust (stable; the MSVC toolchain on Windows), and pnpm — the install page’s prerequisites table covers the Windows details. On Linux and macOS add the standard Tauri v2 system packages for your OS (Tauri’s prerequisites guide lists them; the exact apt set CI uses is in .github/workflows/release.yml). Node is not on the list — the repo pins it and pnpm fetches it.

Development

pnpm install            # frontend dependencies
pnpm tauri dev          # development mode (hot reload)
pnpm tauri build        # produce an installer

cargo test --workspace  # Rust unit tests (must be fully green before committing)
pnpm build              # strict tsc check + vite bundle

You never build the hub server as a routine step — pnpm tauri dev and pnpm tauri build both do it for you (see Packaging below). cargo build --release -p nextup-mcp exists only as the recovery command the app itself prints when the executable has gone missing.

Note

The Node version is pinned by use-node-version in .npmrc; pnpm downloads and uses it automatically, so whatever version is installed on your machine doesn’t matter.

Packaging

pnpm tauri build produces the installer (on Windows: MSI and NSIS).

The hub server ships inside the installer. scripts/prepare-sidecar.mjs builds nextup-mcp and stages it; it is wired into both beforeDevCommand and beforeBuildCommand, and Tauri’s externalBin mechanism packages it next to the main executable. After installation the app finds it without any PATH setup.

Windows also gets a portable build — the app and the hub in one zip, no installer. node scripts/make-portable.mjs (after pnpm tauri build) writes target/portable/Agent NextUp_<version>_<arch>_portable.zip; unzip anywhere you can write to and run agent-nextup.exe. It is Windows-only on purpose: Linux’s AppImage is already a no-install format, and an unsigned macOS app served from a zip hits Gatekeeper harder than the dmg does. Two caveats: the portable build cannot fetch the WebView2 runtime for you (the installer can), and AppLocker/WDAC block by execution policy, so they stop a portable exe just the same.

Multi-platform installers are produced by CI (three targets: Windows x64, Linux x64, macOS arm64), and the Windows job builds the portable zip alongside them. Pushing a v* tag opens a GitHub pre-release with the installers and the zip attached; workflow_dispatch uploads them as workflow artifacts instead. Every tagged build is on the releases page; take the newest. One exception is worth naming: the macOS build of the first tag, v0.1.0, predates the ad-hoc signature described below and does not open at all.

Unsigned builds

Nothing here is signed with a publisher certificate and nothing is notarized, so every OS stops the first launch. macOS bundles do carry an ad-hoc signature (bundle.macOS.signingIdentity: "-"), which identifies no publisher — it only makes the bundle structurally valid, so that Gatekeeper’s refusal is the recoverable kind rather than “the application is damaged”.

• Windows — SmartScreen blue box → “More info” → “Run anyway” (the installer and the portable exe alike).
• macOS — Gatekeeper refuses the first launch because the build is not notarized. Open System Settings → Privacy & Security, find the blocked app near the bottom of the pane, and click Open Anyway. Control-clicking the app and choosing “Open” is no longer a reliable bypass on current macOS. The command-line equivalent strips the quarantine flag instead — quote the path, it contains a space: xattr -dr com.apple.quarantine "/Applications/Agent NextUp.app".
• Linux — chmod +x the AppImage before running it; for the deb, sudo apt install ./Agent*.deb. The filename contains a space, so keep it out of the pattern — a literal space would split the argument before the glob ever runs, while the glob’s own result is a single word.

Automatic updates are not enabled yet.