What will be deprecated in Mattermost v12.0? (October 2026)

Mattermost v12.0 will ship in October 2026 with several deprecations, plus a handful of smaller breaking changes, that self-hosted admins, integration authors, and plugin developers should plan for.

RHEL 7 and RHEL 8 will no longer be supported deployment targets

Mattermost binaries link against the system glibc, and we’ve been building against Debian Bullseye specifically to stay compatible with RHEL 7 (glibc 2.17) and RHEL 8 (glibc 2.28). Bullseye reaches end-of-life in August 2026, so we’ll be moving to the official Go build image based on Debian Bookworm, which ships glibc 2.36. RHEL 9, Ubuntu 22.04/24.04 LTS, Debian Bookworm, and containers will all remain fully supported; only the RHEL 7 and 8 lines are affected. v11.11 (September 2026) will be the last release to support them, and from v12.0 the binaries will require glibc 2.34 or newer.

Upgrade in place to RHEL 9, move to another supported distribution, or switch to the official Docker image, which runs on any Linux host regardless of the host’s glibc. See the forum post for more details.

OpenSearch 1.x will no longer be a supported search backend

OpenSearch 1.x has reached end-of-life, and supporting it means maintaining compatibility shims for an API surface that has meaningfully diverged from 2.x. We’ll be setting a minimum of OpenSearch 2.x, stable and widely adopted since 2022. OpenSearch 2.x and 3.x and Elasticsearch 8.x/9.x will remain fully supported. On v12.0 with 1.x, the server will refuse to activate the search backend and will log OpenSearch version 1 is lower than min supported version of 2.

Use OpenSearch’s in-place upgrade path to 2.x, upgrade your managed domain through your provider’s console, or move to Elasticsearch. v11 releases will continue to work with 1.x while you plan. See the forum post for more details.

atmos/camo will no longer be supported as an image proxy

The atmos/camo project has been archived and is no longer maintained, so v12.0 will drop support for it. This one will have a harder failure mode than the others: if ImageProxySettings.ImageProxyType is still set to atmos/camo, the server will log a configuration error on startup and fail to start, and the RemoteImageProxyURL and RemoteImageProxyOptions settings will be removed and ignored.

Update your configuration before upgrading. Either set ImageProxySettings.ImageProxyType to local to use the built-in proxy, which needs no external service and adds SVG content blocking plus security response headers, or set ImageProxySettings.Enable to false if you don’t need proxying. See the forum post for more details.

The web and desktop apps will be built on React 19

v12.0 will be the first release built on React 19, which keeps us on a supported version of our core UI framework and unlocks concurrent rendering. This will only affect plugins that register web app components; server-only plugins will need no changes. The key detail: web app plugins use the React version the web app provides rather than bundling their own, so your components will render under React 19 whether or not you rebuild. Plugins calling removed APIs (ReactDOM.findDOMNode, propTypes/defaultProps on function components, legacy Context, string refs) or relying on legacy synchronous rendering may break.

Run npx codemod@latest run react-19-migration-recipe, fix what it surfaces, and test against a v12.0 release candidate during the beta window. See the forum post for more details.

The mobile app will require iOS 17 or later

Separately from the server version requirement above, Mobile App v2.45 (October 2026) will raise the minimum supported iOS version to v17. Devices on iOS 16 or earlier will stop receiving new versions of the app from the App Store; the installed version will keep working but will no longer get updates, including security fixes.

Users should update to iOS 17 or newer before v2.45 ships. See the forum post for more details.

User and PAT sessions will no longer be able to set post identity or display-override props

For years some deployments have used a known workaround: a regular user session or personal access token forges integration props like from_webhook alongside override_username and override_icon_url, so posts appear under a custom name and icon. That pattern is indistinguishable from impersonation, since the channel UI, thread lists, push notifications, and post previews all honor those props once stored.

From v12.0 the server will strip from_webhook, from_bot, from_oauth_app, from_plugin, override_username, override_icon_url, override_icon_emoji, and webhook_display_name from client and PAT payloads, re-applying them only under verified integration authority. Note the failure mode: the post will still be created and no error will be returned. The forged props will be silently dropped and the message will appear as the authenticating user. Legitimate paths will be unaffected: incoming webhooks and slash commands will still be able to override username and icon when enabled in the System Console, bots will post as the bot account, from_* markers will still be set server-side for OAuth apps and plugins, and remote identity props will be preserved across Shared Channels sync.

If you rely on PAT forging today, migrate those scripts to an incoming webhook or a bot account before upgrading. See the forum post for more details.

Deprecated interactive dialog date and time fields will be removed

v12.0 will remove the deprecated date/datetime field options in interactive dialogs. The top-level min_date, max_date, and time_interval keys, along with datetime_config.allow_manual_time_entry, will no longer be accepted. Use datetime_config (with manual_time_entry) instead. As with the identity props above, the legacy keys will be silently ignored rather than raising an error, so update any integration that still sends them before upgrading.

Other v12 breaking changes

Alongside the deprecations above, v12.0 will include a set of smaller breaking changes. Most deployments won’t notice them, but they’re worth a scan:

• Stricter server config validation. Config values that are currently tolerated but unusable will be rejected, and the server will fail to start rather than run in a misconfigured state. This will cover export, SQL replica monitor, feature flag sync, burn-on-read, LDAP, Elasticsearch index sizing, connected workspace batches, email, sessions, data retention, TLS, and webserver settings. Validate your config.json against a v12.0 release candidate before upgrading.
• Deprecated Slack compatibility aliases will be removed. SlackAttachment, SlackAttachmentField, ParseSlackAttachment, and StringifySlackFieldValue will be removed from the Go model package. Use the MessageAttachment equivalents instead. This will affect Go plugins only; the payload format will be unchanged.
• The logs query API will reject malformed date filters. POST /api/v4/logs/query currently accepts date_from and date_to values it cannot parse, silently drops the filter, and returns HTTP 200 with unfiltered results. From v12.0 a non-empty value that fails to parse with the layout 2006-01-02 15:04:05.999 -07:00 will return HTTP 400 naming the offending field. Empty values will continue to mean “unbounded”.
• Channel member endpoints will omit sanitized timestamps instead of returning -1. For other users’ memberships, last_viewed_at and last_update_at are currently sanitized to a -1 sentinel, which clients decode as December 31, 1969. From v12.0 those fields will be omitted from the response entirely. This affects GET /channels/{channel_id}/members, GET /channels/{channel_id}/members/{user_id}, POST /channels/{channel_id}/members/ids, POST /channels/{channel_id}/members, GET /users/{user_id}/teams/{team_id}/channels/members, and GET /users/{user_id}/channel_members. The requester’s own memberships will be unaffected and will continue to return real values, including a legitimate 0 meaning “never viewed”. Scripts that read the -1 sentinel, or that assume the fields are always present, will need updating.
• Separately, eleven configuration settings that no longer affect server behavior will be removed. Leftover entries in config.json will be ignored rather than rejected, so no action is needed; see the Deprecated features documentation for the list.

Planning your upgrade

Configuration changes can be made well ahead of the upgrade; infrastructure work (OS and search backend migrations, and especially MySQL to PostgreSQL) needs the most lead time. The full list of upcoming and past deprecations lives in the Deprecated features documentation. If you’re unsure how any of this affects your deployment, reach out to your Customer Success contact.

Other upcoming breaking changes

Starting in v11.7.10 ESR, v11.10.1 and v11.11.0, FIPS builds will require a PostgreSQL password of at least 14 characters. The updated glibc-openssl-fips bundle includes an OpenSSL build that enforces the FIPS minimum key length of 112 bits for HMAC operations. The PostgreSQL driver passes the database password during SCRAM authentication, so a password shorter than 112 bits (14 ASCII characters) will cause the server to panic on connect rather than fail gracefully. Before upgrading, FIPS deployments should confirm the password in SqlSettings.DataSource is at least 14 characters and rotate it in PostgreSQL if not. Standard, non-FIPS builds are unaffected.

Boards has been sending the Desktop App navigation paths that include the server subpath, unlike the core web app, which sends subpath-relative paths. To compensate, the Desktop App will strip the subpath back out, a workaround that misfires when a team name matches the subpath (a team named foo on a server hosted at /foo, say) and produces a “Team not found” error. Boards will send subpath-relative paths like the web app, so Desktop App v6.4, shipping November 2026, will remove the cleanup logic. The pairing matters in one direction only: the Boards fix is safe with every Desktop App version, but Desktop v6.4 running against an older Boards may fail to navigate.

Only deployments with a subpath in their Site URL are affected. If you run one, update Boards to v9.4.0 or later before rolling out Desktop v6.4; Boards is a Marketplace plugin, so no server upgrade is needed. See the forum post for more details.