How to deploy the CloudBees CI MCP Router with rootless Docker

Issue

The public installation documentation for the CloudBees CI MCP Router does not state whether rootless Docker is a supported way to run the container, and does not document any Docker Engine security requirements. Teams whose security policy requires a non-root Docker daemon, or who are installing Docker for the first time specifically to run the CloudBees CI MCP Router, need confirmation before choosing a deployment approach.

Environment

CloudBees CI MCP Router (Docker deployment)
CloudBees CI on modern cloud platforms - operations center
CloudBees CI on traditional platforms - operations center
MCP Server plugin

Resolution

Rootless Docker is supported for running the CloudBees CI MCP Router. This was confirmed by running the container under a genuine RootlessKit-based Docker daemon (the official docker:dind-rootless image), not just a container with reduced capabilities under a normal rootful daemon. Under that daemon, the CloudBees CI MCP Router connected to Operations center, discovered managed controllers, and executed real MCP tool calls (whoAmI, getJobs, getStatus) returning live data, the same as under a standard rootful Docker daemon.

Two configuration points apply when deploying the CloudBees CI MCP Router in Operations center mode, independent of whether the Docker daemon itself is rootless or rootful.

Install the MCP Server plugin on Operations center as well as on each controller

The public install documentation says to install MCP Server plugin "on your controllers" without specifying scope. For Operations center mode, where the CloudBees CI MCP Router discovers controllers through Operations center rather than connecting to each one directly, MCP Server plugin must be installed on Operations center itself, not only on each controller it manages. Without it, Operations center-mode discovery (the getControllers tool) fails even though the plugin is correctly installed on every managed controller.

Ensure each controller’s registered Jenkins URL is reachable from wherever the router runs

Operations center registers a Jenkins URL for every connected controller, and the CloudBees CI MCP Router uses that registered URL directly once it has the list of controllers from Operations center — it does not go through a browser or the load balancer that end users normally use to reach the same controller.

If the CloudBees CI MCP Router runs in a different network context than where administrators access Operations center’s UI, for example in a Docker container on a different host or network namespace, confirm that each controller’s registered URL resolves and is reachable from that specific network context, not just from a browser. If it is not reachable, update the controller’s registered Jenkins URL to an address that is reachable from the CloudBees CI MCP Router’s network, for example through a JenkinsLocationConfiguration override.

Verify a rootless Docker deployment

Confirm the Docker daemon the CloudBees CI MCP Router will run under is actually running rootless:
```
docker info | grep -A2 "Security Options"▼
```
A genuinely rootless daemon reports rootless in the security options, for example:
```
Security Options:
 rootless
  NoNewPrivileges: true▼
```
Start the CloudBees CI MCP Router normally against that daemon.

Confirm the CloudBees CI MCP Router connects to Operations center and lists controllers:

curl -sN -X POST http://localhost:9000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"getControllers","arguments":{}}}' | jq▼

References

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.