Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps - Status | Demo | Docs | Install
O

Operator

@Operator
Unfollow Follow
About
Posts
5
Topics
1
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Feature Request: Enable MCP and Access Tokens flags in Penpot (or expose EXTRA_PENPOT_FLAGS)
    O 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.

    Penpot

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

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

    Penpot

  • Feature Request: Enable MCP and Access Tokens flags in Penpot (or expose EXTRA_PENPOT_FLAGS)
    O 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.

    Penpot

  • Public share links do not work
    O Operator

    Perfect thankyou @joseph the issue was the settings of the collection. In order for the public share link to work the entire collection has to be public and viewable by everyone in the workspace it seems

    Outline

  • Public share links do not work
    O Operator

    When creating a public share link using on a document - the link redirects to a login page.

    To my understanding a public sharing link is supposed to be read-only by anyone with the link not only users of the outline instance.

    Is this a bug or do I need to configure something other than the toggle button in the preference settings?

    Outline
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search