Quick follow-up here in case it helps anyone else debugging this.
We tested the updated Cloudron Penpot package with the new enable-access-tokens and enable-mcp flags. The flags do appear to be applied correctly — access tokens and the MCP-related UI/config are enabled — but the Penpot app itself does not appear to expose a usable MCP HTTP/SSE endpoint from the core backend.
In our checks:
/api/rpc/command/get-access-tokensexists and is auth-gated, so access-token support is working./mcp,/mcp/sse,/api/mcp,/api/mcp/sse,/mcp/streametc. did not resolve to a working MCP transport from the Penpot app itself.- The official Penpot MCP implementation appears to be a separate Node service/plugin bridge rather than just a backend route inside the main Penpot container.
- That service exposes, roughly:
- MCP HTTP endpoint on
/mcp - legacy SSE endpoint on
/sse - plugin WebSocket bridge on
/ws - static plugin assets such as
/manifest.jsonand/plugin.js
- MCP HTTP endpoint on
We got remote MCP working by deploying the official penpot-mcp service separately and proxying those routes through nginx. A few practical gotchas we hit:
- Build the plugin assets at image-build time, not runtime, because Cloudron app code is read-only at runtime.
- The plugin manifest/assets need CORS headers so the Penpot UI can install/fetch the plugin from another origin.
/mcpand/sseshould be auth-gated withuserToken./wsneeds proper WebSocket upgrade proxying.- The internal REPL/debug service should not be exposed publicly.
So I think the Cloudron Penpot package flags are useful and necessary, but full remote MCP support likely needs either:
- bundling/running the official
penpot-mcpservice alongside Penpot, or - documenting it as a companion app/service with nginx routes for
/mcp,/sse,/messages,/ws, and the plugin static assets.
Hope that saves someone else some digging.