@Muhanand Definitely possible. But this app just by nature requires a more sophisticated manual setup.

@girish said in Update on community packages: Depending on how many packages my CustomAppGateway has ~25 apps, and there are more currently out there not added to it, and with 9.1, I would expect the numbers to double at least. I have no hesitancy with deferring 'app discovery' in favour of getting the core functionality available and working. I feel we will need a discovery place of some kind, relying on a forum post in an AppWishList topic might be viable as short and medium term. But catalogue / CUR / "awesome" style git package is likely needed longer term. And it's more polished / prettier

@marcusquinn your prompt reminded me about it. I will take off the very dusty shelf and look at it again.

Next release of romm should contain fixes for every issue I've found. I'd consider it usable at that point.

@James absolutely ! Very cool ! That was actually a break-through moment to get over blind poking and assessing output. So thank you again.

@timconsidine challenge accepted? You grow either way.

@Eliahou I packaged the signal bridge and now wanted to see how I can make encryption work. Root Cause: Synapse 1.141+ explicitly blocks appservice users from using /sync. The mautrix bridges were configured to poll /sync for encryption data, which caused HTTP 500 errors. Solution: Enabled appservice mode for end-to-bridge encryption, which uses MSC3202/MSC2409 to receive encryption data via appservice transactions instead of /sync. In specific this means: Changes Made Synapse: Added experimental features to homeserver.yaml: experimental_features: msc3202_transaction_extensions: true msc2409_to_device_messages_enabled: true Added org.matrix.msc3202: true to both bridge registration files Signal Bridge: Updated start.sh to set encryption.appservice = true Built and deployed andreasdueren/mautrix-signal:1.0.2 WhatsApp Bridge: Updated start.sh to set encryption.appservice = true Built and deployed andreasdueren/mautrix-whatsapp:2.0.2

@LoudLemur late reply not sure I understand your question so this answer may not be what you want but in picture form ... [image: 1768330247721-mermaid-diagram-2026-01-13-185009-resized.png]

Lets support Prosody XMPP server on Cloudron, now that we have Cloudron 9. https://github.com/prosody/prosody-docker Docker seems to be the new official way of installing Prosody.

Hello @timconsidine I can really recommend nvm to manage Node.js and NPM versions.

@robi said in Garage packaging status, next steps: More options is better than less IMHO In that spirit, I made my own package, principally so I could learn about Garage : https://forum.cloudron.io/post/117911

I see, I think. I'll try to work the API example into the start.sh script that runs when the app is started.

i was hardening it here is the repository link and tag samcorepa/appsmith-cloudron-ce:20251230-135540 [image: 1767103309577-333dfbea-62fc-4c51-a7a3-e6629bd2e248-image-resized.png]

The only "danger" of using a production Cloudron is that you use some CLI command by mistake. Like cloudron uninstall --app <some-domain-by-typo> . The CLI command is less forgiving when it comes to mistakes like that. i.e there is confirmation .

new! Updated to 1.0.1. codeberg.org/themeerkat/hecapte-cloudron:1.0.1 I added customization options: renaming sites, deleting sites, and specifying CORS(!) on registration. This should make it a lot easier to use.

This is a custom app based I am packaging on react-admin. I am currently just redirecting the user to {app}/logout on clicking logout. Any way to enable it for just the custom app?

Absolutely. That's an excellent and thorough answer, @james . Many, many thanks. Possible text: This add-on is intended for applications that already support OpenID Connect-based (OIDC) authentication. Apply this add-on to use Cloudron as an OpenID provider with an application that supports OIDC-based authentication. Possible improvement for proxyauth: The proxyauth add-on allows you to put an authentication wall in front of an application. This is useful in situations where the application has no authentication mechanisms of its own, or where there are features that you cannot easily turn off (for the general public), and you want to restrict access using Cloudron's built-in user and group management tools. I think the idea being that, in both cases, a bit more "why" might help. Either way, thank you. All of my questions are answered (including "oh, hey, there was an app packaging topic!").