What's coming in 9.1
-
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.@james said in What's coming in 9.1:
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
-
Congratz Team Cloudron
Is there an approximate timeline for 9.1?The Custom app build & deploy + Community packages are something that the majority of us have been looking forward to for a long time
-
Congratz Team Cloudron
Is there an approximate timeline for 9.1?The Custom app build & deploy + Community packages are something that the majority of us have been looking forward to for a long time
@creative567145 in the meantime, give ccai a try
-
@james said in What's coming in 9.1:
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
Hello @dualoswinwiz
@DualOSWinWiz said in What's coming in 9.1:
So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
This needs to be addressed by custom app packager.
-
N nebulon referenced this topic on
-
I'm curious how the implementation for the community packages will look like. Are you saying you will monitor a manifest file and inside of the manifest would be a container tag, and when the manifest or the tag changes the app will be updated with this?
The custom app build and deploy functionality sounds quite neat. Since you mention it will be cli driven I suppose it is the responsiblity for the person running the cli to make sure that the right branch/tag is checked out?
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.
-
G girish referenced this topic on
-
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 on
-
Any chance to have some VPN per App or S3-as-a-service in there as well?
-
-
Hello @nostrdev
We have tested the passkey support with the Bitwarden browser extension, YubiKey 5, Nitrokey and native support from some browsers and operating systems like Windows, Apple and Linux.
Please note, we implemented passkey support and not the full WebAuthn/FIDO2 specification available options. -
To support passkey login via the cloudron cli, we will move to oidc login for the cli in 9.1
Basically the cli will open a browser window to login and obtain an access token. For everyone using the cli in some automated pipeline, one can still use it with a pre-obtained api key from the dashboard.
-
We will be working on the following for 9.1:
- Custom app build and deploy - You can git-clone any package repository and run cloudron install directly. This builds the app locally on the Cloudron instance and installs it. This simplifies building and maintaining custom packages. The workflow is primarily CLI-driven and targets developers building custom apps as well as users who want to apply patches on top of existing packages.
- Community packages - can be installed from a URL via the dashboard. Cloudron will track the upstream URL and automatically check for and apply updates. Will allow people to publish outside Cloudron App store and users can easily install these packages and keep them automatically updated. For discovery, we will maintain a list either on the forum or in the documentation (TBD).
- Separate notifications view
- Mongodb 8, Redis 8.4, Nodejs 24.x
- Acme ARI support
- Backup Integrity verification UI
- Improved progress reporting - show percentage complete and elapsed/estimated time for backups and app installations.
- Convert backup site creation dialog to a view
- Better eventlog UI
said in What's coming in 9.1:
Improved progress reporting - show percentage complete and elapsed/estimated time for backups and app installations.
Convert backup site creation dialog to a viewSave these two, other features are implemented. Work has started on getting 9.1 release out.
-
Hello @nostrdev
We have tested the passkey support with the Bitwarden browser extension, YubiKey 5, Nitrokey and native support from some browsers and operating systems like Windows, Apple and Linux.
Please note, we implemented passkey support and not the full WebAuthn/FIDO2 specification available options.Using Bitwarden means keeping your secret on a potentially compromised device. Better to use a hardware key.
The problem with both Yubikey and Nitrokey is that if you lose the device, you lose the key. Big problem.
The fact you cannot recover a passkey, make those devices a pass, from us. Or at least, they must be used in a far more careful and limited fashion - ie, fallback to email recovery - than what would otherwise be the case (sovereign recovery).
With Trezor - and other hardware wallets that use deterministic webAuthN - you can recover from a seed. This means that the loss of a device is not catastrophic.
EDIT: Am reading the Trezor forums and apparently they do support Passkeys, it's just that the Resident Key is encrypted with the seed, and not deterministically generated. So for recovery, you just back up the file using regular cloud storage.
Looking forward to testing it on cloudron, and letting you all know the results.
-
J james referenced this topic on
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login