Cloudron Forum

App is now signed.

@timconsidine Yes, the developer's got the background for decentralisation with Bitcoin development, and seems to thing he's getting speeds close to regular Wireguard. Only gotchya is the network remains small at the moment, so it's only useful as more of a Tailscale/Netbird alternative for now. Then, for the network to grow, more people will have to opt-in to sharing their IP & unused bandwidth as exit nodes.

Hello @mejoaocordeiro The URL states cloudron:1337 that does not look correct. Also the output of cloudron-support --troubleshoot is still missing see https://docs.cloudron.io/troubleshooting#troubleshooting-tool Please send that.

@paulfitz yes, we will look into this again. cc @james

Thanks - I see where you are coming from, but this is not directly what I aimed for with my initial post as a cheeky attempt to get consideration for a mail archiving app officially packaged for Cloudron. nonetheless, I see both as valuable topic of discussion: Legal compliance with business email archiving, especially in transactional email scenario - as a Cloudron feature tight to cloudron email server Email archiving app, possibly providing the above functionality by delegation of the feature but also enabling the archive of other emailing solution not residing on Cloudron (e.g. gmail, outlook etc..). Selfishly, the later is what is most attracting to me due to the need of archiving emails from various email solutions / providers as well as cloudron ones.

@james @james said: I would argue 5 minutes is already a pretty big timeout window. Thanks for the info - I would argue the same. @james said: Do you use Cloudflare Proxying for your Koel app? No Cloudflare Proxing here. However, this note made me think of something else in our local network that needs checking. Thanks for this. I will revert back if/when relevant.

Hello @abo_shahad I am a little curious, because you stated before: @halkhamis said: I’m using a managed database hosted on AWS/Azure. and now it is: @abo_shahad said: Alibaba Cloud RDS so the DB infrastructure changed from AWS to Alibaba within two days? @abo_shahad said: 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. If a backup site based on S3 is used and not a local mounted one, this can be completely avoided. Many S3 providers offer write-once, read-many. So when the backup gets stored encrypted on the S3, it can't even be encrypted again by a ransomware. Also, Cloudron full system backups include everything to restore from 0 to 100. So even if the full drive gets encrypted, you can restore the whole set up from a Cloudron backup without the need to restore the whole server. Just a fresh Ubuntu and the Cloudron restore from the backup site is enough for 0 to 100. But I can see that you really want to do this. So your options are to fork the Freescout app and maintain it yourself or install it manually in the LAMP as suggested before. Still, this will cause issues with the Cloudron backup and restore process leading to even bigger issues and frustration when the need to recover arises.

Hello @hakunamatata Can you try the following in an attempt to fix this issue? You need the cloudron cli # Example Dashboard Domain my.cloudron.dev cloudron env set PENPOT_SSRF_ALLOWED_HOSTS="$YOUR_CLOUDRON_DASHBOARD_DOMAIN" --app $YOUR_PENPOT_APP_LOCATION_OR_APPID # Full example: # cloudron env set PENPOT_SSRF_ALLOWED_HOSTS="my.cloudron.dev" --app penpot restart the app and try again to log in with OIDC using your ccTLD domain.

Bichon reached v1.0 recently! Even v1.1 couple of days ago.

Hello @flexplore Can you please post the output of systemctl status docker.service and journalctl -xeu docker.service so I can take a look at the log to understand why the docker.service is not starting correctly?