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

[sanoker]

Hi everyone,

I am trying to set up the new official Penpot MCP (Model Context Protocol) server to integrate my self-hosted Penpot instance with local AI coding clients like Cursor and Claude Desktop.

Currently, this is impossible on the Cloudron deployment because the necessary UI elements ("Integrations" and "Access Tokens" in the account settings) are hidden behind Penpot feature flags that are not enabled in the Cloudron package.

Because Cloudron dynamically constructs PENPOT_FLAGS on startup, manually editing env.sh to add these flags gets ignored/overwritten.

Could we get one of the following implemented in the next package update?

Option A (Ideal): Enable the enable-mcp and enable-access-tokens flags by default in the app's startup script, as these are becoming standard features for modern AI workflows.

Option B (Flexible): Expose an EXTRA_PENPOT_FLAGS variable in env.sh that gets appended to the main string on startup. This would allow advanced users to opt-in to new Penpot backend features without waiting for package updates.

Thanks for maintaining this package! Let me know if there is a temporary workaround I can use in the meantime.

[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.