Cloudron Forum

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.

Awesome, thank you @girish ! We'll pull the package update and confirm 4-byte writes (emoji) go through.

Hi,

On our Dolibarr install (Cloudron, MySQL addon), creating a ticket (or any record) that contains a 4-byte character (e.g. an emoji ) fails with:

Incorrect string value: '\xF0\x9F\x98\x8A...' for column 'message'

Root cause: the database and all schema tables are already utf8mb4 (the Cloudron MySQL addon defaults to utf8mb4). The only utf8mb3 link in the chain is the connection charset, which the package hardcodes in /app/pkg/cloudron.conf.php:

$dolibarr_main_db_character_set = 'utf8';        // = utf8mb3, 3 bytes max
$dolibarr_main_db_collation     = 'utf8_unicode_ci';

So Dolibarr issues SET NAMES utf8, and MySQL rejects any 4-byte character on write.

Because cloudron.conf.php is included after /app/data/conf/conf.php (and is read-only), users cannot override the charset persistently — any change in /app/data/conf/conf.php gets overwritten.

Suggested fix — set in cloudron.conf.php:

$dolibarr_main_db_character_set = 'utf8mb4';
$dolibarr_main_db_collation     = 'utf8mb4_unicode_ci';

(Ideally also guard it so /app/data/conf/conf.php can override.) Existing installs already have utf8mb4 tables, so this only aligns the connection — no data migration needed.

Thanks!