tauri-action: Building and Publishing Tauri Apps from GitHub Actions

What tauri-action Changes for Tauri Projects

tauri-action packages a Tauri build and release flow inside GitHub Actions. The specific problem is not general application compilation. It is the repeated coordination needed to build a Tauri desktop application across macOS, Linux and Windows, collect native bundles, and place those bundles into a GitHub Release. The intended users are teams that already have a Tauri application and use GitHub-hosted runners for continuous integration or release automation.

The action supports three documented modes. It can test the build pipeline, upload artifacts to an existing release, or create a release and upload the generated bundles. The README presents release creation as the simplest common case. The application version is also used in the documented `tagName` and `releaseName` examples through the `__VERSION__` replacement token. That connection matters because a CI release must agree with the version in the Tauri application.

This is a focused action rather than a complete deployment platform. It invokes the Tauri CLI, works with GitHub Releases, and can generate updater JSON when the updater is configured. The documentation does not describe publishing to npm, operating a general artifact repository, signing every platform bundle, or deploying to an app store. Those jobs need separate workflow steps or services.

The Build, Release, and Updater Data Flow

The action begins inside a GitHub Actions job after the repository has been checked out and the language toolchain has been prepared. The workflow supplies `projectPath`, which points to the Tauri project root. The default is the current directory. Relative paths passed through `--config` are resolved relative to `projectPath`, so the location of the Tauri configuration affects how additional build arguments are interpreted.

The action executes the Tauri CLI through `tauriScript`. By default, it uses the package manager command appropriate to the project, such as `npm`, `pnpm`, `yarn` or `bun`, followed by `tauri`. If the action has to install the CLI, the documented default changes to `tauri`. The `tauriScript` value must contain no arguments and must not include a command such as `build`. Additional arguments go through `args`, which is added to the current Tauri build command.

Release handling has several branches. `releaseId` selects an existing release and causes `tagName` and `releaseName` to be ignored when finding that release. `tagName` identifies the release to find or create. If no release exists, `releaseName` is required when `releaseId` is not set. `releaseDraft` must match the existing release state when a tag already points to a release. The action can also generate release notes through GitHub's Release Notes API, with `releaseName` taking precedence over the generated title and `releaseBody` being prepended to generated notes.

When the updater is enabled, `uploadUpdaterJson` controls whether a JSON updater file is uploaded. The default is `true`. If both NSIS and WiX bundles exist, `updaterJsonPreferNsis` selects which bundle type is referenced by the updater JSON. The default is `false` for legacy reasons.

A First GitHub Actions Release

The README's publish workflow is the clearest first use. It checks out the repository, installs Node, installs stable Rust, installs Linux-specific packages, installs frontend dependencies, and then invokes `tauri-apps/tauri-action@v1`. The workflow also grants `contents: write`, which is required for creating or updating a GitHub Release.

The following is the documented macOS workflow step. It uses the release inputs from the README, and `GITHUB_TOKEN` is supplied through the environment.

- uses: tauri-apps/tauri-action@v1
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    tagName: app-v__VERSION__
    releaseName: 'App v__VERSION__'
    releaseBody: 'See the assets to download this version and install.'
    releaseDraft: true
    prerelease: false
    args: ${{ matrix.args }}

The release is created as a draft in the example. The action replaces `__VERSION__` with the application version when generating the tag and release name. The `args` value comes from the matrix, which lets one workflow build separate targets, including Apple Silicon and Intel macOS targets.

The full example also checks out the code and prepares the build environment:

- uses: actions/checkout@v4

- name: setup node
  uses: actions/setup-node@v4
  with:
    node-version: lts/*

- name: install Rust stable
  uses: dtolnay/rust-toolchain@stable

For Ubuntu, the repository documentation requires these system packages:

- name: install dependencies (ubuntu only)
  if: matrix.platform == 'ubuntu-22.04'
  run: |
    sudo apt-get update
    sudo apt-get install -y libwebkit2gtk-4.1-dev libappindicator3-dev librsvg2-dev patchelf xdg-utils

After the action completes, the expected result is a GitHub Release with the application bundles attached, or a draft release when `releaseDraft: true` is used. The README also points to the `examples` directory and the Tauri distribution guide for more workflow variants.

Release Controls and Workflow Constraints

The action exposes several controls for teams that already maintain release assets. `releaseId` is the most direct choice when a release already exists. In that mode, the action uploads assets to the specified release instead of locating it through `tagName` or `releaseName`. `tagName` remains relevant when publishing into a tagged release, and `releaseCommitish` can select the branch or commit used to create a new Git tag. The documentation says `releaseCommitish` is not used when the Git tag already exists.

The action also supports releases outside the current repository through `owner` and `repo`. Those settings require `GITHUB_TOKEN` and a `releaseCommitish` target when the destination does not match the current repository. `githubBaseUrl` changes the GitHub API endpoint for self-hosted GitHub Enterprise or GitHub instances, and it also affects the endpoint written into generated `latest.json`.

Retries are limited by `retryAttempts`, whose default is `0`. The README describes retries for both the initial build and for fetching, creating, or uploading assets. This is useful for transient failures, but it does not make platform-specific build errors disappear. The action is not responsible for signing or notarizing bundles in the shown workflow. The repository includes a separate example whose filename mentions signing certificates, but the README excerpt does not explain its configuration, so signing should be verified against that example rather than assumed.

Another constraint is `projectPath`. The directory must not be gitignored. That rule exists because the action needs to locate the Tauri project within the checked-out repository. A monorepo job must therefore place the path correctly and ensure that no ignore rule hides the project from the action.

How tauri-action Differs from a Manual Tauri Release Job

A manual Tauri release job can use the Tauri CLI directly on a runner, then upload files with separate GitHub tooling. That approach gives the workflow author more control over the individual steps, but it also requires implementing release lookup, release creation, asset upload, updater JSON handling, and retries in the workflow or an external script. `tauri-action` packages those release-related operations around the Tauri build for GitHub Releases.

The difference is therefore integration scope, not a different desktop runtime. The action does not replace `actions/checkout`, Node setup, Rust installation, frontend dependency installation, or Linux system packages. Those remain visible responsibilities in the documented workflow. It also does not replace the Tauri CLI, because it invokes that CLI to produce the application bundles.

This makes the action a poor fit if artifacts must go somewhere other than GitHub Releases, or if the project does not use Tauri. It is also a poor fit when the release process requires a different hosting API and the workflow does not need the action's GitHub Release behavior. The documented `githubBaseUrl` option covers GitHub Enterprise API endpoints, but it does not claim support for arbitrary artifact services.

For a Tauri team already publishing through GitHub, the main trade-off is between a shorter release step and fewer visible details about the surrounding implementation. Teams that need unusual signing, notarization, artifact retention, or multi-repository release policies should read the repository examples and the action inputs before replacing their current process.

Maintenance, Upgrades, and License Boundaries

The repository is not archived. Its last push was on 2026-10-16, and recent releases include `action-v1.0.0` on 2026-06-29, `action-v0.6.2` on 2026-03-14, and `action-v0.6.1` on 2026-01-03. The package metadata lists version `1.0.0`, Node `>=20`, and pnpm `^10.34.0` as development engine requirements for the action repository itself. The example workflow uses `actions/checkout@v4`, `actions/setup-node@v4`, and `dtolnay/rust-toolchain@stable`, so changes to those upstream actions or to the Tauri CLI can affect the build independently of the action release.

The action uses `retryAttempts` for transient build and release operations, with a default of `0`. Its own release history suggests that upgrades may involve reviewing changed inputs, workflow behavior, and generated updater metadata. The excerpt does not document a migration or rollback procedure for action versions, so a team should compare release notes and workflow behavior before changing a pinned `@v1` reference or replacing a local release process.

The repository declares the MIT license. That declaration covers the `tauri-action` project, while application bundles, signing certificates, GitHub Release content, and third-party dependencies remain separate concerns. The repository does not provide legal guidance about those additional assets, and the action does not claim to configure signing certificates for every bundle format.

Editorial conclusion

Adopt tauri-action when the application is already a Tauri project, the release process should run in GitHub Actions, and uploading bundles to GitHub Releases is acceptable. Do not choose it as a replacement for a general CI system or for projects that need signing details not present in the documented workflow. Verify first that your project path is tracked by Git, your runner has the required platform dependencies, and your release inputs match the state of the target GitHub Release. The repository is not archived, and its last push was on 2026-10-16.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tauri-apps/tauri-action on GitHub