# Mod Configuration Options

Mod Configuration Options let developers define customizable settings that can be configured by:

* **Mod users**, when [activating a mod](https://docs.pixiebrix.com/activating-mods)
* **Team administrators**, when [deploying a mod](https://docs.pixiebrix.com/deploying-mods) to their organization

<figure><img src="https://2274778196-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fq123bF1HPQPV35s5vHa1%2Fuploads%2FHtX4t2GGr05qYhHrVZ08%2FCleanShot%202025-07-16%20at%2015.20.21.png?alt=media&#x26;token=f45af876-a29b-4eb3-bcb4-1e870fd1fb1f" alt=""><figcaption></figcaption></figure>

These settings are ideal for things like:

* Setting a default language
* Choosing which database to reference&#x20;
* Enabling or disabling specific features (feature flags)

Once set, the values are passed into the mod at runtime and can be accessed in your mod using `@options.variableName`.&#x20;

### Defining a Configuration Option

Each option includes:

| Field                 | Description                                                                        |
| --------------------- | ---------------------------------------------------------------------------------- |
| **Name**              | The variable name used in `@options.variableName`                                  |
| **Label**             | Displayed in the form                                                              |
| **Field Description** | Optional text to provide with instructions for setting the text. Accepts markdown. |
| **Type**              | Input type (text, dropdown, checkbox, databse selector, Google Sheet, etc.)        |
| **Default**           | Optional starting value                                                            |
| **Placeholder**       | Hint displayed before entering text                                                |
| **Required**          | Optional flag to require thjis field for activation or deployment.                 |

#### Example

<figure><img src="https://2274778196-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fq123bF1HPQPV35s5vHa1%2Fuploads%2FCZKu3188SX7YKvKbHYw1%2FCleanShot%202025-07-16%20at%2015.15.36.png?alt=media&#x26;token=35cb829f-9511-4a4f-9db0-b120886d6e5f" alt=""><figcaption></figcaption></figure>

Then use `@options.user` anywhere in your mod.

***

### Best Practices

* Use clear, human-friendly labels.
* Use dropdowns or checkboxes to guide user input and provide consistency in options.
* Set default values to reduce friction.
* Group related options together when possible.
* Do not use for storing sensitive information, like API keys or secrets.

***

### FAQs

**What’s the difference between `@options` and `@input`?**\
`@options` refers to configuration values set when the mod is activated or deployed. `@input` is used to collect information about the current page each time a mod runs.

**Can I hide options or values from users?**\
No. All configuration options are visible when the mod is activated or deployed. For this reason, displaying secrets is not advised. Use an Integration to store and process API keys and tokens safely.

**Can I update options after deploying a mod?**\
Yes. Users or team admins can update the deployment options at any time.

**Do configuration values persist across sessions?**\
Yes. Once set, configuration values persist until updated in the deployment or the mod is reactivated.