I built a thing using Cloudron - testers wanted

[luckow]

@3246 The underlying problem is a lack of quotas for apps on Cloudron. Since this cannot be solved at the platform level, the only option is to set a volume per app. For example, you could define a volume of 10 GB for Jellyfin (or Nextcloud or Sogo ...), move the app into this volume, and give the customer the option to purchase more GB for more money.
Problem solved.

[3246]

@luckow thanks, that sounds like a good idea. I'll investigate that.

[humptydumpty]

Now the pricing is different. Initially, it was 5.99 for all but a few (Mattermost was one).

[3246]

@humptydumpty that looks right to me. I am looking at the caching which might be the root cause.

[crazybrad]

@3246 One idea is to separate the apps into high, medium, low resources (especially considering @luckow cooking channel). Launch your service with attractive prices using just the "low" apps, where you won't get burned and need to jack up the prices, something your target audience will likely hate.

Another thought is I personally find the list of Cloudron apps mind-boggling at times. I would also consider offering packages which might include bundles of apps that match business needs (e.g. CRM + Email + Bitwarden). You increase the transaction size, reduce the decision fatigue, and if you price it as Buy 3, Get 1 Free, the economies will surely drive some business. Solopreneur, freelancer, etc. Think about what they need and bundle a solution!

[3246]

Thanks @crazybrad. Originally I was thinking just to offer a small range of apps and offer bundle deals. It evolved into the current model with pricing tiers and a comprehensive assortment. However, I am working on a type of bundle like Nextcloud and Collabora. It's not yet working the way I want it to though.

@nebulon et al, I am thinking of using /api/v1/apps/:id/configure/storage to move app data to an XFS volume to solve the 'unlimited storage quota' problem. I will use quotas with XFS.

The approach:

1. The setAppStorage() API call moves the app's data directory from the default /home/yellowtent/appsdata/<appid> to /mnt/volumes/appdata/svc_<id>/ on the XFS volume
2. SSH-based quota management via sshExec()
3. The XFS project quota is transparent to Cloudron — it just enforces a size limit on that subdirectory
4. Backups/restores work as usual

Bearing in mind the orchestrator is separate from the Cloudrons (multiples). Does that approach make sense? Am I missing something vital?

[timconsidine]

@3246 nice simple approach, good for end-users.

Limited online so have not checked - have you excluded apps which have licence restrictions, no managed service. Forget which, but there are a few.

[joseph]

@3246 have you see this already - https://docs.cloudron.io/guides/per-app-storage-limit ?

[necrevistonnezr]

@timconsidine said in I built a thing using Cloudron - testers wanted:

@3246 nice simple approach, good for end-users.

Limited online so have not checked - have you excluded apps which have licence restrictions, no managed service. Forget which, but there are a few.

Anything with a BUSL (Business Source License) or similar (NocoDB, Hashicorp products, etc.)

[3246]

@joseph thanks. Is it in the API yet?

[james]

Hello @3246
This can not be in the API since this is a file system setup.