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.

@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.

@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]

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

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 .

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!").

@tronical personally I do this process : fork the repo make changes docker build etc. docker push etc cloudron install etc. Maybe I should learn cloudron build but I am an old dog with limited brain space My build script (usually in folder above the app dev folder) : #!/bin/bash if [ "$#" -lt 1 ]; then echo "Usage: $0 <image-name> [cache|nocache] <appname.yourdomain.tld>" exit 1 fi # Get the directory from which the script was called BUILD_DIR="$(pwd)" if [ "$2" = "cache" ]; then echo "Building with cache ..." docker build --platform linux/amd64 -t $1 "$BUILD_DIR" else echo "Building with no cache ..." docker build --no-cache --platform linux/amd64 -t $1 "$BUILD_DIR" fi docker push $1 cloudron install --image $1 --location $3 e.g. ../cld.sh dockerregistry.yourdomain.tld/appname:version cache appname.yourdomain.tld

Many thanks, @james. The text was absolutely helpful. Also, that diff hint is gold. I may end up with a PR against the docs when I'm done, because that kind of hint is a nice trick to figure out quickly all the places an app touches the disk.

Currently this is not possible, we only manually add translators to avoid spam. Due to the vast changes of translation strings for the new UI, we are yet to purge and merge strings. So may not be too useful at the moment to suggest changes, but I am very happy to create an account for you for the future. Please mail your preferred email address to support@cloudron.io for this and we can handle it there.

@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!