@zylstra thanks! fixed.

@hendrikvl It's not a problem to have local network specific configuration in unbound. See https://docs.cloudron.io/networking/#private-dns . As for the motivation, we use unbound because the mail server needs to do DNSBL queries. Most of the DNSBL servers like Zen SpamHaus will not respond if the queries originate from Google/Cloudflare DNS. This forces us to run our own DNS server. The other motivation was also to log DNS lookups by apps to identify any malicious use but we never got around to this (this was initially designed for a setup where we expected all app packages to be done by 3rd party). Finally, the unbound server should not be used much at all because most of the apps should not be querying anything external.

I didn't know Argo tunnels were free. So one can hide the mail service and put it thru an Argo tunnel on a subdomain to the world. https://docs.ibracorp.io/all-guides-in-order/documentation/cloudflare-tunnel Similarly one can have another domain and IP handle the incoming, which is tunneled to you via Tailscale. https://docs.ibracorp.io/all-guides-in-order/documentation/tailscale

@girish do you need anything from me or can you replicate that by yourself?

If you are using Nextcloud, or don't mind installing it, you can try the Polls module: https://apps.nextcloud.com/apps/polls

@chymian said in Information Central - notifications: forward to messengers, telegram or matrix, because they are read/recognized faster We discuss this in another post, I have proposed to offer a Webhook interface for events. And it was on the plan for update 6.3 but then postponed: Gitlab issue

@luckow Sounds like this could be adapted to a Cloudron App having it install in the appropriate directories for 'w' and 'ro' filesystems.

@murgero good to know !

@timconsidine Nice, looks interesting. More like Grafana than Cockpit from my initial glance over the site? Seems to be on the growing Wishlist too: https://forum.cloudron.io/topic/1125/netdata-real-time-monitoring

@humptydumpty thank you, will review

Your easiest customer to sell more to are your existing customers

@humptydumpty Perfect thank you.

@nebulon said in Quo Vadis Cloudron?: Otherwise I feel we still have to discuss the notification system then to also work for your use-case. Maybe you can start a separate thread describing what your ideal solution would look like a bit and we can see how this makes sense for us to implement this way or not. yes, I agree, will do that the next days.

@d19dotca I'm looking forward to that too, but mail is not so critical for me. I spent ~10 hours earlier this week getting Papercups up and running on a separate VPS. If it were on Cloudron, it would have been 5 mins plus config. So - for me at least - mail is a bonus, with core case for Cloudron proved day in day out.

@cyberfreakde no, the server and apps won't stop and will continue to run forever. Additionally, no features are disabled as such. The main change is that you cannot install more apps and existing apps won't get updates. I put these notes in https://docs.cloudron.io/billing/#canceling-subscription . Also, support is limited if you let the subscription lapse too much (hard to support if software is outdated by many releases).

@marcusquinn it's an interesting option to have available for Cloudron. I haven't researched whether there would be bandwidth issues for the deployed instance, serving out video. Maybe they have a clever way to minimise load on the hosting server.

@yeku I understand the points, but I have only seen a couple of errors, and they haven't prevented me getting the message or successfully using Cloudron. I think Cloudron have enough work running a fantastic architecture. The community here can help out @girish free of charge with great enthusiasm. Errors just need to be reported and they can be fixed quickly.

@marcusquinn Yeah. I was in a fraternity when I was in college. It was like the movie Animal House... but worse. Looking back on it I'm embarrassed by what I did. But it was fun at the time. College itself was a big waste of time for me.

@jdaviescoates Good! I want them to succeed. I neither want to deal with DevOps freelancers nor do I want to do sys admin myself.

@infogulch said in Nice ideas for reducing container size: paid once for the whole server To be fair, you will get the same footprint with a multi-stage build and images that depend on the same shared base. Let say that we will have a CloudronBase (Image LVL1), this image will include only ubuntu + minim software used for debugging. As a second step you will get different images with all the dependencies for the different cases: One image for every type of DB: MariaDB, pSQL, MongoDB. One for the webservers: Nginx, and Apache (that can maybe already include PHP). Then as the last level (3) of images, we have the language, like: node, python, etc, etc. This will have the same footprint as the one big image that we have now, it will always be a Cloudron Base, but it will be like: cloudronbase/nginx-node cloudronbase/mariadb Yes to slit the image in multiple parts will be a big work, but then we can update all the lvl with less effort. And as a second bonus, we will be able to have a server with just 2 WordPress, without unused library and software. To resume, what I propose is to keep the idea of an cloudron base, but to slit it, so that the apps can be developed easily, but servers with 20 GB of storage don't louse 10% of their space for code that they will never use.