workloads should be run, such as machines that meet [PCI-SS
compliance](https://www.pcisecuritystandards.org/).
A compromised worker could not compromise these special workloads because it
cannot change node labels.
Engine labels, however, are still useful because some features that do not
affect secure orchestration of containers might be better off set in a
decentralized manner. For instance, an engine could have a label to indicate
that it has a certain type of disk device, which may not be relevant to security
directly. These labels are more easily "trusted" by the swarm orchestrator.
Refer to the `docker service create` [CLI reference](/reference/cli/docker/service/create.md)
for more information about service constraints.
### Promote or demote a node
You can promote a worker node to the manager role. This is useful when a
manager node becomes unavailable or if you want to take a manager offline for
maintenance. Similarly, you can demote a manager node to the worker role.
> [!NOTE]
>
> Regardless of your reason to promote or demote
> a node, you must always maintain a quorum of manager nodes in the
> swarm. For more information refer to the [Swarm administration guide](admin_guide.md).
To promote a node or set of nodes, run `docker node promote` from a manager
node:
```console
$ docker node promote node-3 node-2
Node node-3 promoted to a manager in the swarm.
Node node-2 promoted to a manager in the swarm.
```
To demote a node or set of nodes, run `docker node demote` from a manager node:
```console
$ docker node demote node-3 node-2
Manager node-3 demoted in the swarm.
Manager node-2 demoted in the swarm.
```
`docker node promote` and `docker node demote` are convenience commands for
`docker node update --role manager` and `docker node update --role worker`
respectively.
## Install plugins on swarm nodes
If your swarm service relies on one or more
[plugins](/engine/extend/plugin_api/), these plugins need to be available on
every node where the service could potentially be deployed. You can manually
install the plugin on each node or script the installation. You can also deploy
the plugin in a similar way as a global service using the Docker API, by specifying
a `PluginSpec` instead of a `ContainerSpec`.
> [!NOTE]
>
> There is currently no way to deploy a plugin to a swarm using the
> Docker CLI or Docker Compose. In addition, it is not possible to install
> plugins from a private repository.
The [`PluginSpec`](/engine/extend/plugin_api/#json-specification)
is defined by the plugin developer. To add the plugin to all Docker nodes, use
the [`service/create`](/reference/api/engine/v1.31/#operation/ServiceCreate) API, passing
the `PluginSpec` JSON defined in the `TaskTemplate`.
## Leave the swarm
Run the `docker swarm leave` command on a node to remove it from the swarm.
For example to leave the swarm on a worker node:
```console
$ docker swarm leave
Node left the swarm.
```
When a node leaves the swarm, Docker Engine stops running in Swarm
mode. The orchestrator no longer schedules tasks to the node.
If the node is a manager node, you receive a warning about maintaining the
quorum. To override the warning, pass the `--force` flag. If the last manager
node leaves the swarm, the swarm becomes unavailable requiring you to take
disaster recovery measures.
For information about maintaining a quorum and disaster recovery, refer to the
[Swarm administration guide](admin_guide.md).
After a node leaves the swarm, you can run `docker node rm` on a
manager node to remove the node from the node list.
For instance:
```console
$ docker node rm node-2
```
## Learn more
* [Swarm administration guide](admin_guide.md)
* [Docker Engine command line reference](/reference/cli/docker/)
* [Swarm mode tutorial](swarm-tutorial/_index.md)