Cloudron Forum

@nebulon said: which is an android I can help test the app if you're willing to share the APK. @nebulon said: Media handling will come, so far those are just files in a folder, so one can purge on timestamp if that is wanted. But I guess we will provide some better controls over time. To share some issues I ran into in Matrix. Last time I tried deleting media to save on space, it corrupted the rooms and I had to wipe the entire app. Luckily, I had exported the rooms via HTML/JSON beforehand. I used the Matrix admin tool btw. I didn't manually delete things. But, manual deletion of a room's media folder (assuming each room has its own folder) would be ideal. For instance, for DM rooms between users, we share a lot of media between each other but it serves its purpose once seen. Yet, that accounted for a huge percentage of the app's media storage. @nebulon said: Those make a lot of sense when you don't trust your coordinating server of course This will limit the app location to on-premise servers, really. I wouldn't trust a VPS provider with my chats.

@james thanks! Related: cloudron/php-base:8.5-20261021 and the current WordPress package (3.17.1) still ship libbrotli1 1.2.0-3build1, while the Ubuntu fix for CVE-2026-111497 is 1.2.0-3ubuntu0.1. PHP apps reach this through libcurl, as WordPress decodes Brotli on outbound requests (see Patchstack's write-up, https://patchstack.com/articles/wordpress-doesnt-ship-brotli-its-still-exposed-to-cve-2026-111497/). Could the PHP base get a rebuild as well?

I don't have an immediate need for anything like this myself but it sounds useful. Made me think of the requirement for listing Mastodon servers on the official directory https://joinmastodon.org/servers , one of which is that at least 3 people have access to the server (actually, I've either mis-remembered, or it's changed, seems it's just at least one other person as per https://joinmastodon.org/covenant ). This could be one easy way to facilitate that.

The way it's implemented is that the white list is provided in the VPN UI but the VPN itself is optional. It's also not implemented at a per-app level but at a system level just like the current VPN protection. AFAIU, these IPs are primarily maybe intranet addresses. So, it's a way to say that these IP addresses don't need any protection.

[2.13.1] Update mirotalksfu to 2.7.11

I've packaged Warmbly, an Apache-2.0 platform for B2B cold outreach, as a community app. Connect your sending mailboxes and run multi-step campaigns across them, with warmup, a unified inbox for every reply, a CRM, hosted lead-capture forms and open/click tracking on your own tracking domain. [image: Warmbly mailboxes and warmup] Install: add this catalog under Settings → Community apps, then install Warmbly from the App Store: https://raw.githubusercontent.com/marcusquinn/cloudron-warmbly-app/main/CloudronVersions.json or cloudron install --versions-url <that URL> --location warmbly.example.com. The installer asks for four secondary domains: API, admin panel, tracking and forms. What fits in with Cloudron Single sign-on, and the first sign-in claims it: open the app and choose Continue with your Cloudron. You don't need to type an email or password, and the first person to sign in becomes the owner and platform admin. Until then, password sign-ups are closed, so nobody can claim a fresh install before you do. After that, the app's access control decides who gets in. Password sign-up stays invitation-only. Platform email (sign-in codes, password resets, invitations, digests) goes through the Cloudron mail relay. Sending mailboxes on Cloudron Mail work over IMAP/SMTP. Gmail and Microsoft 365 work with your own OAuth clients (the README has the redirect URIs). Tracking domains: use a separate registered domain for opens, clicks and unsubscribes. Customers' own tracking domains (a CNAME to yours) are added as aliases of the app, so Cloudron issues their certificates. The whole self-host stack (API, event consumer, mailbox worker, tracking, forms, realtime gateway and NATS JetStream) runs in one container on the PostgreSQL and Redis addons. Data and encryption keys are in Cloudron backups. Good to know 2 GiB memory default; raise it for many mailboxes. Requires Cloudron 9.1+. Billing, update checks, CAPTCHA and product analytics are off. It runs on a single node; upstream's multi-node worker fleet isn't used. The dashboard updates live through the API domain. Upstream's CLI event stream and SDKs can't discover the realtime socket on this package yet. The image uses upstream's release images, pinned by digest, plus one small patch (the first Cloudron sign-in becomes owner). The patch is in the repo, and I'd like to upstream it. Images and the catalog carry GitHub build provenance. Links Package, setup guide and issues: https://github.com/marcusquinn/cloudron-warmbly-app Warmbly: https://github.com/warmbly/warmbly Docs: https://docs.warmbly.com App Wishlist post with further info and screenshots: https://forum.cloudron.io/topic/16228/warmbly-free-open-source-alternative-to-warmly-instantly-apollo-smartlead-listkit-lemlist-zoominfo-mailreach-warmforge-etc This is a first release, so feedback is welcome, especially on deliverability with Cloudron Mail mailboxes and on tracking-domain setups. I maintain the package independently of the Warmbly project; please report packaging problems on the package repo rather than upstream.

Now packaged as a community app. Details here: https://forum.cloudron.io/topic/16229/warmbly-open-source-cold-outreach-and-email-warmup-campaigns-unified-inbox-crm-with-cloudron-sso-and-cloudron-mail

Thanks, I have removed it.

I moved most of my apps to on-premise servers and kept a handful on a Hetzner VPS to keep costs down. I'm using SFF computers like the HP Elitedesk 800 G3 Mini (under $100 on eBay nowadays) and it's a solid machine for hosting. Older ram like DDR3/DDR4 are easier to find/buy too.