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.

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.

@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!

@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.

@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.

@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!

@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:)

@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...

@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"

@nebulon @girish I think that user choice would be best with Cloudron recommendation (3 failures in a row) being the default.

I have been playing with packaging Keila. Still needs some more work, though. I am particularly interested in the ability to set sending limits (tied to Paddle plans).

@girish It would be really helpful to know on a quarterly basis what apps will be officially packaged in the upcoming quarter and what apps will be deprecated. While votes on the App Wishlist are part of that decision, I'm sure there are other considerations as well. Knowing the team's intent would be helpful in planning our own activities and whether Cloudron can be leveraged to host specific software platforms. I also recognize that bugs, security issues, platform enhancements, etc. can limit the core team's ability to package apps and for that reason, timelines can change. But knowing what is first, second, third on the "intent list" would be a good start.

@Dont-Worry I am experiencing similar thoughts about the potential for using Cloudron in mission-critical situations. In past years I have preferred "buying" services from larger, known organizations rather than "building" it myself. But I have been disappointed on too many occasions by these companies. The Cloudron team and community is incredible and I think my company's needs might be better served here than in other places. To achieve this goal we must also ask what "we" can do to help the Cloudron team (@girish, @nebulon ) get there. Whether money or time or both, we should be prepared to invest in our future!

@infogulch Looks like you are right. I checked one of my VW backups and searching for the unique KDF iterations revealed that it is in fact stored in the database. So the information I read after the LastPass breach was incorrect suggesting that a random value of similar size provided more protection that just using the default value.

As I recall the default value at that time was 100,000 and OWASP was suggesting a much larger number. In fact some long time users had much smaller KDF iterations, making the hacking effort minimal.

So it looks like OWASP recommendation should be the minimum KDF iterations and to @girish question earlier, perhaps increasing the value based on your own hardware devices in sensible increments.

Thank you @infogulch for correcting my misinformation. But since my random # was higher than 600,000, I'm keeping it:)

@girish Thanks for the suggestion. Sounds like I will need to pursue this idea on an app by app basis, rather than signing on as a Cloudron user. If I am successful, I will share the results so that others can benefit as well.