To be honest, the only tricky part (in general for cloudron apps) are the env vars. When updating an app, always make sure to FIRST set the new env vars (it only works when the app is running... and if the app depends on a var to start, well.... ) and THEN update the container. I'm using Buddy selfhosted as my CI/CD and build a template which i can just duplicate for every cloudron app. Push to git -> build image -> push image -> set env vars on cloudron -> update cloudron

@nebulon I see. Ok this solves it for me. Yes build build left me spinning last week but I understood eventually

We ran an automated assessment of how difficult it would be to package and then maintain Prosody as an application on Cloudron. The assessment is here (TL/DR - it would be a lot more feasible than Ejabberd): https://wanderingmonster.dev/blog/monster-manual-prosody/ https://enjoys.rocks/?8957edc0c6a1b7fa#DdSoHsPAZQwxnUHuNVfiQcdFd6soCFf8XLRogrXTNpgy

@ekevu123 if you have a startup.sh or other launch script, it is common to have the script touch /app/data/initialized during first setup, all setup inside a test whether .initialized is present or not. If so, skip setup. If not, then do setup. Setup including key generation. I haven't reviewed how you launch the app, so not sure how viable it is for you, but it's very common for other apps. if [ ! -f /app/data/.initialized ]; then cp -a -n /app/code/defaults/config/. /app/data/config/ || true touch /app/data/.initialized fi

Thanks @girish TBH, most people don't read docs despite all this Yep, true Soon there won't be any docs. AI coding agent utility will produce some illegible binary asset "cloudron.aifood", which another agent will use. We humans won't need to know or read anything. Thanks @nebulon maybe better some https://foo.bar/changelog link nice idea, let me think about that. testing my build script which makes it a mandatory input (to overcome my lack of discipline )

Yes the format is described in https://docs.cloudron.io/packaging/manifest#changelog Using the .md extension is not really relevant, however it might render the file better in git hosting apps.

Stubborn dog-with-a-bone that I am, I did more research, and hopefully this can put to bed my diversion of the thread (sorry), and maybe help others with a similar use case / workflow objective to mine : Forgejo (official Cloudron AppStore) provides standard git source code functionality AND it has a built-in container registry functionality so no need to consider changes to the official docker registry app for public pulls forgejo supports private and public repos (which git.cloudron.io does not) forgejo supports public image pulls (like hub.docker.com) but also multiple private containers (hub.docker.com only allows 1) I can uninstall docker registry app and gitea/gitlab apps, multiple used for segregating cloudron community work from closed app dev, using Forgejo organization instead. So the answer for my bandwidth-limited brain of 1 app for (almost) everything seems to be Forgejo (available today, no dev work). However, @girish made valuable comment that hosting container images is a disk/network usage risk. Even for a small dev footprint like mine, this could be critical (let alone Cloudron scale). I need to think & test out, but maybe Forgejo actions can automate container push to hub.docker.com, and do automated cleanup in the instance. So from dev point of view it's a single answer (Forgejo) with CI/CD offloading disk/network risks to hub.docker.com (or whatever).

You already got it, but often proxyAuth is the simplest.

Hello @aaaaargzombies @aaaaargZombies said: TLDR I'm on version 9.0.17 and should try upgrading. Yes, you should update to Cloudron 9.1.3 for cloudron install to work without the need to build and push the image before installing.

Hello @themeerkat I have added your package to the list: https://forum.cloudron.io/topic/15172/community-apps

@eyecreate amazing! I'll be installing this I think

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

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

@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