Cloudron Forum

@ccfu "fighting" the platform is good idea

@nebulon
Thanks for the clarification. I understand Cloudron’s design philosophy regarding keeping the database tightly coupled with the application for consistent backups and restores.

However, in our case, the main objective of using Alibaba Cloud RDS is that the database layer is fully managed independently, including backups, HA, DR, PITR, monitoring, and recovery procedures.

From an infrastructure and security perspective, we also need a separate recovery path in case the Cloudron server itself becomes corrupted during an upgrade, suffers complete filesystem failure, or even gets impacted by ransomware attacks such as Shamoon-style destructive malware encrypting the entire server storage.

In these scenarios, having the database isolated and continuously protected on a managed RDS platform gives us a strong fallback and significantly improves resilience and disaster recovery capabilities.

Our goal here is mainly to follow infrastructure best practices by separating the application tier from the database tier, both operationally and from a security/recovery standpoint, rather than relying on a single tightly coupled host for everything.

Mr. @james,

I have the same setup and faced a similar issue. Currently, I'm using Alibaba Cloud RDS, which provides multiple enterprise-grade features such as High Availability (HA), Disaster Recovery (DR), and Point-in-Time Recovery (PITR).

I'm planning to adopt a two-tier architecture by separating the application tier (Cloudron) from the database tier. The goal is to better separate responsibilities and specializations across the team, while also improving scalability, maintainability, and operational management.

Is there any recommended approach to achieve this without forking the package?

Hello everyone,

I’m running GitLab 17.4.2 on Cloudron, and I can see that the latest available version in the App Store is 18.8.

Before proceeding with the update, I’d like to clarify how Cloudron handles major GitLab upgrades:
• When updating GitLab via Cloudron, does it upgrade directly to the latest version (e.g. 17.4.2 → 18.8)?
• Or does Cloudron internally handle sequential version upgrades to satisfy GitLab’s upgrade path requirements?

I’m aware that on self-managed GitLab installations, skipping certain major versions is not recommended, so I want to make sure Cloudron’s packaging and migration process safely handles this.

Any clarification from the Cloudron team or users who’ve upgraded GitLab across major versions would be appreciated.

Thanks in advance!