Cloudron Forum

I wanted to share some information acquired from the school of hard knocks...

Background: I found that VaultWarden uses PBKDF2-SHA-256 as its default encryption with 600,000 iterations. One thing I discovered from security experts after being one of the many unlucky LastPass customers (victims of a hacking incident) was an added vulnerability in that everyone had the same number of KDF iterations based on default installation values. While VW's 600,000 is far greater (and better because it requires more calculation resources) than my LastPass default setting, it is unfortunately the same for everyone - unless you change that:)

Suggestions:

• Set a random value > 600,000 for the # of KDF iterations - Account Settings | Security | Keys. Setting a value too high can make VW a bit unresponsive, so increase sensibly based on VW's suggested increments.

• OWASP publishes a recommendation on the # iterations for PBKDF2 encryption . Check periodically to make sure your value is equal to or greater than their recommendation.

• Note: Each user will need to change this setting for their account.

Benefits: A random KDF means a hacker has many more possible combinations to try. With any luck they will move on to an easier target. Staying at or above OWASP recommended iterations makes sense as well.

Hope this helps.

@timconsidine You are so right. The best day for Team Cloudron is one in which there are no updates. I give @girish @nebulon @joseph an enormous amount of credit for the job they do. As someone who rolls out ~ monthly updates to users, every time that happens I pray that me and my team didn't miss something important. But it happens to all of us, despite good processes and best of intentions. But 8.3 will be replaced shortly with 8.3.1 and then 8.4 and then 9.0. And this difficult day will be replaced in everyone's memory by the great things that are yet to come!

Since Cloudron already manages "allowed ports" internally, I think that adding TURN server ports to this list is a necessary security feature. Here are the details:

Background:

Several Cloudron users have reported that unwanted (hacking?) attempts are being made to connect to their Cloudron's TURN server despite the fact that no installed apps utilize TURN.

Server resources (256MB RAM + application logs) are being wasted when no app needs an operational TURN server.

Managing this external to the Cloudron server via firewall or proxy leaves the potential for a support issue when a user adds an app that needs TURN, but forgets to update their firewall and enable the ports. (Note: Also, this solution just blocks the connection, but still wastes resources).

Proposal:

Have Cloudron handle TURN server management (resources, ports) internally with the following logic:

(1) If an app requires TURN server access (it should be declared in the app manifest). If that occurs, then the TURN server container should be "brought up" if not already enabled, resources (memory) deployed according to the configuration, and TURN ports permitted in the firewall.

(2) If no apps use TURN, then the server should be disabled, ideally, the container disabled, and TURN ports blocked by the internal Cloudron firewall automatically.

Perhaps a "first step" would be during Cloudron boot, to disable TURN ports (firewall) if no app needed TURN, leaving the container operational as is. This would accomplish the needed security and with no connections being possible, the actual utilization of the RAM should be almost 0.

Everyone, please feel free to add/delete/modify as you see fit!

I agree 100% with @igaudette. I do understand that some of the applications voted up on the App Wish List like Zulip (one of the top apps for quite some time) take a lot of resources. And Cloudron seems to support both business and home users. But before increasing my paid Cloudron instances, I am waiting to see some of my business needs met. It's a simple question of "make" vs. "buy". I would much rather "buy" a solidly hosted solution from Cloudron rather than "make" it myself using my company's development resources. But I can't wait forever and have started to investigate Cloudron's competitors to see if they can provide these business solutions. I believe in this platform, the Cloudron team, and our community, but spending time adding apps because they are "easy" seems like a bridge to nowhere. Let's start building to somewhere.

@d19dotca Many thanks for sharing this. I'd like to suggest another addition based on one nasty abuse I've seen: unsubscribe links that use http instead of https, hoping that browser security blocks/warnings will cause users not to follow through and unsubscribe. Anyone not using https for anything these days is not worthy of my time:) This puts them where they belong:

# Rule to detect unsubscribe links that do not use HTTPS
body UNSUB_LINK_HTTP /unsubscribe.*http:\/\//i
describe UNSUB_LINK_HTTP Unsubscribe link does not use HTTPS
score UNSUB_LINK_HTTP 10.0

Cloudron is so reliable I am using Kuma inside Cloudron to check availability on all my other unreliable vendors:) And some of them will have one less customer in the near future.

@necrevistonnezr Thank you for providing this information. It is really nice to know that although I am not a German taxpayer they are watching my back as well. Much appreciated. @joseph And as usual, Cloudron team is on the ball patching quickly so any exposure is minimized. Well done!

@girish We contributed some code back to Plausible Analytics some time ago to accomplish some things we wanted on our time line rather than theirs. They publish infrequent "official" updates to the self-hosted Docker code in part to minimize the support impact on their small development team. I believe they publish their code (not self-hosted) updates more frequently, which might give visibility to security updates and new features. Their primary source of revenue is from paid accounts that they host on their own infrastructure, so perhaps another reason is to entice customers to use their hosted Plausible solution.

FWIW, we do both, in part to support their efforts. They are solid and I have nothing but good things to say about them as a company, a platform, and as individuals.

@alex-a-soto Great idea. I'm interested. Let's see if anyone else has a similar interest. In either case, I will reach out as you suggested.

I would like to wish Team Cloudron a Merry Christmas and Happy New Year! Thank you for all you do to make our lives better. And to all the incredible members of our community that make this the best platform in tech, my appreciation and warm wishes for a terrific 2026:)

Thought I would share an update from U.S. based resellers. The supply environment is not good. Mfr prices on components and services are rising. It is unknown when backlogs will be satisfied. Bottom line: it will be chaotic.

@necrevistonnezr You raise some excellent points. I think it's also interesting how Apple has just released the Neo, a $599 ($499 for education market) laptop that many here in the U.S. are predicting will really challenge Microsoft's WIN 11. The fact that Apple has a tight control on its supply chain (something you already mentioned) and able to deliver product at scale might be the deciding factor (ignoring the OSX vs. WIN debate). Students can not wait for the computer industry to sort out this mess. They reach various stages and need a computer to continue their education. And if Apple has the product, they win by default.

And your comment about farm tractors is really interesting. Perhaps this is an untapped Cloudron server market. @girish Perhaps we should consider packaging farming-related applications:)

@joseph What I see appears to be "normal" attempts to connect to a TURN server. The problem is that there is no application "publishing" my TURN server to make it usable by potential WebRTC connections. So these are people trying to leverage a misconfigured TURN server or a software vulnerability. In my mind, it's no different than people probing to SSH to a server - hence the reason to use Fail2Ban and other tools to restrict this.

Since Cloudron manages "allowed ports" internally, I think that TURN server ports should be added to that list as follows:

(1) If an app requires TURN server access (it should be declared in the app manifest), then TURN ports should be opened)
(2) If no apps use TURN, then those ports should be closed by CLoudron automatically.

Agreed. Cloudron is A+:)

@marcusquinn I would build a new room with floor to ceiling monitors on one wall. Reclining theatre seating and a kegerator. And a Hirsh keypad to prevent anyone except me from entering:)

As a relatively new member of the Cloudron community (especially compared to @scooke) I can see both points of view. The current collection of apps is very eclectic, spanning both personal and business. And to a certain extent that reflects the wide range of our community - a strength.

I do not envy @girish and team trying to please all of us. It is both thankless and impossible. But one person's "must have" app is another person's "who cares". The danger is losing members if their needs are not met with the applications they need or want.

Perhaps having a simplified installation process would allow more people to customize their Cloudrons as desired. And yes, despite the warnings that you are on your own, I am sure that support questions will arise. And the spirit of the Cloudron team and the community to help will always prevail. As long as these questions are within reasonable limits, perhaps this will allow the platform to grow more valuable without being overwhelmed. I would suggest that custom-installed apps have its own topic area, especially if the results could be hidden from search engines to prevent prospective members getting the wrong impression about Cloudron's reliability per @scooke 's valid concerns.

Finally, I am personally interested in a business-oriented, custom-app platform where Dockerized applications can be hosted in a well-thought out and architected environment like Cloudron. We are exploring several ideas along these lines, including adding some private applications we have created, others we have paid to license, and some that are open source. And these systems would require incremental Cloudrons - helping to grow the revenue stream. In the end, that's the idea, isn't it...

@timconsidine Personally want to thank you for pushing CCAI and moving the development to the point where the Cloudron Team is taking this the next part of journey. In my mind, this makes Cloudron THE platform for hosting custom apps.

@necrevistonnezr But do you know someone in HR that can get us all a job when AI replaces us:) Janitor, cafeteria cook. There are many talents hidden here.

Seriously, I am shocked that a company of your size and stature is being treated so poorly by vendors. If this is what your company is experiencing, then we all are in big trouble. Usually, it's the little people that get screwed. But when this is happening to the big and powerful too, it is beyond concerning.

@necrevistonnezr I have a friend who worked in the semiconductor industry in the U.S. This has been a several decade process of exiting chip manufacturing, especially "commodity" chips like memory. Memory chip manufacturers experienced boom/bust cycles tied to chasing demand, building factories, only to find them empty after demand stabilized. In my opinion, their assessment today to jack up prices and build nothing is the result of their past experiences.

Unfortunately through intense regulation (many would argue appropriate regulation), other countries have taken a more laissez faire attitude about making semiconductors and have reaped the economic benefit. But many of the chemicals used in semiconductor manufacturing are endocrine disruptors, highly toxic in other ways and generally difficult to protect production workers.

But that (and enormous capital costs) may explain why America and Europe were less interested in producing chips. Again, "short-term, earnings this year above all else, share buyback" mentality that seems to prevail in Western economies justifies a "buy" instead of "make" strategy.

@creative567145 Try these (replacing endpoint and region with proper references matching your bucket):

export S3_ACCESS_KEY="your_backblaze_b2_keyID"
export S3_SECRET_KEY="your_backblaze_b2_applicationKey"
export S3_BUCKET="your-bucket-name"
export S3_ENDPOINT="s3.us-west-002.backblazeb2.com"
export S3_REGION="us-west-002"
export S3_SSL="true"