Configuring Plugins

Many plugins accept configuration that you specify in tauri.conf.json under the plugins key. This is where you set plugin-specific options like timeouts, API keys, custom paths, or feature flags. Configuration is separate from installing plugins: installation wires the crate and JavaScript bindings into the project, while configuration tells an already-registered plugin how to behave.

The plugin name in the configuration must match the string the plugin’s Rust Builder uses — typically the part after tauri-plugin- (e.g., store for tauri-plugin-store).

{
  "build": { /* ... */ },
  "tauri": { /* ... */ },
  "plugins": {
    "store": {
      "defaultFileName": "app_data.json",
      "autoSave": true
    },
    "http": {
      "timeout": 30,
      "connectTimeout": 10
    }
  }
}

On the Rust side, the plugin reads this configuration during its setup hook via the api.config() method. You define a Config struct that deserializes the plugin’s block automatically. You don’t need to write any extra code to parse tauri.conf.json — Tauri does it for you when you pass the right type to the Builder.

The same plugins object lives in the main tauri.conf.json file that the CLI and runtime already read for windows, bundling, and security.

Combining Config with Permissions

Configuration becomes especially important when you need to restrict plugin behavior globally. For instance, the HTTP Plugin can be configured to only allow requests to certain domains. This acts as a second layer of security beyond the capability permissions — even if a capability accidentally allows a broad URL scope, the plugin config can still block it.

Permissions themselves are not written in the plugins block. They live in capability files under src-tauri/capabilities/. After you install a plugin, you still grant command access there — typically a plugin-name:default set or individual allow-* identifiers. The plugin permissions page covers how those identifiers are assigned to windows.

A typical capability entry looks like this:

{
  "identifier": "main-capability",
  "description": "Capability for the main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "store:default"
  ]
}

The exact permission identifier varies per plugin. Check the plugin’s documentation for the correct string. The Permissions & Security chapter explains the deny-by-default model that makes a missing entry fail closed rather than open.

Matching Names Across Rust, JSON, and JavaScript

Three strings must stay aligned for configuration to apply:

1. The plugin identifier passed to Builder::new("store") (or the official crate’s init()).
2. The key under plugins in tauri.conf.json.
3. The permission prefix in capabilities (store:default, http:default, and so on).

If those names drift, the plugin still starts, but api.config() deserializes an empty or default struct, and capability checks look for a different prefix. That is a common source of “the plugin ignores my config” reports.

The Store Plugin and HTTP Plugin are typical examples: their plugins.store and plugins.http blocks only apply after .plugin(...) is registered in lib.rs and the matching permission identifiers are granted.

Summary

Plugin configuration in Tauri v2 is a named block in tauri.conf.json plus a capability grant. The JSON block feeds api.config() on the Rust side; the capability file decides whether the frontend may call the plugin at all. Keep the plugin name identical across the Builder, the config key, and the permission prefix, and treat config as a second restriction layer rather than a replacement for permissions.