> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Plugin marketplace

> Install and require bundles of skills for everyone in your org or enterprise from the Devin web app

<Note>
  Plugins are in **closed beta**. To request access, contact [support@cognition.ai](mailto:support@cognition.ai). Behavior and configuration may change in future releases.
</Note>

## What are plugins?

A **plugin** bundles skills — and optionally rules, hooks, MCP servers, and subagents — so it can be installed and reused as a unit. See the [plugins reference](/cli/extensibility/plugins/overview) for the file format and what a plugin can ship.

**Managed plugins** let an admin install plugins centrally, from the Devin web app, so they apply to **everyone in the org or enterprise** — no per-user setup. This covers cloud Devin sessions **and** [Devin CLI](/cli/index) users logged into the account (enterprise/account-level config reaches the CLI too — see [cloud sessions vs. the CLI](#cloud-sessions-vs-the-cli)). When a plugin is installed, its skills become available to Devin automatically as `/<plugin>:<skill>` commands.

This page covers the web app side of plugins: managed manifests, scopes, and uploads.

## Where to configure them

Go to [**Settings → Resources → Plugins**](https://app.devin.ai/settings/marketplace). The page has two tabs:

* **Marketplace** — browse plugins (the Devin official catalog plus any your org or enterprise has added) and install them. Installing a plugin **adds it to the manifest of the chosen scope as a required plugin**, so it's installed for everyone in that scope.
* [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) — edit the raw plugin **manifest** as JSON, and upload your own plugin as a folder or `.zip` (or build one in the editor).

Access is permission-gated:

* **Org admins** (organization settings access) manage the **org** manifest.
* **Enterprise admins** (enterprise settings access) additionally manage the shared **enterprise** manifest.

## The manifest

The manifest is a single JSON document with three lists:

```jsonc theme={null}
{
  "requiredPlugins": ["acme/review-tools"],
  "optionalPlugins": [],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*"]
}
```

* **`requiredPlugins`** — installed for everyone in scope (recursively, including any plugins they depend on).
* **`optionalPlugins`** — an allow-list that endorses plugins without auto-installing them; used to carve out exceptions to a forbidden entry.
* **`forbiddenPlugins`** — a deny-list of plugin identities or glob patterns.

The manifest is stored verbatim; the agent validates the full source at install time. See the plugins reference for the [source forms](/cli/extensibility/plugins/overview#the-manifest) each entry can take and the full [dependency and governance semantics](/cli/extensibility/plugins/overview#dependencies-and-governance).

## Adding your own plugins

Depending on where the plugin lives, add it in one of these ways:

| Where it lives                                       | How to add it                                                                                                   |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Public git repo**                                  | Add `"owner/repo"` (or the git URL) to the manifest, or install from the Marketplace tab if it's in the catalog |
| **Private git repo**                                 | Same manifest entry — see [using a private skills repo](#using-a-private-skills-repo) for how auth works        |
| **Subfolder of a repo** (e.g. a monorepo of plugins) | Add a `git-subdir` source — see the [plugins reference](/cli/extensibility/plugins/overview#the-manifest)       |
| **Not in a repo at all**                             | Upload it as a bundle (below)                                                                                   |

### Uploading a plugin bundle

On the [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) tab, the **Uploaded plugin** section lets you upload a plugin as a folder or `.zip`, or build one directly in the editor. Saving it adds it to the manifest as a required plugin (installing it for everyone in scope); deleting it removes the reference. This is a good option for a plugin you don't want to (or can't) host in a git repo.

### Using a private skills repo

Point the manifest straight at the private repo — you generally don't need to bake it into your [environment snapshot](/onboard-devin/environment/blueprints). Any private repo Devin can already reach through your Git integration installs automatically. Use the git URL form, or `git-subdir` to install a plugin from a subfolder of a shared repo. (CLI users covered by the same manifest fetch with their own local git credentials, so they'll need access to the repo too.)

If the repo isn't reachable through your Git integration, either **upload it as a bundle** (above) or clone it during environment setup and reference it with a local path.

## How updates roll out

* **Manifest changes** (Settings → Resources → Plugins) apply to the **next session**.
* **Plugin changes** — merging to the branch a plugin tracks reaches new sessions automatically, within a few hours. Pin the plugin to a commit SHA to control updates yourself; on the CLI, `devin plugins update` refreshes immediately.
* Running sessions keep what they loaded at start — updates never change a session mid-flight.

## Scope and inheritance

Managed manifests exist at up to two levels:

* **Standalone accounts** have a single **account** manifest that applies to everyone.
* **Enterprises** have a shared **enterprise** manifest that is **inherited by every child org**, plus a per-**org** manifest layered below it. The Marketplace view shows both, and enterprise admins can choose to install a plugin at the enterprise scope (applies everywhere) or an org admin can install it at just their org.

These sit at the top of the overall plugin hierarchy, above repo- and user-level plugin config. See [inheritance and levels](/cli/extensibility/plugins/overview#inheritance-and-levels) for the other levels and the authority rules.

### Cloud sessions vs. the CLI

Both cloud Devin sessions and the [Devin CLI](/cli/index) enforce the **enterprise/account** manifest — required plugins are installed and forbids are enforced for CLI users logged into the account too.

The **org** manifest applies only to **cloud sessions**. The CLI authenticates at the account level and has no org context, so org-level requires and forbids don't reach CLI users. Put anything you need enforced in the CLI (or account-wide) in the enterprise/account manifest, and use the org manifest for org-specific additions to cloud sessions.

## Learn more

* [Skills](/product-guides/skills) — the `SKILL.md` procedures that plugins bundle
* [CLI plugins reference](/cli/extensibility/plugins/overview) — plugin file format, authoring, and per-user install
* [Playbooks](/product-guides/creating-playbooks) — reusable prompt templates attached to sessions