@ei8fdb ha.. i missed that thanks—will wait then

@saikarthik yup, can surely be added. probably next release.

@girish Danke, that works

@thetomester13 I'm glad it was helpful! It was a fairly opinionated guide in that I specifically chose Gridsome for the SSG and GitLab/Gitlab CI for the git and CI platforms. But these steps can be adapted to other platforms.

And yes I find the colour cycling philips hue lights incredibly relaxing while I work

@mehdi Yes I saw that part, that's where I got the 1048576000 from and it got me digging into it further. I guess then the display is using binary in Cloudron UI so the value it's set to isn't quite 1 GB in binary so it shows 1000 MB. Interesting. That seems wrong to me though, I assume the value in that manifest should actually be 1073741824 to match others that are 1 GB. Right?

Example: 1073741824 is what's set for Bitwarden: https://git.cloudron.io/cloudron/bitwardenrs-app/-/blob/master/CloudronManifest.json#L17

Am I right in assuming then from this that the Cloudron UI basically shows in Decimal, and not Binary? But ideally the Manifest should be in Binary still so the UI shows the more expected typical numbers and increase segments, right?

@girish it would be great to add this to the docs for making custom apps, to use one of those links as a good base for the Dockerfile and manifest which will speed up packaging development.

Now increased to 100

@yusf said in Why do we have to push an image to a registry?:

Does this mean that we can also host the Cloudron build service on production machines, or am I mistaken?

Well, I run it only on a dev machine since I only use Cloudron to dev. But tbh, after 100s of builds. All of the other apps are still running smoothly so it's not recommended because it's the only app with the docker add-on and thus could technically mess with other apps. It has never done so, I just think they'd rather not have the responsibility of calling it "production-ready" even though in my dev environment, it gives me no issues. I would feel comfortable running this in production tbh. The worry is if it ever bugged. But I can actually work around that by accounting for it using a Cloudron add-on I'm building (Dot the Repair Bot) so even though it's never happened, if I account for the Build Service being able to destroy containers / data outside it's sandbox (what the devs mean when they say it's not for production), I can have them auto-restored by Dot.

But if Dot got destroyed by the Build Service I'd be screwed.

@girish Sorry for the late reply, I tried this and got it working!
Thanks,
Ross

@marcusquinn Oh yes think it would be help

@mehdi said in Updating a node app:

@atrilahiji Also, some browsers are a bit ... aggressive with their caching policies. You may want to force-refresh (ctrl/cmd + shift + R in most browsers), maybe even a few times, before anything else, just to check it wasn't just cache

This has been my experience as well.

@fbartels Ohhhhhh. I understand now. Thanks for the explanation. What a cool concept.

I took a quick look at that some time ago, but it wasn't that trivial for me at least unless I would rewrite parts of the element table management around sorting. Happy to accept any patches there of course.

@murgero HAH! Oddly enough making my script specifically cd into the backend directory and running the server.js there instead of running server.js from outside that directory did it. Unsure why. Works now and I have 0.1.1 of my app released and 0.1.0 of the cloudron integration. Thanks guys!