Plugin marketplace

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

Plugins are in closed beta. To request access, contact [e-mail]. Behavior and configuration may change in future releases.

What are plugins?

A plugin is a bundle of skills — and optionally rules, hooks, and MCP servers — packaged together so it can be installed and reused as a unit. Where a skill lives in a single repo, a plugin is a portable source (a GitHub repo, a git URL, a subfolder of a repo, or an uploaded .zip) that you can require across your whole org or enterprise.

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 users logged into the account (enterprise/account-level config reaches the CLI too — see 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 cloud (web app) side of plugins. For the plugin file format and the CLI’s per-user install flow, see the CLI plugins reference.

Where to configure them

Go to 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 — 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:

{
  "requiredPlugins": [
    // GitHub owner/repo
    "acme/review-tools",

    // any git URL
    "https://gitlab.com/acme/secure-base.git",

    // object form
    { "source": "github", "repo": "acme/audit-logging" },

    // a plugin living in a subfolder
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "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 (e.g. acme/*, or "*" for a full lockdown).

Each entry in requiredPlugins / optionalPlugins is a source — either a string shorthand or an object:

Form	Meaning
"owner/repo"	GitHub repository
"https://…", "git@…", "ssh://…"	any git URL
{ "source": "github", "repo": "owner/repo" }	GitHub, object form
{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }	git URL, object form
{ "source": "git-subdir", "url": "…", "path": "sub/dir" }	a plugin living in a subfolder of a shared repo

All GitHub forms for the same repo (owner/repo, the HTTPS URL, the .git URL, the SSH form) refer to the same plugin identity.

The manifest is stored verbatim; the agent validates the full source at install time.

Governance rules

forbiddenPlugins entries are matched against plugin identities:

• An exact identity, written as owner/repo or a git URL. All GitHub forms of the same repo (owner/repo, the HTTPS URL, the .git URL, the SSH form) refer to the same identity.
• A glob pattern — any entry containing *. The * matches any sequence of characters, including /: acme/* matches all of acme’s GitHub repos, */secrets matches a repo named secrets under any owner, and https://gitlab.com/acme/* matches any repo under that path.
• The lone "*", which matches everything else (a full lockdown).

The lists combine deny-wins:

• Deny wins. A plugin is blocked if any active manifest or installed plugin forbids it. If nothing forbids anything, nothing is blocked.
• Self-override. A manifest’s (or plugin’s) own requiredPlugins and optionalPlugins — and, for a plugin, the plugin itself — are exempt from its own forbidden list, so "forbiddenPlugins": ["*"] plus "optionalPlugins": ["acme/approved"] means “allow only what this manifest lists; forbid everything else.” The carve-out covers only those direct entries, not a required plugin’s transitive dependencies — list those explicitly under a lockdown.
• No cross-scope re-permitting. One manifest’s or plugin’s allow-list cannot re-permit what another forbids. A "forbiddenPlugins": ["*"] lockdown can’t be defeated from a lower scope.

Enforcement happens at two points:

• Install time — installing a blocked plugin (or one whose required plugins can’t be satisfied, or whose name collides with an installed plugin) is refused.
• Load time — a plugin blocked after it’s already installed stays on disk, but its skills are skipped at session start with a warning naming the forbidder.

On top of these rules, managed manifests are tiered — enterprise/account above org above repo- and user-level plugin config. Higher authority wins: a lower tier can never forbid a plugin a higher tier requires, and can never re-permit one a higher tier forbids. So an org forbid can’t block an enterprise-required plugin, but an enterprise forbid overrides an org require.

Adding your own plugins

A plugin is just a directory containing a .devin-plugin/plugin.json manifest and a skills/ folder of ordinary skills:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, and optional dependency lists
├── AGENTS.md           # optional always-on rule
├── rules/              # optional triggered rules
├── hooks.json          # optional lifecycle hooks
├── mcp_config.json     # optional MCP servers
└── skills/
    └── review/
        └── SKILL.md    # an ordinary skill

Beyond skills, a plugin can ship:

• Rules — an AGENTS.md at the plugin root is injected as an always-on rule in every session — in cloud sessions and the CLI alike. Markdown files in a rules/ folder are loaded too, honoring their trigger frontmatter — see the CLI plugins reference.
• Hooks — a hooks.json at the plugin root registers lifecycle hooks that run in the session. Cloud sessions run command hooks for every event except SessionStart and SessionEnd — so PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop, and PostCompaction all work; prompt-type hooks are CLI/local-only.
• MCP servers — an mcp_config.json at the plugin root declares MCP servers ("mcpServers": { "<name>": { … } }) that load in every session where the plugin is installed. They don’t yet appear in the MCP settings UI, but their tools are available to Devin. A plugin’s MCP config may set an OAuth client ID and scopes, but never an OAuth client secret — a server config carrying one is rejected at activation.
• Custom subagents — agents/<name>.md (or agents/<name>/AGENT.md) profiles. These currently load only in local Devin agents — the Devin CLI and Devin Desktop — not in cloud sessions.

The plugin is the unit of installation: installing it installs all of its skills (plus anything in its requiredPlugins) — you can’t install individual skills from a plugin. To offer skills separately, split them into separate plugins. See the CLI plugins reference for the full plugin.json format and local authoring flow.

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 for how auth works
Subfolder of a repo (e.g. a monorepo of plugins)	{ "source": "git-subdir", "url": "…", "path": "sub/dir" } — each subfolder is its own plugin
Not in a repo at all	Upload it as a bundle (below)

One repo (or one git-subdir subfolder) is one plugin. A single repo can host many plugins as subfolders, each referenced with its own git-subdir entry.

Uploading a plugin bundle

On the 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. 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 → Marketplace) 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.

Compatibility

Claude plugins work too: if there’s no .devin-plugin/plugin.json, Devin falls back to a .claude-plugin/plugin.json. When both manifests are present, the Devin one wins.

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 any per-repo or per-user plugin configuration:

1. Enterprise / account manifest (this page)
2. Org manifest (this page)
3. Repo-level plugin config (a repo’s .devin/config.json)
4. User-level plugins — a person’s own CLI installs, which apply only to their local Devin agent and never load in cloud sessions

Higher authority wins: a lower level can never permit a plugin a higher level forbids, or forbid one a higher level requires (see governance rules).

Cloud sessions vs. the CLI

Both cloud Devin sessions and the Devin CLI 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 — the SKILL.md procedures that plugins bundle
• CLI plugins reference — plugin file format, authoring, and per-user install
• Playbooks — reusable prompt templates attached to sessions