Nuxtor: a Nuxt 4 and Tauri 2 starter for desktop and mobile apps

A template, not a framework, and it says so in the package metadata

Nuxtor describes itself as a starter template rather than a library. The package.json carries a private flag set to true, which is what a template repository does rather than a published package, and its description reads Starter template for Nuxt 4 and Tauri 2. Version 1.7.0, author Nicola Spadari, MIT licensed.

The stack is listed plainly: Nuxt v4, Tauri v2, Nuxt UI v4, Tailwind CSS v4, TypeScript and ESLint, plus auto imports including the Tauri APIs. The dependency list backs that up. The runtime dependencies are @nuxt/ui at 4.11.3, the @tauri-apps/api package at 2.12.4, and six official Tauri plugins: fs, notification, opener, os, shell and store. On the Nuxt side there is nuxt at 4.6.1, vue at 3.5.43, vue-router at 5.3.1 and zod for schema validation.

The tooling is equally specific. pnpm is the package manager, pinned at [email protected] in the packageManager field, and the Node version lives in a .nvmrc file. A preinstall hook runs npx only-allow pnpm, so a mistaken npm install fails fast rather than producing a broken lockfile, and a postinstall hook runs nuxt prepare to generate types.

The README frames the project as a spiritual successor to ViTauri by the same author, built with Nuxt 4 and Tauri 2. The repository also carries a Chinese README, a preview.md page linking live previews for iOS, Android, commands, file system, notifications, OS info, storage and webview, and a .claude/ directory alongside a bump.config.ts for release versioning.

Scaffolding, pnpm install, pnpm tauri:dev

Getting a project running is three commands after the template is fetched. The scaffold step uses degit rather than the create tool of a CLI:

npx degit NicolaSpadari/nuxtor my-nuxtor-app

cd my-nuxtor-app

# Install dependencies
pnpm install

# Start development mode
pnpm tauri:dev

The dev server runs on http://localhost:3000, and the README notes that pnpm tauri:dev picks the next free port if the default is busy. The script behind that command is not the plain Tauri CLI, it is tsx scripts/tauri-dev.ts, which is a small wrapper the project provides.

There are Tauri prerequisites to satisfy first. The README requires Rust 1.90 or later and points at the Tauri v2 prerequisites page, which covers the system libraries each platform needs.

One deliberate decision sits underneath all of this: Nuxt SSR is disabled so Tauri can act as the backend. The README is explicit that this is not a reduced Nuxt. Routing, middleware, composables and the other Nuxt features remain fully functional; what is gone is the server side rendering that a hosted site would need. The README lists hosted SSR as the one requirement it declares not suitable for.

One tauri:dev script per target, and the mobile projects are pre-generated

The script names in package.json cover the whole matrix, and each one maps to a Tauri CLI invocation. Desktop is tauri:dev for development and tauri:build for a release, with tauri:build:debug running the debug build, which the README says enables console access inside the bundled app. The output lands in src-tauri/target.

Mobile has its own pair of scripts per platform. iOS development uses pnpm tauri:dev:ios, and it requires macOS, Xcode and CocoaPods. The Xcode project is already generated at src-tauri/gen/apple, which saves the setup step of creating a project by hand. The same script has variants: passing --host exposes the dev server on the network for a physical device, and --open opens the project in Xcode. Production iOS builds use pnpm tauri:build:ios. Signing is configured with a team identifier in the .env file using APPLE_DEVELOPMENT_TEAM, with .env.example showing a placeholder value, or in Xcode under Signing and Capabilities.

Android follows the same shape with pnpm tauri:dev:android and pnpm tauri:build:android, and it requires Android Studio, the SDK and the NDK, with ANDROID_HOME, NDK_HOME and JAVA_HOME all set. The Gradle project is already generated at src-tauri/gen/android.

There is a maintenance note attached to both platforms. After a Tauri CLI upgrade, the mobile projects have to be regenerated with pnpm tauri android init and pnpm tauri ios init. That is the cost of checking generated projects into the repository, and the alternative would be generating them on every clone.

Permissions are split into main.json and desktop.json

The permissions model is where a Tauri template either saves you work or costs you time, and Nuxtor has made a specific choice. The README states that permissions live in src-tauri/capabilities/, with main.json holding the permissions for every platform and desktop.json holding the desktop-only features, naming the tray, menu and shell.

That split is the reason the same template can target a phone and a laptop without granting desktop capabilities on mobile. It also means that if you add a plugin, there are three places to touch, and the README lists them: register it in src-tauri/src/lib.rs, add it to the capabilities, and add it to the module file.

The auto-import layer is the third piece. Tauri APIs are auto-imported under the name pattern useTauri<Module><Function>, defined in modules/tauri.ts. So a call into the notification plugin or the store plugin arrives in a component without an import statement. For a team already living in Vue and Nuxt that removes a layer of friction that would otherwise be the most annoying part of writing a Tauri app.

The repository layout reflects the split between the two halves of the project: app/ for the Nuxt application, src-tauri/ for the Rust side, modules/ for the auto-import definitions, scripts/ for the dev wrapper, plus nuxt.config.ts, tsconfig.json, eslint.config.mjs and a pnpm-workspace.yaml.

Shell access, notifications and persistent storage are already wired up

The feature list is short and every item maps to a plugin already in the dependency list. The app can run shell commands from the interface, send OS-level notifications, read system information through the os plugin, keep persistent key and value data through the store plugin, and show a system tray icon. The file system plugin handles the file system side.

The six plugins in package.json are the plugin-fs, plugin-notification, plugin-opener, plugin-os, plugin-shell and plugin-store packages, all pinned to specific versions in the 2.x line. The opener plugin is the one worth understanding separately, because it exists to hand a file or URL to the operating system's default handler rather than opening it inside the app window.

What the template does not do is provide a UI layer over all of this. Nuxt UI v4 with Tailwind CSS v4 is the component layer, and the repository links live previews for the individual capabilities, which is the fastest way to see what each plugin looks like when it is actually wired up.

There is also a plain web mode in the scripts, with dev, generate and preview running the Nuxt side on its own without Tauri. That separation is useful for working on the interface in a browser, and it is the natural way to develop the front end before the shell commands and permissions are relevant.

Three releases in 2026, and where the template falls short

The project is moving. The repository is not archived, the last push was on 2026-10-16, and the releases tell the story: Nuxtor v1.5.1 on 2026-01-01, v1.6.0 on 2026-01-31 with the release note The mobile update, and v1.7.0 on 2026-10-16. The licence is MIT, copyright Nicola Spadari from 2024 onwards, so you can take the template, rename it and ship a product from it without licence obligations beyond keeping the notice.

The first limitation is the one the README states most clearly. There is no hosted SSR. If your product needs server rendering, streaming, or a Nuxt deployment target, this template is not the starting point, because the SSR decision is baked into the configuration rather than a toggle you can flip.

The second is that a template ages. Nuxt 4, Nuxt UI 4, Tauri 2, Vue Router 5 and the @tauri-apps/api at 2.12.4 are all pinned to specific minor versions, and a template pinned to versions from one point in time will drift from the ecosystem. The bump.config.ts file and the pnpm-lock.yaml give you the machinery to track that, but the work is still yours.

The third is scope. This is a starter, so there is no data layer, no routing convention beyond what Nuxt provides, no test harness and no deployment pipeline for the packaged app. What you get is the hard integration part, which is the part most people get wrong, and you still write the application.

Editorial conclusion

Nuxtor suits a Vue or Nuxt team that wants a native shell for a desktop or mobile app and would rather start from a working template than wire Tauri plugins, permissions and auto-imports by hand, and it does not suit anyone who needs hosted server side rendering, since SSR is turned off on purpose so Tauri can act as the backend. Before you build on it, check the three separate permission files in src-tauri/capabilities, since desktop-only features such as the tray, menu and shell live in desktop.json rather than main.json, and confirm your mobile toolchain, with Android requiring Android Studio, the SDK, the NDK and three environment variables set.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NicolaSpadari/nuxtor on GitHub
4. README
5. Releases