@grienauer When I did my testing for the Valheim Server App I wrote this script to make testing easier. Note tho, this only works when not using any addons, but localstorage works with the local mount. #!/bin/bash # Function to get the user to input the needed vars get_vars () { read -p "Cloudron E-Mail: " EMAIL read -p "Cloudron Username: " USERNAME read -s -p "Cloudron Password: " PASSWORD read -p "Cloudron URL: " CLOUDRON_URL read -p "DOCKER REPOSITORY URL: " DOCKER_REPOSITORY_URL read -p "DOCKER USERNAME: " DOCKER_REPOSITORY_USERNAME read -p -s "DOCKER PASSWORD: " DOCKER_REPOSITORY_PASSWORD printf "EMAIL=$EMAIL\n USERNAME=$USERNAME\n PASSWORD=$PASSWORD\n CLOUDRON_URL=$CLOUDRON_URL\n DOCKER_REPOSITORY_URL=$DOCKER_REPOSITORY_URL\n DOCKER_REPOSITORY_USERNAME=$DOCKER_REPOSITORY_USERNAME\n DOCKER_REPOSITORY_PASSWORD=$DOCKER_REPOSITORY_PASSWORD\n " > .env } # check if .env file exists and read it or check if vars exsist if [ -f ".env" ]; then export $(egrep -v '^#' .env | xargs) &> /dev/null else echo ".env File missing - asking for required vars" get_vars fi if [ -z "$EMAIL" ] || [ -z "$USERNAME" ] || [ -z "$PASSWORD" ] || [ -z "$CLOUDRON_URL" ] || [ -z "$DOCKER_REPOSITORY_URL" ] || [ -z "$DOCKER_REPOSITORY_USERNAME" ] || [ -z "$DOCKER_REPOSITORY_PASSWORD" ]; then echo "some vars are empty - asking for required vars" get_vars fi echo "=> Login Docker" docker login --username $DOCKER_REPOSITORY_USERNAME --password $DOCKER_REPOSITORY_PASSWORD $DOCKER_REPOSITORY_URL echo "=> Login Cloudron" cloudron login --username $USERNAME --password $PASSWORD my.$CLOUDRON_URL set -x # Get the ID and VERSION from the CloudronManifest.json ID=$(jq -r ".id" CloudronManifest.json) VERSION=$(jq -r ".version" CloudronManifest.json) echo "=> Create Test Data dir" mkdir -p ./cloudron_test/data ./cloudron_test/tmp ./cloudron_test/run echo "=> Cleanup Test Data" rm -rf ./cloudron_test/data/* ./cloudron_test/tmp/* ./cloudron_test/run/* echo "=> Build test image" cloudron build --set-repository $DOCKER_REPOSITORY_URL/$ID # docker build -t $DOCKER_REPOSITORY_URL/$ID:$VERSION . if [[ RUN_IMG = "" ]]; then read -p "Do you want to run the image created image?: (y/N)" RUN_IMG fi if [[ "$RUN_IMG" = "y" || "$RUN_IMG" = "Y" ]]; then echo "=> Run `test` tag of build image" docker run -ti --read-only \ --volume $(pwd)/cloudron_test/data:/app/data:rw \ --volume $(pwd)/cloudron_test/tmp:/tmp:rw \ --volume $(pwd)/cloudron_test/run:/run:rw \ $DOCKER_REPOSITORY_URL/$ID:$VERSION \ bash fi echo "=> Running tests" cd test echo "=> Running ncu - updating deps" ncu -u npm -i echo "=> Installing package.json" npm install if [[ -f ./node_modules/.bin/mocha ]]; then ./node_modules/.bin/mocha ./test.js -b fi if [[ -f ../node_modules/.bin/mocha ]]; then ../node_modules/.bin/mocha ./test.js -b fi # remove installed test instance echo "Cancel now if you wish to keep the app installed" sleep 10 cloudron uninstall --app test.$CLOUDRON_URL

@girish hah, I didn’t realize there was an update! Thanks!!! I’m glad I wasn’t crazy there and it was a platform issue. I redid my package like 4 times thinking I was overriding the environment vars somehow

@jodumont If you run the node file for cloudron directly (add it to your PATH) you don't need the set-executionpolicy bit. Node is separate from powershell and as such it can run without that.

@nebulon Thanks thought that might be the answer.

Thanks, that's perfect.

@jimcavoli I think that makes sense. Let me see if I can get the recvmail addon working again, should be straightforward. For your suggestion of having a "selector" in the email UI, we did exactly that for sendmail addon in the previous release. So, we can do the same for recvmail as well I guess. Let me investigate.

@girish Now It's working, thanks for your help

@moocloud_matt As soon as someone comes in reporting a real case that their NIC is saturated and it's slowing down their server I'd be interested in pursuing a solution. I've never seen such a real case on these forums (though I may just be misinformed) so I'd have to tilt towards YAGNI until one appears. Object storage is not magic, it's just data like everything else. If it's just used to serve file attachments for an app with 25 users I wouldn't expect it to be a bottleneck.

@roru2k20 I have a package already that has code-server, would you like to get access to the repo?

@atridad it's not so easy, you need to compile all the C extensions modules that you are using. For example, are not compatible libraries because there's no way to easily compile them are tensorflow, pytorch. But in generaly Yes is compatible with all the python code because it's a fork of its default interpreter/compiler CPython.

@girish said in Custom app container startup arguments: these variables can then be configured by UI ? Also, I guess you are expecting these variables to become exposed as environment variables to the app? I like the way this is implemented in the univention app center. The format of the settings (there they use the ini format) is explained in https://docs.software-univention.de/app-provider-5.0.html#app-settings:reference. It defines different types of settings and allows to template default values (even custom drop downs). The values are then stored in a file in the container and scripts can be triggered inside and outside of the container to react on changes. Outside is probably not necessary here.

@marcusquinn Thanks a lot for the comments, really useful! I have actually received several similar suggestions regarding the userTrack name. I thought about it for a long time, but for now I have no plans of changing it. A big reason is that when people are Googling for "user tracking" they will stumble upon userTrack, which is one of the most privacy-friendly solutions for "tracking" users (self-hosted, cookieless, hashed IPs, multiple privacy settings, etc.). This is in some way similar to getting "earthIsFlat dot com" and posting on it content that proves the earth is not flat. Another reason why I am still using the name is because it's self-hosted, so the web administrator can actually name the user-facing scripts whatever he wants. I agree that a more user-friendly name could help, but currently the existing brand power and SEO benefits make this change unlikely to happen. I highly recommend looking at the EspoCRM, Wordpress, Matomo open-source, premium add-ons business-models I have considered and tried many pricing models over the years. Working on userTrack for over 9 years I have also always watched other similar platforms and their business model and always debated whether going open-source would help or kill the project. For example, Matomo is really awesome and it's open-source, but their focus is NOT on the open-source part. Being a business, their focus is to attract users to their premium offering so their open-source version drops in quality/features (some core features are only available for the cloud plans for a very high cost). Open-source is not free of cost for users, they pay you with their time, testing and feedback This is true, but keep in mind that paying users also pay with their time, testing and feedback too. Don't cut off that source of improvement, just get better at managing a public Git*** repo and issues, embrace the community spirit, and I'm sure you will have great success - including here Doing open-source well is REALLY hard. Take Matomo for example, which is a huge organization, yet their repo has thousands of open issues and tens of unmerged Pull Requests. Although this seems like good activity, in the end I feel like it also means many human-hours of effort have been wasted trying to create, analyze, accept/reject all those suggestions. All this while the user-facing progress is overall slow and the platform starts to feel outdated. I also recommend watching this great talk about the not-so-good parts of open-source. I am not saying in any way that userTrack will never ever be open-sourced, but for my current goals with the project this is currently a no-go (working on userTrack as a shared/paid-source project for over 9 years has worked really well and most of the customers are extremely happy with the product). I want to mention that it's not about the money, it's mostly that switching userTrack to open-source would move my focus away from my envisioned end-goal for the product and self-hosting ecosystem. I wouldn't consider anything with compiled or obfuscated code in though - and would spend 5 times the amount to have it decompiled and published userTrack's source-code was actually entirely unobfuscated and visible up until v3 when I rewrote the entire application in TypeScript and React. Because those technologies require a building process, which means dev tools and maintaining a dev documentation, I realized that I wouldn't be able to provide a proper developer experience while focusing on improving the product. My goal now is to create an awesome product that just works, without having to fiddle with code (so the target audience also includes non-programmers). That being said, the server side (PHP, MySQL) and tracking (JS tracker) source code of userTrack is completely visible and unobfuscated. The only obfuscated part is the JS of the interface (dashboard UI) only because changing it would require me to provide numerous extra development tools and write extensive documentation. My plan is to soon add a way to extend userTrack (eg. via plugins), so you can still customize the dashboard if you want but without having to learn and setup a complex dev environment. Thanks again a lot for sharing your opinions, it's really useful to know how different communities have different opinions on how a product should be in order to be useful for them.

@girish yes

As we get Sysbox into Cloudron as a default runc, that will enable many more of these use cases.

we usually find that these extensions are usually very specific and sometimes it is way more work to write a general system than just hard coding it One of the things I recognized right away about the way you guys develop Cloudron is a laser focus on implementing practical, minimal, incremental solutions instead of chasing maximum general power right out of the gate. It leads to a more stable system that I don't have to constantly fuss over -- thank you for that! I agree that this is probably the right approach for matrix plugins as well, at least for now. I think the way issue 569 was resolved is a good example of this. I think it makes more sense to continue the matrix discussion on that thread, which I just replied to. Thanks for taking the time to read and respond.