License issue

[girish]

@arta said in License issue:

Does this mean after we reach 300 we need to get in touch again?

yes. currently, the installed apps are being tracked in the appstore database which has these field size limitations and fk constraints.

I still don't see the reasoning behind this limitation while the license agreement clearly states unlimited apps.

This is in the territory of 'unlimited' always has limits

But I agree it's all inconvenient and we don't like the extra work either. In Cloudron 9, we removed all this app "registration" stuff entirely. It used to be like https://git.cloudron.io/platform/box/-/blob/8.3/src/apps.js?ref_type=heads#L2462, but it's all gone. So, you won't this any more soonish since app installation does not contact app store any more other than downloading the manifest.

[arta]

Thank you for clarification.

[arta]

Hi Girish, we hit 300 apps now and we are getting this error:

Error creating Cloudron app: Too many installed apps. Please contact sales@cloudron.io

[girish]

@arta doubled to 600 . can you please try again?

[arta]

Yes sir, though I can't confirm if the limit is 600 now, but it passed 300. Thank you

[luckow]

@arta I'm really curious.
What kind of machine and use case do you have to run 300+ apps on one instance?

[andreasdueren]

@luckow Maybe some sort of shared hosting? Should be able to support lots of wordpress instances, LAMP stacks and Surfer apps.

[arta]

@luckow I run cloudron on a dedicated server with this spec:

We run lots of n8n instances. Also gitlab instances. We run a APP and Web development Company.
Cloudron is our life saver as it makes keeping our projects easy. Specially deploying and backups. Its fast and a click away. FYI, we are almost close to 600.

Thank you for your attention.

[luckow]

@arta A quick follow-up question: How does it feel to restart or update the instance? Hopefully, everything will run as usual again after the task is complete. But the moment the screen goes black, all of the customers' applications are gone. Restoring a backup on another instance takes time. Really? Not for me Instead of using one large machine, I distribute apps and customers across different Cloudron instances. If one goes down, the others continue to run, and not all my customers call me at the same time.

[arta]

You are not wrong in principle, distributing workloads reduces blast radius, and that approach makes perfect sense in many scenarios.

Our setup, however, is slightly different. We operate our own colocation facility (4K rack capacity) with direct, hands-on access to the hardware. For this particular server, there is a live mirror in place with continuous rsync-based synchronization, so the data is always effectively warm. Internally, the servers are connected over a dedicated 10 Gbps private network. In practical terms, this means restoring or promoting a mirror is not a lengthy operation.

It is also worth noting that these instances are not customer facing. They support our internal workflows, not production services for external clients, so the operational impact of a short outage is limited by design. Even in the worst case, an instance going down does not trigger customer downtime or a flood of support calls.

The main reason we run Cloudron on a single server is automation. We rely heavily on the Cloudron API for provisioning, backups, restores, and lifecycle management, and keeping everything under one Cloudron instance allows these processes to remain fully automated and consistent. But sure, it has some costs.

Running multiple Cloudron instances on separate servers would significantly increase operational complexity and require manual coordination, which defeats the purpose of our setup. Given our mirrored data, high-speed internal networking, and automated recovery, a single Cloudron control panel is a deliberate and acceptable trade-off for our use case.