I publish independent Linux builds from the latest Mattermost ESR source for amd64 and arm64. The packaged user limit is set to 1,000 and there is no product-imposed message history cap. They are community builds, not official Mattermost releases, and they do not include commercial support.
This is not a campaign against Mattermost. I value the product, understand why a company needs a sustainable commercial model, and want the upstream project to remain healthy. My position is narrower: a real community deployment can be larger than 250 users without becoming an enterprise procurement project.
The need came before the build
I operate a Mattermost server with more than 500 users. It is not a temporary evaluation and it is not an oversized test environment. It is a working communication service with history, integrations, expectations, and people who rely on it.
A 250-user ceiling does not make that operational need disappear. Moving immediately to a different product would introduce migration work and user disruption. Holding on to an old release would eventually create a security and maintenance problem. Building the current ESR from source gives me a third path: remain current while preserving the scale my deployment already needs.
What Mattermost changed in v11
Mattermost announced two free paths for v11. Mattermost Entry became the commercial-license option with a broad feature set and usage limits. The official compiled Team Edition remained available under the MIT-Compiled License for open source-oriented use, but its user limit fell from 1,000 to 250 and GitLab SSO was removed.
The announcement also makes clear that the underlying open source project remains under AGPLv3. Community members can still compile, use, modify, and contribute to it. That distinction matters: the official compiled offering changed, but the source did not close.
Evaluation with expanded features and SSO.
10,000-message plan plus other usage limitsFor hobbyists, personal projects, and open source-oriented organizations.
250 users and no GitLab SSOFor self-hosted deployments that need a larger practical middle ground.
1,000 users and no message history capWhere I agree, and where I differ
Mattermost has legitimate reasons to distinguish unsupported community deployments from commercial environments. Large installations carry expectations around security response, compliance, integrations, and support. A free binary should not be mistaken for an enterprise support contract.
I also hope Mattermost continues publishing Team Edition for deployments below 250 users. That offering is valuable for hobbyists, laboratories, communities, and smaller organizations that specifically want open source software. It should remain a first-class path, not merely a short evaluation route.
Where I differ is the idea that every deployment beyond 250 users fits neatly into the same commercial category. My server already exceeds 500 users. For my use case, retaining the previous 1,000-user ceiling is a practical middle ground. These builds exist because I needed that middle ground myself.
What I publish
- Builds from the latest Mattermost Extended Support Release source only.
- Linux archives for amd64 and arm64 servers.
- A packaged user ceiling of 1,000.
- No artificial 10,000-message history limit.
- Public downloads without an account or installer wrapper.
At the time of publication, the package repository contains Mattermost 11.7.9. The package page is the source of truth because I update the builds as the maintained ESR moves forward.
Why I stay on ESR
A chat server is not where I want novelty for its own sake. ESR gives administrators a longer maintenance window and a more deliberate upgrade rhythm. It also keeps these packages focused: I can track one supported branch, rebuild security and maintenance releases, and avoid presenting every feature release as production-ready.
Latest ESR only is therefore a maintenance promise and a boundary. These packages are not an archive of every historical release. If an older release is no longer on the maintained ESR line, operators should plan an upgrade instead of treating an old community build as a safe long-term endpoint.
What the packages do not promise
The absence of a product-imposed message cap does not make storage infinite. Administrators still need retention policy, database maintenance, attachment capacity, backups, monitoring, and tested recovery. A 1,000-user ceiling is also not a performance guarantee. Real capacity depends on activity, integrations, calls, database design, storage, and the surrounding infrastructure.
These packages are not affiliated with or endorsed by Mattermost. They are not a replacement for commercial support, paid capabilities, compliance guidance, or a service-level agreement. Operators should review the source, package provenance, applicable licenses, and their own support requirements before deployment.
License and identity matter: Mattermost says source-built forks remain available under AGPLv3 and also calls out obligations around its trademarked name and logo. Anyone modifying or redistributing the software should read those terms directly and make their own deployment compliant.
How I would approach deployment
- Back up the database, configuration, plugins, and file storage before replacing a server binary.
- Test the upgrade against a restored copy of production data.
- Read the upstream ESR release notes and required migration steps.
- Confirm architecture, package version, plugins, and external integrations.
- Plan rollback before the maintenance window begins.
- Monitor database migrations, application logs, queues, and client behavior after startup.
A community build changes who assembled the binary. It does not remove the normal responsibilities of operating a stateful service.
Why keep doing it
I build these packages because I use them. The goal is not to deny Mattermost a commercial business. The goal is to keep a useful open source deployment maintainable at the scale I already operate, then make the same build available to others who understand the trade-off.
I would be happy to see official Team Edition continue serving the smaller end of the community for years to come. For deployments like mine, the independent ESR packages provide a practical bridge: current source, familiar operations, a 1,000-user ceiling, and message history governed by the infrastructure rather than an evaluation counter.