Issue with Remote DB Connection in Matomo on Cloudron
-
Hi, we’re trying to connect Matomo to a remote database by modifying the config.ini.php file, but after restarting the server, Cloudron’s script overwrites our changes. Has anyone found a way to prevent this from happening?
Thanks!
-
Hi, we’re trying to connect Matomo to a remote database by modifying the config.ini.php file, but after restarting the server, Cloudron’s script overwrites our changes. Has anyone found a way to prevent this from happening?
Thanks!
@preet-cappital on Cloudron, deployed apps always use the internal database. You cannot configure apps to use an external database.
Is there a reason to use an external database? You can always give your internal database more resource in Services view.
Cloudron features like backup, restore, clone, import etc all rely on the internal database being used (this is how things are automated).
-
We are running multiple apps in a single Cloudron instance. In Matomo, we are tracking our project, which has millions of daily active users and numerous custom dimensions. We need to generate detailed reports to analyze trends, which results in a significant amount of data.
Our main concern is monitoring and scaling the server's storage when needed. With the internal database, we would have to manually clean up storage or scale the instance, whereas a remote database with auto-scaling would handle this seamlessly. This is why we were exploring connecting Matomo to an external database.
Also during the scaling process, our other apps will be affected.Is there a workaround to prevent Cloudron from overwriting the config changes, or is there an alternative approach to achieve this?
Thanks!
-
Cloudron package always ensure the platform related configs on app restart. This is required to know a consistent state for updates. In your case if you need to tweak those, then you may have to fork the package repo and customize the app for such needs. Overall Cloudron is not built for horizontal scaling and maybe for millions of daily users, it is likely not the best option. We try to strike some balance here, but solving too much in one would make life hard for other use-cases.