CLI tool
tauri-apps/plugins-workspace avatar
tauri-apps/plugins-workspace

tauri plugins: the official plugin set in one workspace

All of the official Tauri plugins in one place!

1,836 stars624 forksRustApache-2.0

At a glance

What is it?
The official Tauri plugins live in a single repository that is both a Cargo workspace and a pnpm workspace, and the table at the top of the README is the most useful thing in it: a support matrix that says which plugin runs on Windows, macOS, Linux, iOS and Android. The repository also carries the versioning machinery for the updater plugin, which is why the recent releases are all updater tags.
Who is it for?
Adopt the official Tauri plugins if you are building a Tauri application and want the maintained integrations rather than your own IPC layer, and if you are willing to check the support matrix before you promise a feature on a platform you have not tested. Do not adopt a plugin whose cell in the matrix is a question mark, because that means the support is not established.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The matrix is the documentation

The plugins table is the centre of the README, and it is more informative than a paragraph of prose would be. Each plugin has a row, a one-line description and five columns for Windows, Mac, Linux, iOS and Android, each marked with a tick, a cross or a question mark.

The question marks are the interesting part. They are not crosses, so the plugin is not declared unsupported, and they are not ticks, so it is not declared supported either. A question mark is a promise the project has not made, and reading it that way saves somebody from shipping a feature that turns out not to work on the platform their users are on.

The pattern across the table is clear once you read a few rows. Plugins that are inherently about desktop session behaviour are desktop only: autostart launches the app at system startup, positioner moves windows to common locations, and single-instance ensures a single instance of the app is running, and all three are crosses on iOS and Android. Plugins that are inherently about device hardware are mobile only: barcode-scanner uses the camera, biometric prompts for biometric authentication, geolocation gets and tracks the device position, haptics does haptic feedback, nfc reads and writes NFC tags, and torch controls the flashlight.

And then there is a long list in the middle that is a tick on every platform: clipboard-manager, deep-link, dialog, http, log, notification, opener, os, sql and store.

A handful sit in between with question marks on the mobile columns: fs for file system access, global-shortcut, localhost, persisted-scope, process, shell and stronghold.

What the plugins actually do

Walking the list gives a good picture of what a Tauri application can reach for without writing its own bridge.

The system integration plugins are autostart for launching at startup, cli for parsing arguments from your command line interface, global-shortcut for registering global shortcuts, opener for opening files and URLs using their default application, and os for reading information about the operating system. The positioner moves windows to common locations, and single-instance ensures only one copy of the app runs.

The data and storage plugins are store for persistent key value storage, sql for SQL databases, and stronghold for an encrypted, secure database. The fs plugin gives access to the file system, and persisted-scope persists runtime scope changes on the filesystem, which is the mechanism behind a Tauri permission being granted and surviving a restart.

The process related ones are process, which provides APIs to access the current process, with a pointer in the table to the separate shell plugin for spawning child processes, and shell itself, which accesses the system shell, allows you to spawn child processes and manage files and URLs using their default application.

Then the cross-platform set. The http plugin exposes the HTTP client written in Rust, which is a meaningful difference from the browser fetch, and the log plugin gives configurable logging. The notification plugin sends message notifications, with a brief auto-expiring OS window element, and can also be used with the Notification Web API. The dialog plugin gives native system dialogs for opening and saving files along with message dialogs, deep-link sets your Tauri application as the default handler for a URL, and the localhost plugin lets you use a localhost server in production apps.

That is a complete inventory of what a desktop and mobile application usually needs from its host, in one table, which is the value of keeping them in a single repository rather than scattered across their own.

One Cargo workspace, one pnpm workspace

The repository is both a Rust workspace and a JavaScript one, and the Cargo manifest shows how the Rust side is organised.

toml
[workspace.package]
edition = "2024"
authors = ["Tauri Programme within The Commons Conservancy"]
license = "Apache-2.0 OR MIT"
rust-version = "1.90"
repository = "https://github.com/tauri-apps/plugins-workspace"

The members are the plugins, their test crates, the updater migration fixture and the example applications, listed as plugins/*, plugins/*/tests/*, a specific updater migration app, plugins/*/examples/*/src-tauri and examples/*/src-tauri, with the resolver set to 3.

The workspace dependencies show what the plugins share. There is serde with derive, tracing and log for the two logging ecosystems, tauri 2.12 with default features off, tauri-build 2.7, tauri-plugin 2.7.1 and tauri-utils 2.10, then serde_json, thiserror 2, url, schemars, dunce, glob, and two that stand out: specta, the library for generating TypeScript types from Rust types, and zbus, the D-Bus bindings used for the Linux side of the plugins that need it.

The edition is 2024 and the minimum Rust version is 1.90, and the README says the same thing in bold at the top. The authors field names the Tauri Programme within The Commons Conservancy, which tells you the governance of the repository rather than an individual, and the licence is the same dual Apache-2.0 OR MIT that the JavaScript side declares.

A release profile that optimises for size

The profile section of the Cargo manifest is short and deliberate.

toml
[profile.release]
panic = "abort"
codegen-units = 1
lto = true
incremental = false
opt-level = "s"

The comment above it says the intention: default to small, optimized release binaries. Each line follows from that. opt-level of s optimises for size rather than for speed, lto enables link time optimisation across the crate boundaries, codegen-units of 1 gives the optimiser the whole program to look at, incremental is off because it costs disk and buys nothing in a release build, and panic abort replaces unwinding with an immediate abort, which removes the unwinding tables and the associated binary size.

For a plugin library those settings matter less than they would for a final binary, since most of the code ends up in the host application. But the profile is inherited by the example applications and by the integration test binaries, and a Tauri application is exactly the case where a couple of megabytes per plugin adds up to something the user notices.

The fact that the profile is shared across the whole workspace, rather than tuned per plugin, is a simplification worth knowing about. It keeps the build configuration in one place, and it means every plugin is compiled the same way, which is usually the right trade for a set of libraries that ship together.

The JavaScript side, the tooling and the release line

The package.json is the JavaScript half of the workspace, and it uses pnpm at 12.3.4 with a minimumReleaseAge of 4320, which is a delay in minutes that keeps a newly published package from being installed immediately, a supply chain precaution that is now common in this ecosystem.

The scripts show the shape of the work. The build runs recursively with filters that exclude the workspace root and the example applications, because the examples are applications rather than libraries. There are lint, format and format:check scripts, a ts:check that runs the type check across the packages, and three end-to-end scripts, a general test:api-e2e plus android and ios variants, which are the ones that run the API example on a device. There is also example:api:dev to run the example application with tauri dev.

The JavaScript dependencies are the type checker and the bundler rather than a framework: TypeScript 6.0.3, eslint 10 with the typescript-eslint and security plugins, prettier 3.8.3 and rollup 4 with the node resolve, terser and typescript plugins.

The rest of the root is the housekeeping that a multi-language monorepo accumulates: an AGENTS.md, a SECURITY.md, a renovate.json for the dependency updates, a taplo.toml for formatting the Cargo files, an eslint.config.js, the Prettier and npm configuration, .cargo/ and .changes/ and .scripts/ directories, and a .vscode/ directory. The licences are three files, LICENSE.spdx, LICENSE_APACHE-2.0 and LICENSE_MIT, which is the usual way of shipping a dual licence with an SPDX expression alongside.

The updater plugin moves on its own schedule

The recent release list is entirely updater tags, and that is the interesting detail. There is updater v2.14.0 and updater v3.0.0-alpha.3, plus updater-js v3.0.0-alpha.3, all on 2026-10-14, and the last push to the repository was on 2026-10-18, four days before this review.

Two things follow from that. The updater plugin is released independently of the other plugins, which is correct for the component that has to be trusted to replace a running application with a new one. And there are two major lines in flight at once, the 2.x stable and the 3.0 alpha, which is what a major version boundary in a plugin that is coupled to the Tauri major version looks like.

The default branch is v2, which is the 2.x line, so a checkout of the default branch gives you the stable plugins rather than the alphas.

The repository is not archived, the primary language is Rust, and the project licence in the metadata is Apache-2.0 while the workspace declares the dual Apache-2.0 OR MIT. The homepage is tauri.app, and the topic tags are hacktoberfest, tauri and tauri-plugin, which is a reminder that this repository takes outside contributions, and that the maintainers are more interested in the plugin set than in a single application.

Editorial conclusion

Adopt the official Tauri plugins if you are building a Tauri application and want the maintained integrations rather than your own IPC layer, and if you are willing to check the support matrix before you promise a feature on a platform you have not tested. Do not adopt a plugin whose cell in the matrix is a question mark, because that means the support is not established. Before you start, read the matrix for the platforms you ship, and check the Rust version, since the repository and all the plugins require Rust 1.90 or later, and note that the updater plugin ships on its own release line with a 3.0 alpha alongside the 2.x stable, so pin the plugin version that matches your Tauri major.

Frequently asked questions

What is the tauri plugins workspace?

It is the single repository holding all the official Tauri plugins, and it is both a Cargo workspace and a pnpm workspace. The README table lists each plugin with a description and a support matrix across Windows, macOS, Linux, iOS and Android.

What do the check marks and question marks in the plugin table mean?

A tick means the plugin is supported on that platform and a cross means it is not. A question mark means the support is not established, so a plugin with a question mark on your target platform is one the project has not confirmed, and it should not be the basis of a shipped feature.

What are the requirements for building the Tauri plugins?

The repository and all the plugins require a Rust version of at least 1.90, and the Cargo workspace uses edition 2024 with the resolver set to 3. The JavaScript side uses pnpm at 12.3.4, and the whole workspace is licensed Apache-2.0 OR MIT.

How are the Tauri plugins tested?

Beyond the per-plugin test crates that are listed as workspace members, the package.json defines end-to-end scripts for the API example, including separate android and ios variants, and a script that runs the example application with tauri dev. The JavaScript build script deliberately excludes the example applications from the recursive build.

How often are the Tauri plugins released?

The recent releases are all updater tags, with updater v2.14.0 and updater v3.0.0-alpha.3 on 2026-10-14, and the last push was on 2026-10-18. The updater plugin ships on its own release line, separately from the other plugins, and the default branch is v2.

Official sources

  1. License: Apache-2.0
  2. Project website
  3. README
  4. Releases
  5. tauri-apps/plugins-workspace on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/tauri-apps-plugins-workspace.svg)](https://hysenlabs.com/projects/tauri-apps-plugins-workspace)

Was this useful?