I built a thing using Cloudron - testers wanted
-
@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. -
Now the pricing is different. Initially, it was 5.99 for all but a few (Mattermost was one).
-
Now the pricing is different. Initially, it was 5.99 for all but a few (Mattermost was one).
@humptydumpty that looks right to me. I am looking at the caching which might be the root cause.
-
@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!
-
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:
- 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
- SSH-based quota management via sshExec()
- The XFS project quota is transparent to Cloudron — it just enforces a size limit on that subdirectory
- 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?
-
Hiho folks.
Cloudron is awesome and I finally got around to building something that completely hides it from the users' eyes
To make it super easy, barely an inconvenience for the non-technical user, I created (drum roll
please):https://instantappshosting.com
Which is now in public beta and you can have a free app or two in return for telling me what's not right (kinda a not-buy-two get a third free deal).
Please DM me for the special Cloudron supporters coupon which gives you 100% off the sticker price.
Hope you like it and thanks to the Cloudron crew and this amazing community. I look forward to extending my business license soon as I grow my Cloudrons.
Over to you.
@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.
-
@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.
@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 have you see this already - https://docs.cloudron.io/guides/per-app-storage-limit ?
