Cloudron Forum

@girish Thanks ^^ I've seen a similar post where the solution didn't helped on this and I though it was a good place to ask this. In the mean time I also issued this on github, about another database but with the same error and got a response that it's not a bug and indeed these type of databases, even if they use postgres are not supported. Guess I'll keep looking for alternatives that would fit my use case. Thanks for answering

@jdaviescoates said in Installed at map.bridport.coop then deleted, then reinstalled on same location: server not found: Is there a way to flush the NXDOMAIN cache on routers/ computers? Not that I am aware of. These days browsers also do their own DNS caching complicating things even more.

@LoudLemur Great, as you know many Apps here have other service ports opened, they just need to be packaged as such and include a webUI for config & health checks, etc.

@matthewdykstra Whoa! That’s crazy affordable. Ok, good to know. Thank you.

@qwinter I used to segregate apps on different VPS. Largely through fear of apps conflicting with each other (different modules/scripts) and my personal ignorance of how containers worked. It all cost me a fortune !! Multiple small bottom tier VPS, each of which did not consume their resources to an adequate level. I've since gone with steadily bigger beefier machines, and certainly get better price/performance, adding on extra apps to research ("play") and they don't tax the power of a well-spec'ed host. I do have separate VPS, one for Cloudron, one for non-Cloudron Docker deployments, etc. So I do segregate apps to different hosts but hopefully with more logic than I did before. So I would go with the best host which makes sense to you, rather than multiple smaller ones, except where there is a clear technical reason (e.g. I don't risk my main Cloudron host with non-Cloudron docker apps).

Here is an ai generated list of potential solutions to some possible hurdles packaging molly brown: Here's the tidied section presented as a markdown code block: Potential Problems and Solutions Golang Version Compatibility Problem: Molly Brown requires specific Golang version compatibility. Solution: Specify the exact Golang version in the Dockerfile and ensure it's compatible with both Molly Brown and Cloudron. Configuration Management Problem: Managing configurations for different Cloudron environments. Solution: Use environment variables in CloudronManifest.json and modify the start script to generate a config file based on these variables. Persistent Storage Problem: Ensuring persistent storage for Gemini content. Solution: Define a volume in CloudronManifest.json for storing Gemini content, ensuring it persists across app updates and restarts. SSL/TLS Certificate Management Problem: Managing SSL/TLS certificates for the Gemini protocol. Solution: Utilize Cloudron's built-in SSL management if possible, or implement a custom solution in the start script to generate and renew certificates. Preserving Custom Configurations Problem: Updating Molly Brown without losing custom configurations. Solution: Store custom configurations in a separate volume and implement a migration script that runs during updates. Resource Allocation Problem: Efficient resource allocation in shared Cloudron environments. Solution: Carefully define resource limits in CloudronManifest.json and optimize Molly Brown's configuration for efficiency. Logging and Monitoring Problem: Integrating logging and monitoring with Cloudron. Solution: Configure Molly Brown to output logs in a format compatible with Cloudron's logging system, possibly using a log forwarding solution. Backup and Restore Problem: Ensuring comprehensive backup and restore functionality. Solution: Clearly define all data that needs to be backed up in CloudronManifest.json and thoroughly test the backup/restore process.

As of now, Im not having this issue anymore. I really dont know what would have caused this. Im thinking of setting up an opnsense firewall, not sure if it would help though

Thanks a lot guys, really appreciated for the input. Actually I am using vultr.com now, just made the upgrade of my server with it.

Debugged this with @ZeZaung a bit. Somehow, it was possible to re-run cloudron-setup on the existing install and this reset the database even though the app containers and data were still there. I have made a fix which should hopefully mitigate the problem.

@girish That's awesome, thanks Girish! Glad I wasn't crazy hahaha

As I said on the other thread I seem to have managed to install cloudron on Ubuntu 20.04 LTS by following your advice to use ./cloudron-setup --version 5.6.3. I've disabled automatic upgrades and I'll wait a bit to upgrade to version 6. All is good!

Will lock this thread in favor of the same question about a week ago https://forum.cloudron.io/topic/2677/ability-to-schedule-restart-reboots-updates?_=1592566614617

Just my 2 cents here : like girish said, if you want to run other things besides cloudron, you should install cloudron in a VM. If you really want to dedicate the whole machine to cloudron, there is really no need to bother with the additional layer of complexity, another OS to keep up to date and such. I would go bare-metal in this case. That's how I've been running cloudron for 2 years, and it's great.

https://forum.cloudron.io/topic/7193/unable-to-install-cloudron/3?_=1654970145198. Please help me with this topic. A bit similar to this topic.

Is this still an issue? Otherwise I will close this thread.