Installer Configuration

When you run tauri build, the bundler doesn't just compile your Rust backend and frontend. It takes everything, wraps it in a platform-appropriate installer, and drops the result in your output folder. The installer configuration—part of the bundle object in tauri.conf.json—controls exactly how that wrapping works. It decides the installer format, what the user sees during installation, and the final artifact's name and version. Code signing settings also live in these platform objects.

Think of it like a box that holds your application. The configuration describes the box's label, its shape, and the instructions printed on it. Different operating systems expect different boxes, and that's why the installer configuration splits naturally into Windows, macOS, and Linux sections.

How Tauri Creates Installers

During a build, Tauri's bundler gathers your compiled binary, frontend assets, resources, and icons. It then passes these to platform-specific tools—like WiX or NSIS on Windows, pkgbuild/dmgbuild on macOS, and dpkg/appimagetool on Linux. The final installer artifacts land in src-tauri/target/release/bundle/.

The bundle object in your config is the dial you use to influence this process. At minimum, you need "active": true and an identifier. From there, each platform's sub-object lets you fine-tune the installer.

Windows Installer Configuration

Tauri offers two installer technologies for Windows: NSIS (setup.exe) and WiX (MSI). You can generate one, the other, or both from the same tauri build run by setting the corresponding sub-objects under bundle.windows. NSIS produces a self-extracting executable with a familiar wizard. WiX produces an MSI file, which is easier for enterprise deployments and supports features like silent installation and group policy distribution.

{
  "productName": "My App",
  "version": "1.0.0",
  "identifier": "com.mycompany.myapp",
  "bundle": {
    "active": true,
    "icon": ["icons/icon.ico"],
    "targets": "nsis",
    "windows": {
      "nsis": {
        "installMode": "currentUser",
        "shortcutName": "My App",
        "uninstallDisplayName": "My App ${version}",
        "displayLanguageSelector": false
      }
    }
  }
}

WebView2 Installation Options

Both installer formats need Microsoft Edge WebView2, the runtime that powers your frontend. By default, the installer downloads the WebView2 bootstrapper on the user's machine if it isn't present. You control this behavior with webviewInstallMode.

"windows": {
  "webviewInstallMode": {
    "type": "downloadBootstrapper",
    "silent": true
  }
}

The type field accepts four options:

skip is also available but leaves WebView2 uninstalled—only use it if you are certain every target machine already has the runtime.

macOS Bundle Configuration

macOS packaging revolves around two deliverables: the .app bundle (always created) and an optional .dmg disk image. The bundle.macOS object in your config sets the rules for both.

Here's a production-ready macOS configuration:

{
  "productName": "My App",
  "version": "1.0.0",
  "identifier": "com.mycompany.myapp",
  "bundle": {
    "active": true,
    "icon": ["icons/icon.icns"],
    "macOS": {
      "minimumSystemVersion": "10.15",
      "hardenedRuntime": true,
      "dmg": {
        "appPosition": { "x": 180, "y": 170 },
        "applicationFolderPosition": { "x": 480, "y": 170 },
        "windowSize": { "height": 400, "width": 660 },
        "background": "dmg-background.png",
        "volumeName": "My App Installer",
        "title": "My App Installer"
      }
    }
  }
}

minimumSystemVersion sets the oldest macOS version your app supports. Users on older systems won't be able to open the app at all. hardenedRuntime enables Apple's hardened runtime, required for notarization. Leave it true unless you have a specific reason to disable it.

The dmg sub-object controls the look of the disk image window: where the app icon sits, where the Applications folder shortcut appears, and the size of the window that opens when the user mounts the DMG. background is a PNG image placed in your resources; it serves as the DMG's window background. volumeName sets the volume label that appears in Finder.

Linux Package Configuration

Linux packaging is more fragmented. Tauri supports three formats: Debian (.deb), RPM, and AppImage. You can generate all three in a single build. The configurations live under bundle.linux:

{
  "bundle": {
    "active": true,
    "icon": ["icons/icon.png"],
    "linux": {
      "deb": {
        "depends": ["libwebkit2gtk-4.1-dev", "libgtk-3-0"],
        "files": {
          "/usr/share/applications/my-app.desktop": "desktop/my-app.desktop"
        }
      },
      "rpm": {
        "epoch": 0,
        "release": "1",
        "files": {},
        "requires": ["webkit2gtk3", "gtk3"]
      },
      "appimage": {
        "bundleMediaFramework": false,
        "files": {}
      }
    }
  }
}

Each format has its own sub-object. The depends (deb) and requires (rpm) arrays list system packages that must be present on the target machine. Tauri automatically adds the core WebKitGTK dependency, but if your app links to additional libraries, you need to list them here.

The files map lets you include extra files into the package—for instance, a .desktop file for application menus. The key is the destination path inside the installed system, and the value is the source path relative to your project.

The appimage object is minimal. Setting bundleMediaFramework to true includes additional multimedia libraries, which can be helpful if your frontend uses codecs not bundled by default.

General Installer Customization

Several top-level fields affect the installer regardless of platform. These live at the root of tauri.conf.json and in the bundle object.

{
  "productName": "My App",
  "version": "1.0.0",
  "identifier": "com.mycompany.myapp",
  "mainBinaryName": "myapp",
  "bundle": {
    "active": true,
    "icon": ["icons/icon.png"],
    "targets": "all",
    "createUpdaterArtifacts": false,
    "windows": { ... },
    "macOS": { ... },
    "linux": { ... }
  }
}

productName becomes the application's display name—the one you see in shortcuts, the Start menu, and the title of installer dialogs. identifier must follow reverse-domain notation and be unique. It also determines the data directory path (e.g., ~/.local/share/com.mycompany.myapp/ on Linux).

mainBinaryName overrides the executable filename. By default, Tauri uses the name from your Cargo.toml. Changing it here renames the final binary after compilation, so all packaging steps refer to the new name. Do not include an extension—Tauri adds .exe on Windows automatically.

targets can be "all" (build every format your OS supports) or a comma-separated string like "msi,nsis". This is a quick way to exclude formats without deleting their config blocks.

Common Mistakes

• Forgetting to set "active": true. The bundler produces no installers, and the build may still complete without a clear error. Check your bundle output folder; if it's empty, this is the first thing to verify.
• Using an invalid identifier. If your identifier contains characters beyond alphanumerics, hyphens, and periods, the bundler will reject it. The error message points directly to the field, so read it.
• Changing upgradeCode across MSI versions. Each new GUID tells Windows this is a completely different product, breaking upgrades and leaving old installations behind.
• Relying on the default WebView2 mode for offline use. If your users might not have an internet connection during installation, explicitly choose offlineInstaller or fixedVersion. The default downloadBootstrapper will fail silently, and the app will not launch.

Summary

Installer configuration is the last piece of the bundling puzzle before distribution. Once your installers look the way you want, you'll need to sign them—code signing for Windows and macOS, and GPG signing for Linux repositories—so that users' systems trust your app.