@joseph Yes, I thought I mentioned that just before the apache app.conf. It does. Thanks for chiming in!

Hi @girish, @nebulon, and team, I've updated the Typesense package to address the backup roadblock from the docs (https://typesense.org/docs/guide/backups.html#backup-steps). This should make it compatible with Cloudron's strategy for database-like apps. Key changes in v29.0.1: Added "localstorage" addon for persistent /app/data (includes DB files and snapshots). Defaulted data-dir to /app/data in start.sh. Added backup.sh to trigger a full server snapshot via /operations/snapshot API, saving to snapshots/latest.tar (relative to /app/data). It backs up all collections automatically and checks for success. Added restore.sh to untar latest.tar on startup if present, ensuring consistent restores. Improved logging for the API key in start.sh. Tested on my live install (search.daveswift.com with existing collections)—backup creates the snapshot file, and restore loads it on restart without issues. The snapshot is a complete dump of all data, per Typesense docs. Repo: https://github.com/clientamp/typesense-cloudron (changes on main, see CHANGELOG.md). Latest image: clientamp/typesense-cloudron:29.0.1 (or timestamped builds like 20250929-111100). For integration, Cloudron could run backup.sh via a hook before filesystem backup, then ignore raw DB files. Happy to add more (e.g., compression). Thanks!

@girish said in Matrix WhatsApp Bridge: "extensions" to apps by third parties is quite a burden for app packages. I understand that it needs to be feasible to maintain these kind of things. Cloudron needs to be profitable after all. I hope we can find some solution for these things, especially if they're simple go binaries like this one.

@scooke raises some valid points about user expectations, and I will freely admit that I am not sure where or how the line should be drawn. Conceptually there is indeed some friction between : user is not comfortable installing CLI tools and docker and using them, effectively setting a competence bar and edging them out of this activity making it easier to do what they're not comfortable with, effectively lowering that bar and inevitably encountering support requests if/when it becomes normal/easy to install unsupported apps (via @Kubernetes scripts, my tool or an official way) However I am clear on these points : installing custom apps should be easier (hence my app) : on one level, it's purely and simply a timesaver, e.g. for a user who is competent in installing apps, at least that's how I am using my tool currently nothing wrong in concept with Cloudron providing an official GUI for installing custom apps (Cloudron has already provided the CLI and know-how for non-gui) support line must be clear : Cloudron as a team/business are not responsible for custom apps (not supported, not maintained) if properly handled, easier installation of custom apps can reduce forum pressure on Cloudron team for new apps into the AppStore I like @scooke idea of a pop-up confirmation box or similar : clarity and disclaimer is good. Whether it goes as far as requiring a reboot of the Cloudron instance, I'm not sure. But I will add a disclaimer box to my app. Beyond that, it gets a bit unclear for me : does the packager provide support (my view : only optionally / voluntary / reasonable efforts) do packagers need a reputation score (my view : nice but not viable as a formal rating, who has time and authority to set these, instead maybe some unofficial star rating 1-5 from users with successful deployment of a custom app) can an installer for custom apps provide a monetisation mechanism (comment from @girish) which effectively incentivises packagers to work through the AppWishlist (my view : yes, it could, but it's another layer on-top) should support for installed custom apps be channelled (a) into an UNSUPPORTED category of existing Cloudron forum, or (b) very deliberately into a different forum (my view : B makes a point but A is easier and more natural) @scooke said in Installing custom Apps on Cloudron: Please do not turn Cloudron into another messy Yunohost. I agree 100% on this. It must definitely be the goal of any efforts in this area. Equally, IMHO, standing still is not an option. We have too many well-intentioned but actually not-our-business "lectures" about how Cloudron should expand, and also too many "please please please" requests, pointing to unmet user demand. We cannot be like King Canute trying to push the waves back.

Yes, thank you, this has worked perfectly!

Bumping to let people know I have not forgotten, its just been a busy summer for me!

@girish said in Install new custom app with environment variables?: @ekevu123 cloudron install --env ENV1=1 ENV2=2 --location subdomain . Then, you can verify using cloudron env list. Thank you! I think this is the best solution for this problem.

Thank you @James In the interim, I am attempting a workaround <can't find fingers-crossed emoji>

@girish thanks for looking into it all working now, so probably a glitch somewhere, not worth investigating further

I've my Last.fm account since 2010, but nowadays I'm also scrobbling to https://listenbrainz.org/ as a backup in case Last.fm dies. I also aim to make my own scrobbler/stats independently from ListenBrainz and Last.fm, taking inspiration from https://coryd.dev/posts/2024/tracking-the-music-i-listen-to and https://sive.rs/ti

Okay, thank you for the advise!

Ok the docker issue is on their end. I'll wait until tomorrow to clean all the images on my repo up. I've posted about this app on the Wishlist section to see if there is any interest in putting in on the App Store.

I'm happy to say that I've moved my XMPP server from NethServer to Cloudron. While this is probably not a common move, I am sharing some notes here in case it helps someone else. Also, perhaps this'll cause Cloudron to show up in a few more searches. Install XMPP on Cloudron using the steps above. A bit manual for now! Dump your ejabberd data (that's the XMPP server NethServer uses) with this command: /opt/ejabberd-20.04/bin/ejabberdctl --config-dir /etc/ejabberd dump /etc/ejabberd/xmpp_dump.txt Download this dump file locally For ease, clone the source for prosody to your local computer so you can utilize the migration tools and not install needless packages on Cloudron. You'll need to run ./configure and ./make - but you don't need to actually install it. Don't be a Lua noob. I spent a while struggling to get my Lua environment setup, and thought I needed to run the tools like lua ejabberd2prosody.lua but got lots of errors about dependencies missing. Once I figured out you need to execute it directly like ./ejabberd2prosody.lua things worked fine. run the ejabberd2prosody.lua script on your xmpp_dump.txt file: ./tools/ejabberd2prosody.lua ~/Desktop/xmpp_migrate/xmpp_dump.txt Create a migrator configuration (or use the one I've pasted below). It basically takes everything from the file data format and puts it into the sqlite format, since that's how the Cloudron prosody is configured. Docs: https://prosody.im/doc/migrator https://prosody.im/doc/storage   Run the migrator script: ./tools/migration/prosody-migrator.lua --config=./migrator.cfg.lua prosody_files database Turn off your Cloudron XMPP app Copy the resulting prosody.sqlite file into your Cloudron XMPP's /app/data folder. It will be in the /data folder under your local prosody directory. Turn on your Cloudron XMPP app Your bookmarks, rosters, etc. will now be transferred to your new server! This doesn't appear to move archive messages (mod_mam). Probably because most prosody servers aren't configured to store these permanently so they don't bother migrating them. I only noticed one issue while migrating. When I first ran the migrator script it gave me errors about topics being empty on some MUCs. I thought I was being smart and edited the code to handle the blanks. This caused me to be unable to join the MUCs on Prosody on certain XMPP clients because Prosody expects there to be a Topic for every MUC. Once I manually adjusted the MUC topics to be non-empty, the other clients started working fine. Another almost-issue is that Gajim needed to be restarted a few times to start using OMEMO properly. I think the other MUC issues may have thrown it into an error state. prosody_files { hosts = { -- each VirtualHost to be migrated must be represented ["domain.com"] = { "accounts"; "account_details"; "account_flags"; "account_roles"; "accounts_cleanup"; "auth_tokens"; "invite_token"; "roster"; "vcard"; "vcard_muc"; "private"; "blocklist"; "privacy"; "archive"; "archive_cleanup"; "archive_prefs"; "muc_log"; "muc_log_cleanup"; "persistent"; "config"; "state"; "cloud_notify"; "cron"; "offline"; "pubsub_nodes"; "pubsub_data"; "pep"; "pep_data"; "skeletons"; "smacks_h"; "tombstones"; "upload_stats"; "uploads"; }; ["conference.domain.com"] = { "accounts"; "account_details"; "account_flags"; "account_roles"; "accounts_cleanup"; "auth_tokens"; "invite_token"; "roster"; "vcard"; "vcard_muc"; "private"; "blocklist"; "privacy"; "archive"; "archive_cleanup"; "archive_prefs"; "muc_log"; "muc_log_cleanup"; "persistent"; "config"; "state"; "cloud_notify"; "cron"; "offline"; "pubsub_nodes"; "pubsub_data"; "pep"; "pep_data"; "skeletons"; "smacks_h"; "tombstones"; "upload_stats"; "uploads"; }; }; type = "internal"; -- the default file based backend path = "/home/user/code/prosody-build/prosody-0.12.4/data/"; } database { -- The migration target does not need 'hosts' type = "sql"; driver = "SQLite3"; database = "prosody.sqlite"; }