Build Artifacts

A detailed reference of all files and directories produced by tauri build, including executables, installers, bundled assets, and intermediate compilation outputs.

When you run tauri build, Tauri compiles your Rust backend, builds your frontend with Vite, and packages everything into a set of files you can actually distribute to users. Those files are the build artifacts. Knowing what each one is, where it lives, and what it contains makes it much easier to debug a failed build, locate your final installer, or understand what ends up on a user’s machine. How those artifacts are wrapped for each OS is in Packaging Applications.

A Tauri v2 build produces artifacts in two main locations inside src-tauri:

target/release/ – the compiled Rust binary and intermediate compilation outputs
target/release/bundle/ – the final installer packages and any extra bundled files

This section walks through every category of artifact, what purpose it serves, and how to interpret the directory structure on each platform.

The Main Executable

The central artifact is the executable binary – the actual program that runs when a user double-clicks your app. Tauri embeds your frontend assets (the output from vite build) directly into this binary so that a single file contains both the Rust backend and all your HTML, JavaScript, and CSS.

The executable lives directly in target/release/ and its name and extension depend on the target platform:

Platform	Executable Name	Example
Windows	`<app-name>.exe`	`my-app.exe`
macOS	`<app-name>` (inside a `.app` bundle)	`my-app`
Linux	`<app-name>`	`my-app`

On macOS, the executable is not a standalone file you hand to users. It sits inside a .app bundle – a structured directory that macOS treats as an application. The full path looks like:

src-tauri/target/release/bundle/macos/<App Name>.app/Contents/MacOS/<binary>

On Windows, the .exe in target/release/ is the raw executable. The installer packages (NSIS or MSI) embed this file and place it in Program Files during installation.

On Linux, the binary in target/release/ can technically be run directly, but the installer packages (.deb, .rpm, .AppImage) are what you ship so that dependencies and desktop integration are set up properly.

The binary already contains your frontend:

Because Tauri v2 embeds your Vite build output into the Rust binary at compile time, you do not need to ship a separate folder of HTML/JS files. The tauri::Builder uses tauri-build to generate code that includes your dist directory as raw bytes.

How the Frontend Gets Embedded

During the build, tauri-build reads the distDir from tauri.conf.json (typically ../dist relative to the src-tauri folder) and generates a Rust file that includes all those assets via include_bytes! or a similar mechanism. The result is a single executable that serves the frontend from memory – no file‑system reads needed at runtime for the UI itself.

This is why you can move the binary to a completely different location and it still opens your app with the correct UI, and why Tauri apps remain small: no Chromium runtime, just your frontend bytes and the Rust logic.

Installer Packages

The files you actually give to end users are the installers, stored under target/release/bundle/. Tauri v2 can generate multiple installer formats per platform, and you control which ones appear through the bundle section of tauri.conf.json.

Here is what a typical bundle directory looks like after a successful build:

src-tauri/target/release/bundle/
├── nsis/
│   └── MyApp_1.0.0_x64-setup.exe
├── msi/
│   └── MyApp_1.0.0_x64_en-US.msi
└── (optional) wix/ or other generated files

NSIS installer (nsis/): The default installer format for Tauri v2 on Windows. It produces a .exe that handles installation directories, uninstaller registration, and optional custom pages. This is the most common choice for small to medium apps.
MSI installer (msi/): Produced when you enable the msi bundle target in tauri.conf.json. MSI packages integrate with enterprise deployment tools and Windows Group Policy. They require the WiX Toolset.

Both installer types embed the main .exe, any sidecar binaries, and the app icon.

Installers are ready to distribute:

Once you see these files appear in their respective folders, the build succeeded and you can upload the installers to your website, a GitHub release, or an app store.

How Tauri Decides Which Installers to Generate

In tauri.conf.json, the bundle object controls the active targets:

src-tauri/tauri.conf.json

{
  "bundle": {
    "active": true,
    "targets": "all",
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ]
  }
}

Setting "targets" to "all" produces every available format for the current platform. You can also specify an array like ["nsis", "msi"] on Windows to include both, or just "nsis" for a single format.

Bundled Resources

Beyond the executable, Tauri can ship additional files that your app needs at runtime. These bundled resources are declared in tauri.conf.json under bundle.resources and are copied into the installer package.

Typical bundled resources include:

Custom binaries (sidecars) – external programs your Rust code spawns
Configuration files – default settings or templates
Assets not embedded in the frontend – machine‑learning models, large data files, or license texts

For example, to include a directory of assets:

src-tauri/tauri.conf.json

{
  "bundle": {
    "resources": {
      "assets/*": "./"
    }
  }
}

This copies everything from assets/ in the project root into the same relative location inside the installation directory. At runtime, you resolve the actual path using the tauri::api::path module.

Bundled resources are external files:

Unlike your frontend assets, resources declared in bundle.resources are not embedded into the binary. They are stored alongside the executable and accessed at runtime via file paths. If you need maximum portability (a single binary with zero external files), consider embedding data directly in Rust using the include_bytes! macro.

Icons and Application Metadata

Icons are technically bundled resources but are handled automatically. Tauri reads your icon files from the icons/ directory and embeds them into the platform‑specific binaries:

On Windows: the icon is set in the executable’s resource section (and used by the installer)
On macOS: the .icns file is placed inside the .app bundle
On Linux: the icon is installed to the appropriate hicolor theme directory

You do not need to manually reference icons in bundle.resources; the bundle.icon array in tauri.conf.json handles all platform wiring.

Generated Build Files and the Target Directory

The target/ directory is Cargo’s working space and contains a large number of intermediate files. For a release build, the most important subdirectories are:

target/release/deps/ – compiled Rust dependencies (.rlib, .d files)
target/release/build/ – build‑script outputs (generated code, compile‑time checks)
target/release/.fingerprint/ – incremental compilation fingerprints
target/release/incremental/ – incremental compilation cache (if enabled)

These files speed up subsequent builds but are not part of the final artifacts. If you experience a linking error that tells you to “delete and rebuild” (like LNK1207: incompatible PDB format), the fix is to clean out the corrupted intermediate files while keeping your source intact.

# From inside src-tauri/
cargo clean

This removes the entire target/ directory, forcing a full rebuild on the next tauri build. It does not affect your bundle output, so your previously generated installers under bundle/ will remain untouched – but they may be overwritten on the next successful build.

A full clean resets incremental compilation:

cargo clean deletes everything in target/, which means the next tauri build will recompile every dependency from scratch. On slower machines this can take significantly longer, so only use it when you encounter actual build corruption.

Debug vs Release Artifacts

When you run tauri dev, Tauri compiles your Rust code in debug mode, with artifacts going to target/debug/. The resulting binary is larger, slower, and includes debug symbols. A development build is not meant for distribution; it uses the development server for frontend hot‑reloading and does not generate installer packages.

When you run tauri build, Tauri compiles in release mode, producing optimized binaries in target/release/ and generating the installer packages under bundle/. This is the only set of artifacts you should distribute.

A common confusion arises when someone accidentally ships the debug binary instead of the installer. The debug binary might run on the developer’s machine because the frontend dev server is available, but it will fail on a user’s machine. Always look inside target/release/bundle/ for your final, distributable artifacts.

Platform‑Specific Artifact Details

Each platform has unique artifact structures worth understanding beyond the installer formats.

Windows: PDB Files and the MSVC Linker

Windows release builds generate .pdb (Program Database) files in target/release/. These files contain debug symbols and are used by crash dump analysis tools. They are large but not needed for end‑user distribution. The .pdb files sometimes cause incremental build problems if they become out of sync – the LNK1207 error mentioned earlier is a direct consequence of a corrupted PDB file. Cleaning the target/ directory resolves it.

macOS: The .app Bundle Structure

The .app bundle under target/release/bundle/macos/ is a directory hierarchy that macOS presents as a single clickable application. Key contents:

MyApp.app/
├── Contents/
│   ├── Info.plist        (metadata: version, bundle ID, supported document types)
│   ├── MacOS/
│   │   └── MyApp         (the compiled Rust executable)
│   ├── Resources/
│   │   ├── icon.icns     (app icon)
│   │   └── ...           (any bundled resources)
│   └── _CodeSignature/   (if signed)
│       └── CodeResources

The executable inside the bundle is the same binary as target/release/my-app, but the bundling process copies it and signs the entire .app structure.

Linux: Desktop Entry and MIME Registration

On Linux, the installer packages create a .desktop file and register MIME types. The artifacts for these are generated automatically from your tauri.conf.json configuration:

bundle.identifier becomes the DBus name
bundle.icon files are installed to /usr/share/icons/hicolor/
The app’s name appears in the system launcher

The .AppImage format is self‑contained and does not require system‑wide installation, which makes it ideal for testing or portable use.

Common Mistakes When Handling Build Artifacts

Confusing the raw executable with the installer
The binary in target/release/ is not what you upload to a website. It may lack required dynamic libraries, resource embedding, or platform integration. Always use the files inside target/release/bundle/.

Distributing a debug build
Running tauri build produces release artifacts. If you accidentally package the binary from tauri dev (which lives in target/debug/), the app will depend on the development server and fail on other machines.

Not cleaning the target directory when builds break
Intermittent linking or compilation errors, especially after toolchain updates or dependency changes, are frequently fixed by cargo clean. If the error message mentions a corrupt file (like a .pdb, .rmeta, or fingerprint), a clean rebuild is the right first step.

Assuming the frontend is separate from the binary
Because the frontend is embedded, you do not need to zip the dist folder and ship it alongside the executable. Attempting to do so can confuse update mechanisms and increase bundle size unnecessarily.

Leftover artifacts from earlier builds:

If you change your app’s name, icon, or bundle targets, old artifacts may remain in target/release/bundle/ until you clean or rebuild. Always verify the file name and location match your current configuration before publishing.

Practical Exploration of Artifacts

To see exactly what your build produced, run tauri build and then inspect the output with your file manager or terminal. The CLI prints the final bundle paths at the end of the output, but the full tree is worth exploring at least once.

A quick way to locate all generated installers on a Unix‑like system:

find src-tauri/target/release/bundle -type f \( -name "*.exe" -o -name "*.msi" -o -name "*.dmg" -o -name "*.deb" -o -name "*.rpm" -o -name "*.AppImage" \)

On Windows (PowerShell):

Get-ChildItem -Path src-tauri\target\release\bundle -Recurse -Include *.exe,*.msi

After running either command, you should see the exact list of installer files ready for distribution. If a format you expected is missing, double‑check your tauri.conf.json bundle settings and that the required build tools (NSIS, WiX) are installed on your system.

Summary

A Tauri v2 build generates more than just an executable – it creates a complete package tailored to each operating system. The raw binary lives in target/release/ with your frontend already embedded, while the installers you actually distribute live under target/release/bundle/. Bundled resources like sidecar binaries and external assets are copied alongside the executable. The target/ directory holds all intermediate compilation artifacts, which can be safely cleaned when build corruption occurs.

Understanding this artifact layout means you can confidently locate your final installer, debug a build failure, and know exactly what your users receive when they download your app.

PreviousBuilding A Tauri App...

Next Build Configuration