Upcoming removal of GitLab SSO in Mattermost v11 – suggestion for Cloudron
-
Mattermost v11 deprecates GitLab SSO – impact on Cloudron users 🥶
Hi all,
Mattermost announced that starting with Server v11.0.0 (October 2025) they will remove the built-in GitLab SSO integration. The current v10.x branch will still be supported for one year, but after that the direct GitLab option disappears (That's what I understand!).
In the open source edition, GitLab has basically been the only built-in OAuth2 IdP option. This has been very valuable because many of us could “bridge” GitLab SSO to other OAuth2 servers, which allowed users to have a passwordless login setup without needing the commercial edition.
It really doesn’t make sense to migrate to a commercial license just to keep a feature that was already free and widely used. I’m sure many Cloudron users currently rely on Mattermost → GitLab SSO for exactly this reason.
So it would be great if Cloudron could either:
provide an official custom image that still includes GitLab SSO, or
make it easier for users to run their own pre-compiled Mattermost builds while keeping Cloudron’s management benefits.info:
https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126 -
@Latinosnctv I think this involves running a forked version of mattermost. I think this is beyond our product's reach. We don't maintain patches and feature sets over upstream apps - unless there is some major security issue and that too only as a short term measure.
If you (or someone) has resource, please fork away our package - https://git.cloudron.io/packages/mattermost-app/ . Just have to point it to the upstream fork and build it yourself.
-
IMHO!
all these chat tools started of good and over the time get afflicted by the curse of greed.
I know that Mattermost is the closest to Slack and that is why understandably it still is so popular.
But same with Rocket.Chat, stripping down the FOSS version more and more to force people into subscriptions.When I get asked "Hey, what chat tool should we use with Cloudron?"
If you don't need a deep integration with ticket systems and such, just use Matrix/Element.
I also pay for multiple subscription services, including Cloudron.
But there is a difference in my head between them.I would also be very happy to pay for features once and then own them.
A good example would be the module system from Freescout.
I can buy e.g. the End User Portal and then own it.
No monthly fee for having this "feature".Or another service I use where the whole service is free and only the "expert" features that need special maintenance I can subscribe to as an extra.
But with the last example, I have the whole core functionality for free and need only to pay for the singular "expert" feature I need.
Still would prefer to pay once and then be done with it. But I also understand that certain features require very regular maintenance which I don't want to or simply can't do.
But I rather pay for the singular feature instead of one big chunk of money that cross finances everything else I don't want/use/need.This is a touchy and complex topic in the current time of
"You will own nothing and be happy".
With services and digital products, I can understand it to certain degree.
But don't get me started with physical products that turn existing features into a subscription.
Looking at you BMW trying to sell a "heated seats subscription"!
We as consumers need to be way more vocal and strict when companies try this.Sorry, little rant from my side
-
IMHO!
all these chat tools started of good and over the time get afflicted by the curse of greed.
I know that Mattermost is the closest to Slack and that is why understandably it still is so popular.
But same with Rocket.Chat, stripping down the FOSS version more and more to force people into subscriptions.When I get asked "Hey, what chat tool should we use with Cloudron?"
If you don't need a deep integration with ticket systems and such, just use Matrix/Element.I also pay for multiple subscription services, including Cloudron.
But there is a difference in my head between them.I would also be very happy to pay for features once and then own them.
A good example would be the module system from Freescout.
I can buy e.g. the End User Portal and then own it.
No monthly fee for having this "feature".Or another service I use where the whole service is free and only the "expert" features that need special maintenance I can subscribe to as an extra.
But with the last example, I have the whole core functionality for free and need only to pay for the singular "expert" feature I need.
Still would prefer to pay once and then be done with it. But I also understand that certain features require very regular maintenance which I don't want to or simply can't do.
But I rather pay for the singular feature instead of one big chunk of money that cross finances everything else I don't want/use/need.This is a touchy and complex topic in the current time of
"You will own nothing and be happy".
With services and digital products, I can understand it to certain degree.
But don't get me started with physical products that turn existing features into a subscription.
Looking at you BMW trying to sell a "heated seats subscription"!
We as consumers need to be way more vocal and strict when companies try this.Sorry, little rant from my side
-
@Latinosnctv I think this involves running a forked version of mattermost. I think this is beyond our product's reach. We don't maintain patches and feature sets over upstream apps - unless there is some major security issue and that too only as a short term measure.
If you (or someone) has resource, please fork away our package - https://git.cloudron.io/packages/mattermost-app/ . Just have to point it to the upstream fork and build it yourself.
@girish I totally understand your point. My suggestion was not about Cloudron maintaining a fork (I will explain myself better).
The idea is more about reducing friction for users who want/need a custom build, instead of everyone having to run their own “loose” installation.
Since Mattermost remains AGPLv3 in the open source edition (without the limitations that their official pre-built binaries include), there could be a middle ground:
-
Cloudron could allow users to select a custom build in the app configuration, similar to how today you can choose between the Team and Enterprise editions.
-
Cloudron can simply add a disclaimer that running a custom build is at the user’s own risk, in case the app breaks or is unsupported upstream.
This way, it remains collective and consistent for all Cloudron users who need this, without putting extra maintenance burden on the Cloudron team.
-
