Guides by Christian Munoz

Build Windows x64 and ARM64 Tauri Installers and Release Them

Get the Tauri Local-AI Starter Kit on Gumroad $199 one time

The problem

Getting a desktop app to run on your own computer is the easy half. The hard half is producing an installer a customer can run, for both common Windows processor types, with checksums and a repeatable release process that does not depend on you remembering twelve steps. Many first releases stall on exactly this, because a sidecar built for one processor cannot simply be copied to the other.

The kit separates the job into two layers. Locally, one command builds an installer for the computer you are on. For releases, a pipeline builds x64 and ARM64 natively, smoke-tests the result and publishes only the installers and a checksum file to a separate public repo. This guide goes through both layers in the order you will meet them. Only Windows is tested, and nothing here should be read as covering other systems.

Steps

  1. Check the prerequisites

    You need Node 24 or newer, the stable Rust toolchain, Microsoft C++ Build Tools with the Desktop development with C++ workload for your processor type, and Microsoft Edge WebView2. The installers you build download WebView2 on the user's PC if it is missing, which needs an internet connection once.

  2. Rename the kit to your app

    Run npm run init-app, with --dry-run first if you want to preview the changes. It rewrites the display name, identifier, executable and installer names, and fills in config/release.json. Run it on a clean tree so git diff shows you exactly what changed.

  3. Build a local installer

    Run npm run desktop:build. It runs the web build, builds the sidecar, then runs tauri build. The result is a per-user NSIS installer that needs no administrator rights, placed in src-tauri/target/release/bundle/nsis/.

  4. Build on the matching processor

    The build covers the computer you are on only, because the sidecar embeds the local node.exe. Build x64 on x64 Windows and ARM64 on ARM64 Windows. The pipeline in the next steps does this for you on two runners.

  5. Point the pipeline at your repos

    Set sourceRepo and releasesRepo in config/release.json (or pass --repo and --releases-repo to init-app). Create a fine-grained token that can write contents to the releases repo only, and store it as the RELEASES_TOKEN secret of the source repo.

  6. Merge the release pull request

    release-please keeps a release pull request up to date from your conventional commits. Merging it tags the version and starts the Windows builds, each with a sidecar smoke test. The publish job then sends only the two installers and SHA256SUMS.txt to the public repo.

The warning your customers will see

The kit deliberately costs nothing to run, so it uses no code-signing certificate. Installers are unsigned, and Windows SmartScreen shows "Windows protected your PC" the first time one runs. Customers click More info and then Run anyway. The release notes explain this and show how to compare the download with the checksum file, but you should decide whether your audience will tolerate it. A signing step has a marked placeholder in the desktop workflow if you add a certificate later.

Automatic updating of installed apps is not switched on in the kit. An optional update feature, off by default, only checks your releases repo and shows a notice.

Time and cost to expect

A full release takes roughly 25 to 30 minutes of wall time, because the two Windows builds and the source job run at the same time. In a private repo, Windows minutes count double, so plan for around 80 to 100 billed minutes per release. These are estimates until you have a few real runs of your own.

Pros and cons

Pros

  • One local command produces a working per-user installer without administrator rights.
  • The pipeline builds x64 and ARM64 natively and smoke-tests the server before anything is published.
  • Only installers and checksums reach the public repo, so your source stays private.
  • Names and repos are set through init-app and one config file instead of scattered edits.

Cons

  • Installers are unsigned, which triggers a SmartScreen warning for your customers.
  • You must build each processor type on matching hardware or runners.
  • The ARM64 runner on GitHub can be slow to start or unavailable, and a full release is a long wait.
  • Only Windows is tested, so the manual options for other systems should not be offered to users.

Frequently asked questions

Can I build the ARM64 installer from an x64 computer?

The kit does not wire that up. The sidecar is built from a Node executable for the target processor, so the supported route is building on the matching hardware.

What does the installer file look like?

A per-user NSIS installer named like Starter App__x64-setup.exe, where the version comes from package.json. Names change after init-app.

What happens if the token is missing?

The publish job stops early with a message pointing to the setup instructions, nothing is published and the other build assets still finish.

Do I have to use the release pipeline?

No. npm run desktop:build works on its own. The pipeline adds repeatable releases, checksums and the public downloads repo.

Get the Tauri Local-AI Starter Kit on Gumroad $199 one time