Kasra Bigdeli

@maietta - have you tried pulling in the edge version and try? Steps outlined here ( https://github.com/caprover/caprover/issues/1189#issuecomment-945042159 ) should, in theory, fix the issue. Have you already tried them?

CapRover currently uses v1.40 API to talk to Docker. `CapabilityAdd` is [added in 1.41](https://docs.docker.com/engine/api/version-history/#v141-api-changes). Until we make a breaking change and up the requirement to 1.41, users can manually add...

Thanks for bringing it up - the issue with recreating images on ARM is not something that I had considered. Regarding the one-off services, as far as I know there...

Yes, it's better for apps to have distinguished names. We should add app name specific suffix to the volumes to avoid this.

This is even trickier than that. Having the same volume is not always bad, sometimes it's intentional. One thing that would help is to edit the volume names to include...

It's not something that we have to do in the code. We just need to write a script that: - Iterates through all apps.yml files here: https://github.com/caprover/one-click-apps/tree/master/public/v4/apps - Reads the...

Yes, in can come in two steps: - First, ensuring that all existing apps have the proper suffix - Second, running the validation on the linter to ensure that we...

I certainly like this. Now that we have the application logs in the app panel, it makes sense to fetch the information regarding the state of the container from Docker...

So this is where things get a little muddy. CapRover "cleverly" decides whether to use `start-first` or `stop-first` when updating a service. If there is a mounted volume, in order...

The main difference is that apps with persistent volumes are tied down to a particular node (in swarm mode) since the data lives on a particular node.