Mattermost is one Linux binary on PostgreSQL, released under MIT on the 16th of every month

One Linux binary, one datastore, and PostgreSQL is not negotiable

The deployment shape is stated in a single sentence and it is the first thing to accept or reject. Mattermost runs as a single Linux binary and relies on PostgreSQL. There is no embedded database, and the README names no alternative store, so a Postgres instance is a prerequisite you provision, secure, back up and upgrade on your own schedule rather than one the application manages for you.

The single-binary claim cuts both ways. It is what makes the tar install and the Docker image straightforward, since there is one artefact to run and one port to expose. It also means the repository you would clone is not what you deploy, and that a Windows or macOS host is not a server target. The clients are separate downloads for Android, iOS, Windows PC, macOS and Linux, so the desktop applications cover the operating systems the server does not.

For a team, the operational consequence is that Mattermost inherits the failure modes of its datastore. A chat history that disappears is a PostgreSQL backup that was not taken, and a migration that stalls during a release is a long-running lock rather than a Mattermost bug. Size the database for the message retention you intend to keep, because the platform stores conversation history in it and offers nothing that substitutes for it.

Open core means two licence files, and the README points you at only one of them

The README calls Mattermost an open core platform, and a new compiled version is released under an MIT license every month on the 16th. Both statements are true and neither tells you the whole licensing story. The repository ships LICENSE.txt, which the README names as the place to find license rights and limitations, and it also ships LICENSE.enterprise at the top level. Two licence files next to a blanket MIT sentence is the open core structure: a permissive core and a separate set of terms for something else.

GitHub does not resolve it either, recording the licence as NOASSERTION rather than MIT. So the honest position is that the MIT statement in the README describes the compiled release, and the boundary between what that release covers and what the enterprise terms cover is defined in the two licence files. The README does not enumerate which features sit on which side, and no feature table in it is labelled as paid. That list is a decision you make by reading the files and by asking the vendor which tier you are deploying.

This matters before the first install rather than at renewal time, because a feature your team depends on may be the thing that moves. Anyone building a compliance case should record which licence governs the exact version they run, and re-check it when the monthly release lands, since a core release can ship alongside a change in what the enterprise file covers.

Six install paths, and the named Ubuntu guide stops at 20.04 LTS

The install section lists six routes and they are not interchangeable. Docker gets you a container fastest. The Ubuntu path is specified for Ubuntu 20.04 LTS, which is the detail that catches people: there is a guide for that release and none named for 22.04 or 24.04, both of which are long past their own end of support. Mattermost Omnibus packages the server with its dependencies, Kubernetes installs through an operator, Helm is the same operator reached through the package manager, and the tar route is the bare binary. The general deployment guide at docs.mattermost.com/guides/deployment.html is the one to read first, because it is the index the other five hang off.

Each path has a cost. Docker gives you a rebuild or a pull on every release, which is convenient for a monthly cadence and awkward for a rollback to a specific patch. Tar gives you a versioned directory and a config file you control, at the price of managing the service unit yourself. Ubuntu packages tie you to a distribution's update behaviour. Kubernetes and Helm give you scaling and restart behaviour, at the price of an operator whose version must track the server's.

The monthly release date makes the choice of path more consequential than it looks. With a new compiled version on the 16th of each month, whatever you chose will be upgraded on your cadence, and the path that makes a rollback easy is the one worth the extra setup.

A stable patch and a 12.0.0 release candidate shipped days apart

The release record shows two trains running at once. v11.11.1 landed on 2026-09-24, v12.0.0-rc1 on 2026-09-18, and v12.0.0-rc2 on 2026-09-25. A maintenance patch on the 11.11 line and the second release candidate of the next major landed one day apart, and the repository's last push was on 2026-09-29. The project is not archived, and the release cadence is a fixed monthly date rather than an approximation.

For a self-hosted operator this turns into a concrete question with no default answer: which tag does your instance run. The 11.11 line is the one that received a patch release, which tells you it is the line receiving fixes. The 12.0.0 candidates are where new behaviour arrives, and a release candidate carries the specific risk that its own README change notes have not been tested by the field. Running a candidate buys you early access to a major version at the cost of being the person who finds the problem.

The monthly date helps more than it first appears, because a predictable release day makes the patch window a calendar entry rather than a surprise. It also means an operator who skips a month is carrying a known-old build, and the security channel that tells you about critical releases is the mailing list described further down.

The monorepo you clone for development is not the artefact you run

The README says this repository is the primary source for core development on the platform, and the top-level layout shows what that costs. server/ holds the Go side that becomes the binary, webapp/ holds the React and TypeScript client, and api/, i18n/, e2e-tests/, tools/ and docs/ sit beside them. GitHub classifies the primary language as TypeScript, while the README describes the project as written in Go and React, which is what a repository with a large typed frontend and a Go backend looks like from the outside.

None of that is your deployment. There is a separate developer machine setup guide for people who want to write code for Mattermost, and a .gitpod.yml plus a .nvmrc and a mise.toml, which is the toolchain pinned for contributors. .yamllint, .editorconfig, a CODEOWNERS file, an AGENTS.md, an enable-claude-docs.sh script and a .cursor/ directory tell you the same thing about how the project is worked on internally.

So the clone is for contributors, and the operating instructions come from the documentation site rather than from the source tree. If you are evaluating the project, read the deployment guide and the security bulletins. If you are contributing, expect to set up Node and Go from the pinned files before you build anything, and note that .gitmodules means submodules are part of a fresh checkout.

Five features in the description, and an extension surface of a different size

The README's description of the platform names five things: chat, workflow automation, voice calling, screen sharing and AI integration. That is the whole product summary on the front page, and it is worth noticing what the extension side of the repository is doing by comparison.

The developer documentation covers building an integration through APIs, Webhooks, slash commands, Apps and plugins, and the API site lists webhooks, slash commands, drivers and a web service. A marketplace entry claims over 700 integrations. In the source tree that integration story has its own home: the api/ directory at the top level, and the fact that a plugin model exists alongside Apps and slash commands means the platform expects third parties to add behaviour, not just configuration.

That gap between a five-item feature list and a first-class extension surface is the real design of the product. Chat is the part everybody uses. Everything a team adds afterwards, a slash command that calls their deployment system, a webhook that posts an incident into a channel, a plugin that lives in its own repository, goes through one of those mechanisms. When you evaluate the platform, the integration list matters more than the feature paragraph, because that is where the platform's usefulness past the first month is decided. The README does not document how a plugin is packaged or what privileges one is granted, so that belongs on your verification list too.

Critical security updates arrive by mailing list, not through the release feed

The README asks anyone deploying Mattermost to subscribe to the Mattermost Security Bulletin mailing list, on the stated grounds that attacker sophistication keeps increasing. That single recommendation describes the whole security posture of a self-hosted install: you do not find out about a critical fix from the platform, you subscribe to a channel and read it.

The repository carries SECURITY.md and a CHANGELOG.md at the top level, and those are files on a disk rather than a push notification. Combined with a new compiled version on the 16th of every month, the operating rhythm is clear: something lands monthly, sometimes the monthly build contains a security fix, and the mailing list is what tells you which months those were. An operator tracking only the tags they pull will upgrade on schedule and learn what changed from the changelog afterwards.

The subscription is cheap and the alternative is worse, because an unpatched collaboration server holds the channel history your incident discussions happen in. What the README does not give you is a way to automate the check: no endpoint, no feed format and no version-to-advisory mapping is described, so the gap between the mailing list and your change management process is a place a human has to live. Build that step before you go live rather than at the first bulletin that matters.

Self-hosted Mattermost against a hosted Slack workspace

The README does not draw this comparison, so here is the practical shape of it. A hosted Slack workspace gives you a service someone else runs, with its own plans and its own feature set, and your involvement ends at signing up. Mattermost, as described here, is a single Linux binary you run against your own PostgreSQL, with the client applications as separate downloads. The difference is not the chat interface; it is who is on call when the database fills up.

That trade buys you specific things. Your message history lives in a database on infrastructure you control, which is the reason organisations with data residency requirements or air-gapped networks take this path at all. Workflow automation, voice calling and screen sharing sit on the same self-hosted instance rather than depending on a third-party service being reachable. The integration mechanisms, webhooks, slash commands, Apps and plugins, run against your own deployment instead of someone else's.

What it costs is everything in the previous sections at once: a PostgreSQL instance to run, a monthly patch decision, a licence boundary to read, a release train to choose from, and a security mailing list to read yourself. For a team that already runs infrastructure and has a reason to keep its own, that is a reasonable bill. For anyone who just wants a channel to talk in, the hosted path is the cheaper decision, and nothing in the project argues otherwise.

Editorial conclusion

Adopt Mattermost if your organisation needs messaging, incident collaboration and workflow automation on servers you administer, and you are prepared to own PostgreSQL, patching and backups yourself. Do not adopt it if you want a hosted team chat with no infrastructure, because the platform exists to be run by you. Verify first by reading LICENSE.txt next to LICENSE.enterprise to establish which features the MIT release actually covers, then decide between the current stable line and the 12.0.0 release candidates before you schedule the first upgrade.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes