---
title: "Plugin Configuration"
description: "How Designer discovers plugins, metadata configuration, window sizing, and styling"
url: https://developer.disguise.one/plugins/configuration/
---

# Plugin Configuration

This page covers how Designer discovers and loads plugins, how to configure plugin metadata, and how to style your plugin to match Designer’s UI.

## Discovery

Designer supports two methods of plugin discovery: local plugins found in project folders and remote plugins discovered through the network.

### Local Plugins

Local plugins are discovered in two locations:

1.  **Project Plugins Folder**: Plugins in the `Plugins` folder within the current project folder
2.  **Common Plugins Folder**: Plugins in the common plugins directory, shared across all projects

Designer automatically loads plugins from both locations, with project-specific plugins taking precedence over common plugins if there are naming conflicts.

### Remote Plugins

Remote plugins are discovered using DNS Service Discovery (DNS-SD). They must be registered with the following service name format:

```text
<instance>._d3plugin._tcp.<domain>
```

Where:

-   `instance` is the name of the service
-   `domain` is usually `local` for local network discovery

For Python-based remote plugins, the [Python plugin library](https://github.com/disguise-one/python-plugin) provides automatic DNS-SD registration and helper functions. See the [Tools & Libraries](/plugins/useful-links) page.

## Metadata

Plugin metadata configures how plugins are presented and behave in Designer. Both local and remote plugins use metadata, though the implementation differs.

### Local Plugin Configuration

Local plugins are configured using a `d3plugin.json` file in the plugin’s root directory. All fields are optional.

```json
{
  "name": string,        // The user-visible name of the plugin
  "url": string,         // The address for this plugin's web resources
  "requiresSession": bool // Whether the plugin requires Designer to be running
}
```

The `url` field allows you to specify a custom endpoint for the plugin’s web interface. If not specified, Designer uses its default hosting address.

### Remote Plugin Configuration

Remote plugins specify their type through a TXT record added to the DNS service registration.

| JSON field | TXT record | Description | Optional |
| --- | --- | --- | --- |
| `name` | N/A | User-visible name. The service instance name is used for remote plugins | Yes |
| `url` | `u` | Address for web resources. Defaults to host for remote plugins | Yes |
| N/A | `t` | Must always be `web` | No |
| `requiresSession` | `s` | Whether the plugin requires Designer to be running. `true` or `false` | Yes |

### Window Configuration

Window size is configured through HTML meta tags:

```html
<meta name="disguise-plugin-window-size" content="512,512">
<meta name="disguise-plugin-window-min-size" content="200,200">
<meta name="disguise-plugin-window-resizable" content="true">
```

These control the initial size, minimum size, and resizability of the plugin’s window in Designer.

## Styling

### Colour Scheme

Designer sets the browser’s colour scheme preference to dark mode when hosting plugins. Implement theme support using the `prefers-color-scheme` CSS media feature:

```css
/* Default dark theme */
:root {
  --background-color: #1a1a1a;
  --text-color: #ffffff;
}

/* Override for light theme if needed */
@media (prefers-color-scheme: light) {
  :root {
    --background-color: #ffffff;
    --text-color: #000000;
  }
}
```

### Alpha Backgrounds

Designer supports transparent backgrounds for plugin pages. When a plugin’s background is transparent, it inherits Designer’s default blurred background, similar to other widgets.

```css
body {
  background-color: rgba(0, 0, 0, 0); /* Fully transparent */
  /* or */
  background-color: rgba(0, 0, 0, 0.5); /* Semi-transparent */
}
```

This is useful for creating floating or overlay-style interfaces that blend with Designer’s environment.