Feature Request: Enable MCP and Access Tokens flags in Penpot (or expose EXTRA_PENPOT_FLAGS)

[james]

Hello @sanoker and welcome to the Cloudron forum

Can you please share what you have configured in the env.sh?

[sanoker]

I created a /app/data/env.sh file and tried adding the following line:

export PENPOT_FLAGS="enable-registration enable-login-with-password enable-access-tokens enable-mcp"

After saving the file and completely restarting the app via the Cloudron dashboard, the "Integrations" and "Access Tokens" UI elements still do not appear in the Penpot account settings.

My assumption was that the Cloudron deployment's internal startup script dynamically generates or overrides the PENPOT_FLAGS variable (perhaps to ensure SMTP or OIDC settings stay intact) and is ignoring the manual export in env.sh.

If there is a specific syntax I should be using in env.sh to append custom flags without them getting overwritten by the system, please let me know! Otherwise, having a supported way to inject flags like EXTRA_PENPOT_FLAGS would be really helpful.

[james]

Hello @sanoker
The @penpot app does not have the logic to handle an /app/data/env.sh file.
I can look into adding enable-access-tokens and enable-mcp to the app.

[Operator]

+1 for this.

I’ve just hit the same limitation on a Cloudron-hosted Penpot 2.16.0 instance.

The frontend bundle appears to include the MCP / access-token UI code, but the features are not available because the required flags are not active. In our live app, /js/config.js shows penpotFlags without enable-mcp or enable-access-tokens, and /mcp/stream, /mcp/sse, and /mcp/ws currently route to 404.

So I think this is exactly the right package-level fix:

• enable enable-access-tokens
• enable enable-mcp
• ideally expose something like EXTRA_PENPOT_FLAGS for future opt-in flags

The flexible EXTRA_PENPOT_FLAGS option would be especially useful because Penpot is moving quickly and Cloudron users may need to opt into new official features before the package defaults catch up.

Thanks for looking into this happy to test once there’s a package update or workaround.

[james]

Hello @sanoker and @operator
We have added the flags and added a handler for extra flags as suggested by @operator.
See: https://forum.cloudron.io/post/125878

[Operator]

Thank you so much @james really appreciate the quick roll out!

[sanoker]

Hi @james,

Thanks for the super quick response on adding those flags, really appreciate it.

Just wanted to give you a quick update. I actually managed to get things working via a local workaround - running the Penpot MCP server on my own machine and bridging it to the canvas using a browser plugin.

While trying to get the remote connection working earlier, though, I noticed that hitting https://[domain]/mcp/stream returns a standard HTML webpage instead of the expected SSE stream (text/event-stream). From what I can tell, I think Penpot’s MCP server might actually run as a separate standalone service or container, rather than being built directly into the core backend.

If that is the case, I think the Cloudron package might eventually need to bundle that extra container and map the Nginx routing for the /mcp/ paths to get remote connections working properly.

There's no rush since my local setup is doing fine, but I figured I'd pass this along in case it saves you some debugging time.

[Operator]

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-tokens exists and is auth-gated, so access-token support is working.
• /mcp, /mcp/sse, /api/mcp, /api/mcp/sse, /mcp/stream etc. 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.json and /plugin.js

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.
• /mcp and /sse should be auth-gated with userToken.
• /ws needs 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:

1. bundling/running the official penpot-mcp service alongside Penpot, or
2. 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.

[james]

Hello @sanoker and @operator
Thanks for the great insights.
Will have to look into that penpot-mcp service.

[BenjaminJ]

Following up on this thread with the state on the current package (1.18.3 / Penpot 2.16.2). The flags @james added are working, and /mcp now resolves. However, the in-app MCP plugin still can't load, which blocks File → MCP Server → Connect. This is exactly the missing piece @Operator described (the frontend plugins/ static assets aren't served).

Current state on 1.18.3:

• [v] enable-mcp + enable-access-tokens are in /app/pkg/start.sh and served in /js/config.js (penpotFlags).
• [v] /mcp now returns 200 (progress vs the earlier 404s in this thread).
• In a design file,
  File → MCP Server → Connect fails. Browser console:

Plugin Error: Failed to load plugin code
GET https://penpot.inno3.eu/plugins/mcp/plugin.js  404 (Not Found)

Root cause (confirmed): the frontend loads the bundled MCP plugin from ${PENPOT_PUBLIC_URI}/plugins/mcp/…, but the nginx root /app/code/frontend has no plugins/ directory -- the files don't exist anywhere in the container. The upstream image already ships them:

$ docker export $(docker create penpotapp/frontend:2.16.2) | tar -tf - | grep plugins/mcp
var/www/app/plugins/mcp/
var/www/app/plugins/mcp/assets/index-JunN9mS-.css
var/www/app/plugins/mcp/icon.jpg
var/www/app/plugins/mcp/index.html
var/www/app/plugins/mcp/index.js
var/www/app/plugins/mcp/manifest.json
var/www/app/plugins/mcp/plugin.js

For reference https://design.penpot.app/plugins/mcp/plugin.js returns 200; ours returns 404. Related: our config.js exposes none of the penpotPlugins* vars (penpotPluginsWhitelist, penpotPluginsListUri, …), so the Plugins manager panel is unavailable too for same root cause.

As @Operator noted, /app/code is read-only at runtime, so this needs to be handled at image-build time. It looks like copying the upstream frontend plugins/ directory into the served root (and exposing the PENPOT_PLUGINS_* config in config.js) would light up both the native MCP plugin and the Plugins manager, without needing to bundle the separate penpot-mcp Node service. Happy to test a patched package on our instance.