A new not-what-I-was-looking-for-but-it-works-solution: I'm mirroring the Dockerfile/project from my local Gitea to Gitlab. I've set up Gitlab as my registry for the project. (The project in this case is a Grocy package for Cloudron.) This arguably gives me a private-enough repo for what I'm exploring, but I was hoping to be able to entirely leverage my Cloudron for this. I'm just plain confused why, at some point in the past, my locally-hosted registry worked, and now, it does not. This is why I believe there is "crufty" config laying around, somewhere, and things therefore don't work. (But... this makes almost no sense, because I have uninstalled and reinstalled the registry, so it is not clear how any state could persist.) Anyway. This remains a mystery, and I would need some explicit guidance as to where I should dig around in the backend of Cloudron to figure out why things are not behaving. (It could also be that there's still some port that I don't have open, or... )

Updated list: Jupyter Hub 256MB Guacamole 512MB Jitsi 1.46G Metabase 1.5GB Minecraft Forge Server 2GB Confluence 4GB

@scooke thanks! fixed.

@girish said in xip.io - Access any dev App via internal IP using a magic domain: @robi Do you know if Let's Encrypt certs work with those domains (since LE has limits). Or maybe they have some special agreement with Let's Encrypt to get over the rate limits? nip.io maps <anything>[.-]<IP Address>.nip.io in "dot", "dash" or "hexadecimal" notation to the corresponding <IP Address>: dot notation: magic.127.0.0.1.nip.io dash notation: magic-127-0-0-1.nip.io hexadecimal notation: magic-7f000001.nip.io The "dash" and "hexadecimal" notation is especially useful when using services like LetsEncrypt as it's just a regular sub-domain of nip.io

@atridad right. I guess we need some sort of 'development mode' flag for such apps which will ask the user to provide an image name optionally during restore.

@mehdi great, thank you, that did it !!

@nebulon thanks Happened again for me last night Will see how it goes today

@grienauer we started out initially with a rocket.chat instance which is still alive and used mostly for internal communication though. Once we had this forum, we essentially wanted the community to move here, since the chat turned out to not be very helpful with issue and solution search-ability. Of course also no public indexing of the channels.

@necrevistonnezr That seems more for the host than installed in apps? Or am I misreading some of it?

@fbartels thanks, nice example

@nebulon thank you, will move the repo over

@girish phew, thank you

Thanks @mehdi and @nebulon My problem solved by deleting the package-lock.json. After that I can update this app and all works good. Thank you very much.

@roru2k20 just git clone on a computer you have cloudron-cli installed then follow instructions in readme (skip docker build/push)

@msbt thank you I've decided to 'step over' adjusting them in the config file (because I can't) and adjusted the app code to read the config file e.g. process.env.CLOUDRON_MONGODB_HOST as it is nodejs app Not there yet but making progress

Right, just use the turn addon - https://docs.cloudron.io/packaging/addons/#turn

@alphagroup if it's an actual clone, you can just install the initial app, create a backup and clone the app to a new (sub)domain for each customer. If they don't have access, you might want to check out the Cloudron CLI or API and build some Dashboard around that

@klawitterb Oh I see, good point, that part escaped my notice. Mediafiles are directly served by nginx and only the rest is forwarded to Gunicorn. #serve media files location /media/ { alias /app/data/mediafiles/; } # pass requests for dynamic content to gunicorn location / { proxy_set_header Host $http_host; proxy_pass http://localhost:8080; # -> this gos to Gunicorn } So with the Cloudron Nginx, static files would still be served from Gunicorn. SO I guess, it is worth the effort Thanks for that.