Cloudron Forum

Maybe we don't have to worry too much on the samba issue ? [image: Screenshot 2026-10-23 at 08.32.36.png] https://thehackernews.com/2026/10/two-cvss-90-linux-ksmbd-rce-flaws.html "Running systemctl status ksmbd or lsmod | grep ksmbd confirms whether the module is active."

Well, as soon as I manually edit .conf file and add allow rule for the public IP of Cloudron server - I can access the app protected by VPN Protection. So, something is either broken in network routing (if the expectation for the routing to be done via internal IPs) or the .conf file should include allow PUBLIC-IP rule.

@girish Weird blog to be honest. Only two posts with the first one telling us LLMs will hack everything on the internet and the second one ranting about how LLMs didn't find an easy hack but deceived us. I am not skilled enough of doing any testing myself but I am thankful for your overtime hours and acting as fast as you did. If it happens to be not as bad as everyone feared, we can happily move on. As for me, I took it as an urgent reason to finally switch a legacy website. Working under pressure gets things done faster.

We already run a company VPN. For certain Cloudron apps (admin tools, internal services, staging, etc.) we would like to restrict access so they are only reachable from our existing company network / VPN ranges. The current VPN Protection feature solves a similar problem, but it requires users to connect to Cloudron’s own VPN app. For organizations that already have a VPN or a well-defined internal network, this means running and managing a second VPN just for Cloudron apps, which is unnecessary overhead. Proposed feature: Add a per-app setting (similar to “Require VPN”) that allows defining one or more allowed IP ranges (CIDR). Requests from outside these ranges are rejected (e.g. with a 403 or a simple “Access restricted” page). Example use cases: App only reachable from the company VPN / office LAN Different apps with different allowlists (public website vs. internal tools) No need for an additional VPN client when the user is already inside the company network Why this is better than only VPN Protection in our case: We already have a VPN. Forcing Cloudron’s VPN on top creates friction and support load. Source IPs are known and stable when users come through the company VPN. Simple CIDR allowlist is easy to understand and configure for admins. Technically this should be straightforward to implement in the existing reverse-proxy config generation (Nginx allow / deny per app server block), similar to how VPN Protection already injects rules. Would be happy to help test if this gets implemented.

[2.8.0] Update python-base | final to 3.12-20261023 security: fix eMudhra cert compromise

@paramedicspecialist Thanks for packaging this! I’ll definitely give the Cloudron package a try. @joseph Just to add some context about MeshCentral: it’s actually quite a bit more powerful than a simple remote desktop tool. It’s a long-standing open-source remote management project, originally developed with strong Intel involvement, particularly around Intel AMT/vPro. I personally use MeshCentral in production to manage around 300 devices across 3 countries. With the regular MeshAgent, you can remotely access desktops, terminals and files, run commands/scripts, manage devices, and tunnel protocols such as RDP or SSH. Where it gets especially interesting is with Intel vPro/AMT hardware. You can get true out-of-band management: remotely power a computer on/off, reboot it, access hardware KVM, boot to BIOS or another boot device, etc. This can work independently of the operating system — even when the machine is powered off, as long as AMT remains powered and reachable. So while it’s not a full RMM in the same sense as products with integrated patch management, MeshCentral can be a very capable self-hosted management platform, especially when combined with scripts or another software deployment/patching solution. Really happy to see it packaged for Cloudron!

Main Page: https://chatto.run/ Git: https://github.com/chattocorp/chatto Licence: AGPL-3.0-or-later (shared framework modules, standalone frontend, docs and examples are Apache-2.0; the bundled Runling orchestrator is MIT) Dockerfile: Yes – official image plus a Docker Compose example (https://github.com/chattocorp/chatto/tree/main/examples/dockercompose) Demo: Official Chatto Community (a live instance run by the developers): https://chat.chatto.run/ Summary: Chatto is a fast, fully-featured, web-based team and community chat app that you can self-host for free. Think Slack/Teams/Discord, but tiny: it ships as a single ~50–70 MB Go binary with no separate database required (data lives in an embedded NATS JetStream store, or an external NATS server for scaling). Features include rooms, threads, replies, DMs, notifications and Web Push, full-text search, file attachments (with thumbnails, GIF processing and ffmpeg video transcoding), voice and video calls with screen sharing (via LiveKit), flexible roles and permissions with room groups as permission boundaries, SSO via external login providers (e.g. Pocket ID), S3-compatible storage for media, an admin dashboard, operator CLI, and backup/restore tooling. It also exposes GraphQL/ConnectRPC and NATS APIs for bots and integrations. Privacy is a core focus: message text and selected account fields are encrypted at rest with per-user keys, and crypto-shredding is supported on account deletion. It's made in Germany and positioned as GDPR-ready. Each deployment is one isolated community — no federation by design. Notes: Why I like it: A genuinely lightweight alternative to Slack / Discord / Mattermost / Rocket.Chat that still covers the essentials, including built-in calls and screen sharing. Single binary with an embedded data store should map nicely onto Cloudron's /app/data model, and SSO support means it could hook into Cloudron's OIDC login. Active development (0.4.0 released, ~2.8k GitHub stars). Packaging considerations: Voice/video needs LiveKit, which wants its own hostname plus TCP 7881 and UDP 3478 / 50000–50200. Calls could be optional in a first version, or LiveKit could perhaps use Cloudron's TURN addon. Direct email/password registration requires SMTP (Cloudron's sendmail addon should cover this). Push notifications need VAPID keys, which could be generated on first run. Runs as non-root (UID 1000) by default. Concerns: Still 0.x – the docs say to expect bugs, missing features, frequent upgrades and unannounced breaking API changes. The project doesn't accept outside contributions at this time. It's openly built with the help of AI coding agents, which some users may want to know. Developer contact: Chatto is developed by Hendrik Mans in Germany. I can connect. Alternative to / Libhunt link: Slack, Microsoft Teams, Discord, Mattermost, Rocket.Chat (no Libhunt listing yet) Screenshots: Light: https://docs.chatto.run/_astro/chatto_light.DjfyysJr_Z2cNdhj.webp Dark: https://docs.chatto.run/_astro/chatto_dark.ku0fA5mZ_Z1SQ7CW.webp Hero: https://chatto.run/_app/immutable/assets/chatto.CJP_M7Vp.webp Logo: https://github.com/chattocorp/chatto/blob/main/favicon.png

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.