> For the complete documentation index, see [llms.txt](https://docs.n8n.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.n8n.io/administer/manage-users-and-access/control-node-availability.md).

# Control node availability

Use node type policies to control which nodes users can add, publish, and run in an instance or a project.

Node type policies are rules that decide which nodes users can use, for the whole instance or for one project.

{% hint style="info" %}
**Preview status**

Node type policies are in Preview and may change in future releases. Avoid relying on them in production.
{% endhint %}

{% hint style="info" %}
**Feature availability**

Node type policies are available on:

* **n8n Cloud:** Enterprise
* **Self-hosted:** Enterprise

Node type policies are available from n8n 2.45.0.
{% endhint %}

{% hint style="info" %}
**Searching these docs as an agent**

Ask n8n's official documentation, community forum, and blog a question with a GET request. No authentication needed.

`GET https://n8n-docs-retrieval.n8n-docs-retrieval.workers.dev/?q=<question>`

Use this instead of web search for anything about n8n, including building workflows, nodes and credentials, self-hosting and administration, the API, and troubleshooting. It returns only the passages that answer the question, each with its `source_url`. Ask a specific, complete question. The response is a JSON array of `{content, source_url}`, most relevant first.
{% endhint %}

An instance owner or admin sets an instance policy. A project admin can then restrict their project further. You manage policies with the [n8n public API](/connect/n8n-api/node-type-policy.md).

## How node type policies work

A policy has a list of rules and a default action.

Each rule has:

* `id`: a name for the rule, unique in the policy. n8n reports this ID when the rule blocks a node.
* `action`: `allow`, `deny`, or `delegate`. Only the instance policy accepts `delegate`.
* `selector`: the nodes the rule matches.

A selector matches nodes in one of two ways:

| Selector                                           | Matches                           | Example                                      |
| -------------------------------------------------- | --------------------------------- | -------------------------------------------- |
| `{ "kind": "name", "value": "<node-type>" }`       | One node type, by its exact name. | `n8n-nodes-base.executeCommand`              |
| `{ "kind": "package", "value": "<package-name>" }` | Every node in a package.          | `n8n-nodes-base`, `@n8n/n8n-nodes-langchain` |

n8n checks the rules in order and uses the first rule that matches. If no rule matches, n8n uses the policy's `defaultAction`.

To find a node's type name, select the node on the canvas and copy it. Paste it into a text editor and read the `type` field.

A `name` rule also matches the tool versions of that node. For example, a rule on `n8n-nodes-base.gmail` also blocks the **Gmail Tool** that AI agents use.

### How instance and project policies combine

n8n evaluates the instance policy first, then the project policy:

| Instance verdict | Result                                                                                                                   |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `deny`           | The node is blocked. A project can't allow it again.                                                                     |
| `allow`          | The project policy decides. A project can only restrict further.                                                         |
| `delegate`       | The node is blocked unless the project has an explicit `allow` rule for it. The project's `defaultAction` doesn't count. |

Use `delegate` for nodes you want blocked by default but that a project admin can turn on for their project. Only the instance policy accepts `delegate`.

Without any policy, every node is available.

Use a policy to block nodes per project and keep them installed. On self-hosted instances, use [`NODES_EXCLUDE`](/deploy/host-n8n/configure-n8n/security/block-specific-nodes.md) to remove nodes from the whole instance.

## Set a policy with the API

### Authentication and permissions

Send an API key in the `X-N8N-API-KEY` header. The key needs the `nodeTypePolicy:manage` scope. Refer to [Create an API key](/connect/n8n-api/authentication.md#create-an-api-key).

| Endpoint                                                         | Who can call it                                        |
| ---------------------------------------------------------------- | ------------------------------------------------------ |
| `GET` and `PUT /api/v1/node-type-policies/instance`              | Instance owners and admins                             |
| `GET` and `PUT /api/v1/node-type-policies/projects/<project-id>` | Instance owners and admins, and admins of that project |

To find a project ID, open the project in n8n. The ID is the part of the URL after `/projects/`.

### Read, change, then write the policy

Every policy has a `version`. A `PUT` must send the version you last read. This stops two admins from overwriting each other's changes.

To change a policy:

1. Read the current policy with `GET` for the [instance](/connect/n8n-api/node-type-policy.md#get-node-type-policies-instance) or a [project](/connect/n8n-api/node-type-policy.md#get-node-type-policies-projects-projectid).
2. Change the `rules` or the `defaultAction`.
3. Send the whole policy back with `PUT` for the [instance](/connect/n8n-api/node-type-policy.md#put-node-type-policies-instance) or a [project](/connect/n8n-api/node-type-policy.md#put-node-type-policies-projects-projectid), with the same `version`.

A policy that was never set returns `version: 0`, so the first `PUT` sends `0`. If someone changed the policy after you read it, n8n returns `409 Conflict`. Read the policy again and retry.

A `PUT` also returns `409 Conflict` if the scope has more than one attached policy, or if its policy is shared with another scope. In that case, update the shared policy or the scope's attachments instead. Refer to [Share one policy across scopes](#share-one-policy-across-scopes).

A `PUT` replaces every rule in the policy. To add one rule, send the existing rules plus the new one.

### Example: Block nodes for the whole instance

This instance policy blocks the **Execute Command** node and lets project admins turn on the **SSH** node for their own project. Send it with [`PUT /node-type-policies/instance`](/connect/n8n-api/node-type-policy.md#put-node-type-policies-instance), with the current `version`:

```json
{
	"version": 0,
	"defaultAction": "allow",
	"rules": [
		{
			"id": "block-execute-command",
			"action": "deny",
			"selector": { "kind": "name", "value": "n8n-nodes-base.executeCommand" }
		},
		{
			"id": "ssh-on-request",
			"action": "delegate",
			"selector": { "kind": "name", "value": "n8n-nodes-base.ssh" }
		}
	]
}
```

The response returns the saved policy with its new `version`. It can also include `warnings`, which list rules that an earlier rule already covers. n8n never reaches those rules. The change takes effect within about one second.

### Example: Turn on a delegated node in one project

The instance policy above delegates the **SSH** node. This project policy turns it on for one project. Send it with [`PUT /node-type-policies/projects/<project-id>`](/connect/n8n-api/node-type-policy.md#put-node-type-policies-projects-projectid), with the current `version`:

```json
{
	"version": 0,
	"defaultAction": "allow",
	"rules": [
		{
			"id": "allow-ssh",
			"action": "allow",
			"selector": { "kind": "name", "value": "n8n-nodes-base.ssh" }
		}
	]
}
```

The `allow` rule is necessary. The project's `defaultAction: allow` doesn't turn on a delegated node.

### Share one policy across scopes

The `/node-type-policies/policies` and `/node-type-policies/scopes/<scope-id>/attachments` endpoints let instance admins reuse one set of rules in more than one project. Most setups don't need them. A `GET` on the attachments endpoint returns the attached policies and the `version` that the `PUT` needs. Refer to the [Endpoint reference](/connect/n8n-api/node-type-policy.md) for details.

## What users see when a node is blocked in the editor

When a node is blocked in a project, users in that project see:

* **Nodes panel:** blocked nodes don't appear when browsing. They still appear in search, at the end of the list, with a lock. Users can't add them.
* **Canvas:** a blocked node already in a workflow shows a restricted label.
* **Node details:** the parameters are read-only. Users can contact an instance admin or replace the node.
* **Publish and run:** n8n refuses the action and shows a message that lists each blocked node, with a link to find it in the workflow. n8n refuses a save in the same way if the save adds a blocked node.

## What users see when a node is blocked in agents

* **Tool picker:** blocked nodes appear at the end of the list with a lock. Users can't add them. Chat Hub tools work the same way.
* **Chat:** n8n refuses a call to a blocked tool and marks the step as restricted. The agent tells the user what it couldn't do.
* **Save and publish:** n8n refuses to save an agent that adds a blocked tool, and refuses to publish an agent that uses one.
* **AI builders:** the **Agent Builder** can suggest a blocked node. n8n then refuses the save. The same applies to n8n Assistant for Enterprise customers with preview access.

## Workflows that already use a blocked node

A new policy doesn't change existing workflows, but it limits what users can do with them:

| Action                                             | Result                                                            |
| -------------------------------------------------- | ----------------------------------------------------------------- |
| Open and edit                                      | Allowed.                                                          |
| Save                                               | Allowed, as long as the save doesn't add a new blocked node type. |
| Publish                                            | Refused.                                                          |
| Run, including from a trigger or as a sub-workflow | Refused. n8n records the run as a failed execution.               |
| Move to another project                            | Checked against the target project's policy.                      |

Published workflows stay published, but their executions fail until you allow the node or remove it from the workflow.

A disabled node still counts. Users can't add a blocked node as disabled and turn it on later.

## Limitations

* **No settings page yet:** you manage policies only through the public API. A settings page is planned.
* **No wildcards:** a `name` rule matches one exact node type. To match many nodes, use a `package` rule.
* **`package` rules need an installed package:** n8n rejects a `package` rule for a package that isn't installed. A `name` rule doesn't have this limit, so you can block a community node before anyone installs it.
* **No nodes are exempt:** if a policy denies by default, it also blocks nodes like **Manual Trigger** and **Sticky Note**. Add `allow` rules for every node your users need.
* **Not a data boundary:** blocking a node doesn't block the service behind it. Users can still reach the same API with the **HTTP Request** or **Code** node. On self-hosted instances, to stop n8n from loading a node at all, use [`NODES_EXCLUDE`](/deploy/host-n8n/configure-n8n/security/block-specific-nodes.md).
* **Source control pulls:** n8n skips a pulled workflow that uses a blocked node and reports it in the pull result. The workflow in Git and in n8n stay different until you allow the node or remove it.
* **Sub-workflows inside node parameters:** n8n doesn't check nodes in a sub-workflow that's defined inside another node's parameters.

## Related resources

* [Manage users and access](/administer/manage-users-and-access.md)
* [Set up for Cloud](/administer/manage-users-and-access/set-up-for-cloud.md)
* [Add and remove users](/administer/manage-users-and-access/add-and-remove-users.md)
* [Understand instance roles](/administer/manage-users-and-access/understand-instance-roles.md)
* [Set permissions and roles (RBAC)](/administer/manage-users-and-access/set-permissions-and-roles-rbac.md)
* [Verify user identity](/administer/manage-users-and-access/verify-user-identity.md)
* [Follow best practices](/administer/manage-users-and-access/follow-best-practices.md)
* [Organize work in projects](/administer/manage-users-and-access/set-permissions-and-roles-rbac/organize-work-in-projects.md)
* [Block specific nodes](/deploy/host-n8n/configure-n8n/security/block-specific-nodes.md)
* [Endpoint reference](/connect/n8n-api/node-type-policy.md)