What's coming in 9.1
-
For the custom app build and deploy -
cloudron installuploads the package's source and there is a docker build running on the server. The source is part of the app backup. This means that when you restore back , it can rebuild from the source pacakge at that point in time and deploy it again. The design requires Dockerfiles to work reliably since the images are not "backed up" .Wanted to check if anyone had a concern that builds can be done on the server? For example, in theory, a build of some mega package can affect the existing apps. Should this feature be opt-in? Of course, every switch and configuration setting adds complexity.
Community packages - the plan here is to have a file called
CloudronVersions.json(or maybeCloudronVersions.json.gz). This is an array of "version" -> "manifest with dockerImage" mapping. This is how it is stored in the database in cloudron.io also. There will be a CLI commandcloudron versions add,cloudron versions publishetc to update that file (there is already acloudron appstoresubcommand, so this new one will loosely mirror that). This system allows: Listing versions of package, going back to old version, checking for new versions etc. Manifest is also saved per version allowing you to have icon/changelog/description/screenshots etc which is version specific. This single file has to be publicly hosted somewhere and doesn't need to be part of the package repo (though I imagine it would be).UI wise, there will be a button to "Install package" and you give a CloudronVersions.json URL and that's it.
Community "app store" - this is a listing of community packages. currently, not planned for. I think we need the above two stable to see if we need this. For a start, we can maintain a page somewhere which has all the community apps. Either here in the forum or the cloudron.io website or somewhere else . Ideally, this has to be self-editing/self-managed and shouldn't require cloudron.io team to add/edit stuff. Open to ideas.
-
For the custom app build and deploy -
cloudron installuploads the package's source and there is a docker build running on the server. The source is part of the app backup. This means that when you restore back , it can rebuild from the source pacakge at that point in time and deploy it again. The design requires Dockerfiles to work reliably since the images are not "backed up" .Wanted to check if anyone had a concern that builds can be done on the server? For example, in theory, a build of some mega package can affect the existing apps. Should this feature be opt-in? Of course, every switch and configuration setting adds complexity.
Community packages - the plan here is to have a file called
CloudronVersions.json(or maybeCloudronVersions.json.gz). This is an array of "version" -> "manifest with dockerImage" mapping. This is how it is stored in the database in cloudron.io also. There will be a CLI commandcloudron versions add,cloudron versions publishetc to update that file (there is already acloudron appstoresubcommand, so this new one will loosely mirror that). This system allows: Listing versions of package, going back to old version, checking for new versions etc. Manifest is also saved per version allowing you to have icon/changelog/description/screenshots etc which is version specific. This single file has to be publicly hosted somewhere and doesn't need to be part of the package repo (though I imagine it would be).UI wise, there will be a button to "Install package" and you give a CloudronVersions.json URL and that's it.
Community "app store" - this is a listing of community packages. currently, not planned for. I think we need the above two stable to see if we need this. For a start, we can maintain a page somewhere which has all the community apps. Either here in the forum or the cloudron.io website or somewhere else . Ideally, this has to be self-editing/self-managed and shouldn't require cloudron.io team to add/edit stuff. Open to ideas.
@girish said in What's coming in 9.1:
The design requires Dockerfiles to work reliably since the images are not "backed up" .
I think for reliability it would probably be easier to backup the docker images instead of counting on well written Dockerfiles. But on the other hand even for these apps I would think the Cloudron base image will be used most commonly, so the chaos might be minimal.
Personally I would then rather use the community packages where I can have a pre built docker image that i can (more) easily deploy to Cloudron.
-
@girish said in What's coming in 9.1:
The design requires Dockerfiles to work reliably since the images are not "backed up" .
I think for reliability it would probably be easier to backup the docker images instead of counting on well written Dockerfiles. But on the other hand even for these apps I would think the Cloudron base image will be used most commonly, so the chaos might be minimal.
Personally I would then rather use the community packages where I can have a pre built docker image that i can (more) easily deploy to Cloudron.
@fbartels I should clarify further. The two features are for different use cases.
The custom app deployment was primarily to help people writing and deploy their own custom apps. There are many who are forking packages and adding some minor patches (because we don't allow customizations with readonly fs). This new mechanism will help people build+deploy easily. This does not require CloudronVersions.json. Only implemented in CLI. I think the CLI workflow gives the right messaging that they have to keep it updated themselves.
The community package always has a docker image associated and requires CloudronVersions.json. It was for people who want to share their packages with others and provide updates.
There is no plan to give a source URL in the UI and "build" from source. While technically possible, don't want people to expect "builds", "deployments" etc like a code deploy/PaaS. It's something for the future, if a use case exists.
Hope that clarifies!
-
Request: Passkeys support for the Cloudron login
-
G girish referenced this topic
-
Any chance to have some VPN per App or S3-as-a-service in there as well?
-
