Cloudron Forum

Finally got around to adding the docs for this route: https://docs.cloudron.io/api.html#tag/Apps/operation/installApp

8.1 is in unstable now, these issues are fixed there.

@philkunz said in No support for simply uploading a backup through the web ui?:

Ok got it. Is there a particular reason, why a simple upload through the webui is not supported?

In some ways, this can be considered a security issue. If we had some bug in Cloudron code, then one can import/delete your existing data in the app. This is also why we don't allow deleting backups via the web ui.

But (atleast I) have come around to this a bit. Maybe this can be considered a usability issue. We just need to figure out some safety hatch when user uploading a backup (maybe require 2fa, reenter password etc).

@philkunz 😊

With the latest update which brings up the memory limit to min 2GB, things look better in my instance.

@philkunz true... too late to change the name now 🙂

... In a way. We are developing our own solution now, that uses Synology as a base for on premise installations.

my bad. I just woke up this morning retested, and everything seems fine. I don't know what was happening yesterday. Maybe also some network congestion in the datacenter.
Sorry for bothering you.

@fbartels said in Backups and users:

Cloudron treats user names as unique

Yes, we used to uuid and then went and changed all the apps to use username so that migration from one Cloudron to another (or anywhere else) is easier. As long as the username exists on the other cloudron, user should be able to login.

@philkunz We use the term snapshot and backup interchangeably in the docs. They are one and the same. I guess snapshot is something you initiate as a user whereas backup is something the system (automatically) initiates.

Ultimately, they are both capturing the state of the app and uploading to configured backup location.

To answer the questions:

yes, backup policy applies to snapshots correct, snapshots (which you click manually) is just in addition to backups (which are taken automatically). there is nothing special about snapshots, we don't differentiate them from the automatic backups. We take snapshots/backups at the per app level. This way you can roll back a single app independent of others. To see the backups/snapshots of an app, you go to Backup section of the app. There is also a system backup (in the Backups view). A system backup is the one which you configure the schedule policy for (we don't have per app backup schedule). The system backup is essentially taking the backup of each app + backup of mail server + backup of the platform (like user information, domains etc) . It "groups" all these separate backups together and this is what is shown in the Backups view. In that sense, the Backups view is showing the "full backups". With the full backups, you can restore/migrate Cloudron to another server (so, it will be exactly the same as the current server with all the apps/domains/data/users).

The dockerfile is here . It's nothing special, just lots of packages on base ubuntu.

To add to what's been said: our approach is the batteries included approach and it's optimized for developer/sysadmin productivity (as opposed to saving disk space). When we open a web terminal, we want all the common tools across all apps (ping, nc, telnet, tar, node, php, python what have you). The Web terminal and File manager have a bunch of tooling prerequisites - tar, zip, rar, jq, database clients (mysql/postgres/redis/mongo), etc for it work well.

Any image will work including multi-stage builds. You have to pay attention to our deployment paradim though - https://docs.cloudron.io/packaging/cheat-sheet/#filesystem . Containers are run on a readonly fs, there is no way around this.

Thank you 🙂

@philkunz might be worth reporting upstream at https://github.com/Joxit/docker-registry-ui/issues/

Documented this at https://docs.cloudron.io/apps/umami/#custom-endpoint