snapshot of https://github.com/mattermost/mattermost.git (master, 2026-09-16; blobs > 131072B omitted)
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Deploy in Air-Gapped Environments"
|
||||
---
|
||||
## Overview
|
||||
|
||||
An air-gapped environment is one that's physically or logically isolated from the public internet. Nothing inside it can reach an external package repository, container registry, app store, or SaaS API, and nothing outside it can initiate a connection in. Mattermost is deployed and operated entirely from resources that already exist inside the boundary.
|
||||
|
||||
Organizations adopt this pattern when regulation or classification makes an internet connection unacceptable rather than merely undesirable — classified and cross-domain networks, defense and intelligence programs, and industrial or operational-technology networks where the collaboration platform must sit on the same isolated segment as the systems it supports.
|
||||
|
||||
<Note>
|
||||
|
||||
Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs support deploying Mattermost and supporting services in an air-gapped environment.
|
||||
|
||||
</Note>
|
||||
|
||||
## How it differs from a connected deployment
|
||||
|
||||
The Mattermost server itself is the same product, deployed with the same [Linux](/deployment-guide/server/deploy-linux), [Kubernetes](/deployment-guide/server/deploy-kubernetes), or [container](/deployment-guide/server/deploy-containers) methods used anywhere else. What changes is everything around it:
|
||||
|
||||
- **Nothing is fetched at install time.** Packages, container images, Helm charts, plugin binaries, and desktop app installers must all be gathered on an internet-connected machine, staged into a private package mirror or container registry, and transferred across the air gap on approved media before the install begins.
|
||||
- **Upgrades are a planned transfer, not a download.** Because each upgrade repeats that staging and transfer cycle, air-gapped deployments commonly track an [Extended Support Release](/product-overview/release-policy#extended-support-releases) rather than the monthly cadence.
|
||||
- **Client apps are side-loaded.** Air-gapped devices can't reach the public app stores, so desktop and mobile apps are distributed through your own [desktop](/deployment-guide/desktop/desktop-app-deployment) and [mobile](/deployment-guide/mobile/mobile-app-deployment) deployment tooling.
|
||||
- **Documentation travels with the deployment.** Administrators inside the boundary can't reach docs.mattermost.com, so the documentation is built and served locally.
|
||||
|
||||
## Constraints to plan for
|
||||
|
||||
Several Mattermost capabilities depend on an outbound internet connection and are unavailable or must be replaced:
|
||||
|
||||
- **Mobile push notifications** rely on the hosted push notification service. Either disable push notifications or run your own [push proxy](/deployment-guide/mobile/host-your-own-push-proxy-service) reachable from the isolated network.
|
||||
- **The Mattermost Marketplace** is unreachable, so plugins are downloaded in advance and uploaded through the System Console.
|
||||
- **Website link previews and the GIF picker** call third-party services and should be disabled.
|
||||
- **In-product notices and telemetry** phone home, generate log errors when they can't, and should be turned off.
|
||||
- **Email** requires an internal SMTP relay inside the boundary, or email invitations and verification must be disabled.
|
||||
- **AI agents** must run against a [self-hosted, OpenAI-compatible LLM](/administration-guide/configure/agents-admin-guide) rather than a hosted model provider.
|
||||
|
||||
## Deploy an air-gapped environment
|
||||
|
||||
[Air-Gapped Operations](/deployment-guide/air-gapped-operations/) covers the full procedure: the step-by-step deployment runbook, the bill of materials to gather before you cross the air gap, how to stand up a private package mirror or container registry, and the server settings to change once Mattermost is running.
|
||||
|
||||
## Related deployment scenarios
|
||||
|
||||
- [Enterprise to Edge DDIL Operations](/deployment-guide/deployment-scenarios/deploy-ddil-operations) — for networks that are intermittently rather than permanently disconnected.
|
||||
- [Out-of-Band Communications](/deployment-guide/deployment-scenarios/deploy-oob) — for an isolated, pre-provisioned system used during incident response.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: "Deploy for Enterprise to Edge DDIL Operations"
|
||||
---
|
||||
## Overview
|
||||
|
||||
Disconnected, Denied, Intermittent, and Limited (DDIL) network conditions present unique challenges for enterprise-to-edge operations. Field operations, remote deployments, and edge environments often become temporarily isolated from the internet, interrupting direct access to Microsoft 365 services such as Teams and Outlook.
|
||||
|
||||
Mattermost enables resilient collaboration by remaining fully operational in DDIL environments. Mission users continue to access self-hosted messaging collaboration, workflow automation, and mission planning within their mobile tactical network. No internet connectivity is required for enhanced collaboration functions, including mission tuned AI agents powered by self-hosted LLMs, and audio and screen sharing services.
|
||||
|
||||
When connectivity is restored, mission users regain access to M365 enterprise systems in addition to collaboration continuity with enterprise users through the [embedded Mattermost experience](/integrations-guide/mattermost-mission-collaboration-for-m365) inside their Microsoft Teams and Outlook applications. All mission activity during the period of disconnection becomes available across enterprise and tactical environments when connectivity returns.
|
||||
|
||||
Traditional cloud-only solutions fail in these scenarios, while fully disconnected systems don't integrate with enterprise tools during normal operations. This deployment architecture [extends sovereign collaboration with Microsoft Teams and Outlook](/deployment-guide/deployment-scenarios/deploy-sovereign-collaboration) to the tactical edge, providing a hybrid solution that enables enterprise integration and fully disconnected tactical collaboration.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
|
||||
Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs support deploying Mattermost and supporting services for DDIL operations.
|
||||
|
||||
</Note>
|
||||
|
||||
## Architecture components
|
||||
|
||||
This hybrid deployment architecture provides optimal collaboration in both connected and disconnected states, including:
|
||||
|
||||
- **Enterprise Network:** Network containing enterprise services and continuous access to Microsoft 365. The network may have a firewall or access gateway protecting egress and ingress, such as network policies, IP allowlists, or WAFs depending on your networking configurations.
|
||||
- **Enterprise Users:** Users within the enterprise network boundary accessing client applications for M365 services and Mattermost.
|
||||
- **Tactical Network:** Operates independently during internet disconnections, hosting a self-contained Mattermost deployment to ensure mission users maintain collaboration capabilities.
|
||||
- **Mission Users:** Tactical or edge users who may be intermittently disconnected from enterprise systems and Microsoft services.
|
||||
- **Identity Providers:**
|
||||
- **Microsoft Entra ID:** Enterprise users authenticate to M365 applications and Mattermost using [single sign-on Entra ID](/administration-guide/onboard/sso-entraid) via OpenID Connect (OIDC) or SAML. This provider only works with functioning internet access.
|
||||
- **Alternative Local Identity Provider:** Deployed within the tactical network to provide authentication services for mission users during disconnected periods when M365 is unreachable. The local IdP serves as the primary authentication source for Mattermost and maintains an independent user directory that operates without internet connectivity.
|
||||
- **Client Applications:**
|
||||
- **Microsoft 365 Desktop Apps:** Teams and Outlook with [embedded Mattermost application.](/integrations-guide/mattermost-mission-collaboration-for-m365)
|
||||
- When internet connected: Enables seamless enterprise-to-edge collaboration within a familiar interface.
|
||||
- When internet disconnected: Microsoft services are unreachable, but embedded Mattermost application remains fully operational for tactical teams.
|
||||
- **Mattermost Desktop Apps:** Access Mattermost via [desktop](/deployment-guide/desktop/desktop-app-deployment) or web apps in addition to the embedded views from Teams and Outlook. *(Optional - not shown)*
|
||||
- **Mattermost Mobile Apps:** Access Mattermost via [iPhone and Android apps](/deployment-guide/mobile/mobile-app-deployment), with support for [ID-only push notifications](/deployment-guide/mobile/host-your-own-push-proxy-service) to ensure compliance with data sovereignty requirements. *(Optional when connectivity permits - not shown)*
|
||||
- **Mattermost Deployment:** Mattermost deployed for sovereign tactical collaboration on local infrastructure, such as [Azure Local](https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview), supporting data residency regulations and [disconnected operations](/deployment-guide/deployment-scenarios/air-gapped-deployment). See [reference architecture](/deployment-guide/scale/server-architecture) documentation for Mattermost deployment configurations based on expected scale.
|
||||
- **Mattermost Server:** Core application server handling tactical collaboration workloads, including:
|
||||
- [Messaging Collaboration](/end-user-guide/collaborate/collaborate-index): DDIL-ready 1:1, group messaging, and structured channel collaboration with [rich integration capabilities](/integrations-guide/integrations-guide-index) and [enterprise-grade search](/deployment-guide/scale/scaling-for-enterprise#enterprise-search).
|
||||
- [Workflow Automation](/end-user-guide/workflow-automation/workflow-automation-index): Playbooks provide structure, monitoring and automation for repeatable processes built-in to your local Mattermost deployment.
|
||||
- [Project Tracking](/end-user-guide/project-management/project-management-index): Boards enables project management capabilities built-in to your local Mattermost deployment.
|
||||
- [AI Agents](/administration-guide/configure/agents-admin-guide): AI Agents run against a local LLM hosted within your tactical network.
|
||||
- [Audio & Screenshare](/deployment-guide/calls/calls-deployment-guide): Calls offers native real-time self-hosted audio calls and screen sharing within your tactical network.
|
||||
- **Proxy Server:** The [proxy server](/deployment-guide/server/setup-nginx-proxy) handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services. NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers.
|
||||
- **PostgreSQL Database:** Stores persistent application data on a [PostgreSQL v13+ database](/deployment-guide/server/prepare-database) hosted locally within your tactical network.
|
||||
- **Object Storage:** File uploads, images, and attachments are stored outside the application node on an [S3-compatible store](/deployment-guide/server/prepare-file-storage) or network/local storage, hosted locally within your tactical network.
|
||||
- **Recording Instance:** `calls-offloader` job service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, to offload heavy processing tasks from Mattermost Calls to self-hosted infrastructure within your tactical network, such as recordings, transcriptions, and live captioning. *(Optional)*
|
||||
- **Self-hosted integrations:** [Custom apps, plugins, and webhooks](/integrations-guide/integrations-guide-index) can be deployed within your tactical network. *(Optional - not shown)*
|
||||
- **Self-hosted LLM:** Locally hosted [OpenAI compatible LLM](/agents/docs/providers) for agentic powered collaboration within your tactical network. *(Optional)*
|
||||
- **Microsoft Global Network:** [World-wide network](https://learn.microsoft.com/en-us/azure/networking/microsoft-global-network) of Microsoft data centers, delivering public cloud services when internet connectivity permits.
|
||||
|
||||
## Operational Best Practices
|
||||
|
||||
The following best practices and deployment configurations help ensure that Mattermost remains compliant and operationally resilient in contested environments.
|
||||
|
||||
### User Authentication
|
||||
|
||||
DDIL environments require authentication infrastructure that remains fully operational without internet connectivity. Relying solely on cloud-based identity providers like Microsoft Entra ID creates a critical single point of failure when tactical networks become disconnected. To ensure mission users maintain authentication capabilities, deploy a locally hosted identity provider within the tactical network.
|
||||
|
||||
- **Enterprise Users:** Access Teams and Outlook by authenticating to Microsoft 365 via Entra ID, and their M365 session also provides access to the embedded Mattermost experience when the tactical network is internet connected.
|
||||
- **Mission users:** Authenticate to Mattermost using a local IdP, such as [Keycloak](/administration-guide/onboard/sso-saml-keycloak) (open-source IdP with OIDC/SAML support), Active Directory with ADFS, or OpenLDAP with an OIDC bridge. When internet connected, the local IdP can optionally federate with Microsoft Entra ID to synchronize user accounts, credentials, and group memberships to enable access to Microsoft applications.
|
||||
|
||||
User accounts must be provisioned in the local IdP before disconnection occurs to ensure authentication services remain available throughout DDIL conditions.
|
||||
|
||||
### Sovereign AI
|
||||
|
||||
Deploy an [OpenAI compatible LLM](/administration-guide/configure/agents-admin-guide) on tactical infrastructure to ensure AI capabilities remain fully sovereign and operational in disconnected scenarios. A self-hosted LLM can power [message and call summarization, semantic search](/end-user-guide/agents#analyze-threads-and-channels), and [mission-tuned AI agents](/administration-guide/configure/agents-admin-guide#agent-configuration) without relying on public cloud AI services. This guarantees compliance with strict data handling mandates and enables AI-enhanced workflows to function locally, even during extended disconnections.
|
||||
|
||||
### Self-hosted audio & screensharing
|
||||
|
||||
Effective collaboration at the tactical edge requires all voice and screen sharing capabilities remain operational without reliance on the internet or third-party services. Deploy [Mattermost Calls](/deployment-guide/calls/calls-deployment-guide) in a self-hosted configuration, including:
|
||||
|
||||
- The `rtcd` service, configured using the [RTCD Setup and Configuration](/deployment-guide/calls/calls-rtcd-setup) guide, provides scalable, low-latency media routing hosted on-premises. Run multiple `rtcd` nodes for redundancy.
|
||||
- The `calls-offloader` service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, offloads heavy processing tasks like recording, transcription and live captioning to a locally hosted compliance-approved job server.
|
||||
|
||||
### High availability and fault tolerance
|
||||
|
||||
Deploy Mattermost in a [cluster-based architecture](/deployment-guide/server/high-availability-cluster-based-deployment) to ensure continued availability during outages or hardware failures. High availability requires redundant infrastructure across each critical component:
|
||||
|
||||
- Application servers: Scale horizontally across multiple nodes with a load balancer distributing client traffic.
|
||||
- Search service: [Elasticsearch or AWS OpenSearch Service](/deployment-guide/scale/scaling-for-enterprise#enterprise-search) provides optimized search performance with dedicated indexing for large-scale deployments.
|
||||
- Object storage: Configure S3-compatible backends with erasure coding or replication for durability. All application servers must access shared file storage (NAS or S3) to ensure consistent data availability.
|
||||
- Calls services: Run multiple `rtcd` and offloader nodes for resilience.
|
||||
|
||||
### Compliance and retention
|
||||
|
||||
Sovereign environments often require strict enforcement of retention policies, legal hold, and export controls. Configure Mattermost's built-in compliance features to meet organizational mandates.
|
||||
|
||||
- Enable [compliance export](/administration-guide/comply/compliance-export) and [monitoring](/administration-guide/comply/compliance-monitoring) to produce auditable exports of message data and user activity logs.
|
||||
- Configure [message retention](/administration-guide/comply/data-retention-policy) and [legal hold](/administration-guide/comply/legal-hold) policies to align with applicable regulations.
|
||||
- Integrate with your organization's [eDiscovery](/administration-guide/comply/electronic-discovery) and archiving systems as required.
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: "Deploy for Mission Partner Collaboration"
|
||||
---
|
||||
## Overview
|
||||
|
||||
Mission partner collaboration extends [sovereign collaboration](/deployment-guide/deployment-scenarios/deploy-sovereign-collaboration) and [edge deployment](/deployment-guide/deployment-scenarios/deploy-ddil-operations) models to enable joint and allied operations across organizations using Mattermost, Microsoft 365 and legacy platforms. The solution architecture outlined in this document delivers a secure, sovereign, and intelligent mission environment that is federated across enterprise and coalition partner networks, enabling interoperability while maintaining compliance and control.
|
||||
|
||||
Joint mission collaboration is achieved through federation using [connected workspaces](/administration-guide/onboard/connected-workspaces), [Matrix connectors](https://mattermost.com/marketplace/mattermost-matrix-connector/), [guest accounts](/administration-guide/onboard/guest-accounts), and [auto-translation](https://github.com/mattermost/mattermost-plugin-channel-translations) for fast, accurate comprehension across globally distributed teams. Additionally, integrating external data feeds, workflow automation, and sovereign AI enables allied and partner users to collaborate at mission speed while enforcing zero-trust policies and maintaining data sovereignty.
|
||||
|
||||
Mattermost deployments may be hosted on-premises or in sovereign clouds, enabling allies and partners to retain control over sensitive data while extending interoperability to coalition partner enterprise networks.
|
||||
|
||||
## Collaboration challenges
|
||||
|
||||
Multi-agency collaborations face complex communication challenges:
|
||||
|
||||
- **Platform diversity:** Organizations often use different platforms, including Microsoft 365, Mattermost, and Matrix - with some using Teams for enterprise productivity [supplemented with Mattermost](/deployment-guide/deployment-scenarios/deploy-sovereign-collaboration) for sovereign collaboration, data residency, and offline resilience.
|
||||
- **External access:** External partners need controlled access without full organizational membership.
|
||||
- **Language barriers:** Organizations may speak different languages.
|
||||
- **Compliance:** Data residency and compliance requirements vary across organizations.
|
||||
|
||||
## Solution Architecture
|
||||
|
||||
Traditional solutions require everyone to adopt the same platform or use insecure external tools. Mattermost powers a multi-layer approach addressing these collaboration challenges and diverse organizational needs, including:
|
||||
|
||||
- **Mattermost ↔ Mattermost Collaboration:** Organizations with Mattermost deployments establish secure connections and share specific channels using [connected workspaces](/administration-guide/onboard/connected-workspaces) over standard HTTPS/VPN.
|
||||
- **External users ↔ Mattermost Collaboration:** Users from external organizations receive Mattermost [guest accounts](/administration-guide/onboard/guest-accounts) with least-privilege access. External users in Microsoft environments may access Mattermost using the [embedded application](/integrations-guide/mattermost-mission-collaboration-for-m365) in their Teams and Outlook clients.
|
||||
- **Matrix / XMPP ↔ Mattermost Collaboration:** Organizations using legacy XMPP systems or Matrix servers connect to Mattermost via the [Matrix bridge plugin](https://github.com/mattermost/mattermost-plugin-matrix-bridge) for bidirectional communication.
|
||||
- **Automatic Language Translation:** The AI-powered [automatic translation plugin](https://github.com/mattermost/mattermost-plugin-channel-translations) enables seamless communication across language barriers in channels with distributed teams.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
|
||||
Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs support deploying Mattermost and supporting services for mission partner collaboration.
|
||||
|
||||
</Note>
|
||||
|
||||
## Architecture components
|
||||
|
||||
The deployment architecture includes the following components:
|
||||
|
||||
- **Allied or Partner Networks:** Globally distributed and segregated networks for each allied or partner organization.
|
||||
- Networks may have a firewall or access gateway protecting egress and ingress, such as network policies, IP allowlists, or WAFs depending on networking configurations.
|
||||
- Networks may [operate in contested environments](/deployment-guide/deployment-scenarios/deploy-ddil-operations) where internet connectivity is intermittent.
|
||||
- **Users:** Enterprise, allied, and coalition partner users accessing client applications for Mattermost and/or Microsoft 365.
|
||||
- **Microsoft Entra ID (Identity Provider):** Partnered organizations using Microsoft 365 services may use [single sign-on Entra ID](/administration-guide/onboard/sso-entraid) for unified authentication to M365 and Mattermost applications. *(Optional)*
|
||||
- **Federation Services:**
|
||||
- **Connected workspaces:** [Federated collaboration](/administration-guide/onboard/connected-workspaces) across partner networks, with seamless synchronization of messages, threads, and files.
|
||||
- **Guest Accounts:** [Secure participation](/administration-guide/onboard/guest-accounts) of external mission partners with least-privilege access. *(Optional)*
|
||||
- **Matrix & XMPP Interoperability:** [Federation with legacy partner systems](https://github.com/mattermost/mattermost-plugin-matrix-bridge) for cross-domain coalition collaboration. *(Optional)*
|
||||
- **Client Applications:**
|
||||
- **Mattermost Desktop Apps:** Access Mattermost directly by deploying [desktop](/deployment-guide/desktop/desktop-app-deployment) or web apps in your organization.
|
||||
- **Mattermost Mobile Apps:** Access Mattermost via [iPhone and Android apps](/deployment-guide/mobile/mobile-app-deployment), with support for [ID-only push notifications](/deployment-guide/mobile/host-your-own-push-proxy-service) to ensure compliance with data sovereignty requirements. *(Optional - not shown)*
|
||||
- **Microsoft 365 Desktop Apps:** For partnered organizations using Microsoft 365 services, Teams and Outlook can be deployed with the [embedded Mattermost application](/integrations-guide/mattermost-mission-collaboration-for-m365) for cross-domain partner collaboration within a familiar interface. *(Optional)*
|
||||
- **Mattermost Deployments:** Mattermost deployed for sovereign collaboration on private cloud or local infrastructure, such as [Azure](/deployment-guide/server/deploy-kubernetes) or [Azure Local](https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview), to maintain compliance with STIG, FedRAMP, and NIST 800-53 standards. See [reference architecture](/deployment-guide/scale/server-architecture) documentation for Mattermost deployment configurations based on expected scale.
|
||||
- **Mattermost Server:** Core application server handling collaboration workloads, including:
|
||||
- [Messaging Collaboration](/end-user-guide/collaborate/collaborate-index): Sovereign 1:1, group messaging, and structured channel collaboration.
|
||||
- [Workflow Automation](/end-user-guide/workflow-automation/workflow-automation-index): Playbooks provide structure, monitoring and automation for repeatable processes built-in to your sovereign Mattermost deployment.
|
||||
- [Project Tracking](/end-user-guide/project-management/project-management-index): Boards enables project management capabilities built-in to your local Mattermost deployment. Boards enables project management capabilities built-in to your sovereign Mattermost deployment.
|
||||
- [AI Agents](/administration-guide/configure/agents-admin-guide): AI Agents run against Azure OpenAI endpoints or a self-hosted LLM that is OpenAI-compatible.
|
||||
- [Audio & Screenshare](/deployment-guide/calls/calls-deployment-guide): Calls offers native real-time self-hosted audio calls and screen sharing within your own network.
|
||||
- **Proxy Server:** The [proxy server](/deployment-guide/server/setup-nginx-proxy) handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services, including requests from users in [connected organizations](/administration-guide/onboard/connected-workspaces). NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers.
|
||||
- **PostgreSQL Database:** Stores persistent application data on a [PostgreSQL v13+ database](/deployment-guide/server/prepare-database), such as [Azure Database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql).
|
||||
- **Object Storage:** File uploads, images, and attachments are stored outside the application node on an [S3-compatible store](/deployment-guide/server/prepare-file-storage) or an NFS (Network File System) server. [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) can be used, but needs an S3-compatible proxy for Mattermost to interface with.
|
||||
- **Recording Instance:** `calls-offloader` job service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to local infrastructure or private cloud. *(Optional)*
|
||||
- **Integration framework:** [Custom apps, plugins, and webhooks](/integrations-guide/integrations-guide-index) can be deployed for real-time data integrations and alerting. *(Optional - not shown)*
|
||||
- **Self-hosted LLM:** Locally hosted [OpenAI compatible LLM](/agents/docs/providers) for agentic powered collaboration. *(Optional)*
|
||||
- **Microsoft Global Network:** [World-wide network](https://learn.microsoft.com/en-us/azure/networking/microsoft-global-network) of Microsoft data centers, delivering public cloud services including M365 and Azure OpenAI. *(Optional)*
|
||||
|
||||
## Operational Best Practices
|
||||
|
||||
The following best practices and deployment configurations help ensure that Mattermost remains secure, resilient, and interoperable across federated mission partner environments.
|
||||
|
||||
### Network Configuration
|
||||
|
||||
When external access is enabled through various federation capabilities, it is recommended to deploy Mattermost in a DMZ rather than on the internal network. This approach provides defense-in-depth and preserves security boundaries by isolating each connected server deployment from the enterprise network.
|
||||
|
||||
- **DMZ Deployment:** Position Mattermost application servers in the DMZ network segment, allowing both internal users and external partner federation traffic to access the collaboration platform through controlled network boundaries.
|
||||
- **VPN Termination:** Terminate site-to-site VPN connections at the network perimeter or DMZ layer, enabling encrypted partner connectivity without exposing internal network infrastructure. VPN tunnels establish secure communication channels between partner organizations over the internet.
|
||||
- **Firewall Segmentation:** Deploy ingress and egress firewall rules to control traffic flow between the DMZ, internal network, and external partner networks. Restrict database and object storage access to only originate from the DMZ segment where Mattermost servers reside.
|
||||
- **Federation Traffic Isolation:** Partner federation traffic (Connected workspaces synchronize over HTTPS port 443/TCP) remains isolated within the DMZ, protecting internal systems while enabling partner collaboration and enforcing zero-trust principles across organizational boundaries.
|
||||
|
||||
### Resilient federation for joint operations
|
||||
|
||||
[Connected workspaces](/administration-guide/onboard/connected-workspaces) allow federated collaboration across multiple organizations and networks while maintaining local data control of each Mattermost deployment. Messages, threads, and files are securely synchronized between environments, ensuring mission continuity for multinational operations without requiring partners to join a single centralized deployment.
|
||||
|
||||
- Enforce [zero-trust access](/administration-guide/onboard/connected-workspaces#create-a-secure-connection) and ensure that only authorized mission partners can view or contribute to shared collaboration channels.
|
||||
- Configure [auto-translation](https://github.com/mattermost/mattermost-plugin-channel-translations) in shared channels for seamless multilingual cross-domain collaboration.
|
||||
- Mattermost instances can operate independently during outages or intermittent connectivity and sync conversations once connectivity returns.
|
||||
|
||||
Many mission partners continue to operate on legacy systems such as Matrix and XMPP. To enable joint operations without forcing migration, Mattermost supports [secure interoperability](https://github.com/mattermost/mattermost-plugin-matrix-bridge) with these environments for continuity of coalition communications while allowing modernized workflows to extend across federated networks.
|
||||
|
||||
Synchronize Mattermost channels with Matrix or XMPP rooms, allowing messages, threads, and attachments to flow across systems in real-time. Each organization maintains control of its data and infrastructure, while interoperability is enabled through federation bridges rather than centralized services.
|
||||
|
||||
### Controlled external access
|
||||
|
||||
Mission partner collaboration may require involving external users such as allied forces, contractors, or coalition partners that do not have Mattermost deployments themselves. [Guest accounts](/administration-guide/onboard/guest-accounts) provide a controlled mechanism to enable these users to participate in joint mission operations while maintaining strict compliance and security boundaries.
|
||||
|
||||
- Guest accounts are restricted to specific teams and channels. This ensures external users only have access to mission-critical resources necessary for their role.
|
||||
- Guests can be granted access to shared channels, enabling collaboration with additional trusted organizations through [connected workspaces](/administration-guide/onboard/connected-workspaces).
|
||||
- Guest users can be provided VPN credentials that allow them to connect specifically to the DMZ network segment where Mattermost resides. This architecture ensures external guests can access the collaboration platform without gaining access to internal corporate resources, files, or systems.
|
||||
|
||||
### Zero-trust access controls
|
||||
|
||||
Mission partner collaboration environments should adopt zero-trust principles by implementing [attribute-based access control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) to ensure access to mission channels is governed by dynamic attributes such as role, clearance, location, and mission context.
|
||||
|
||||
- Restrict channel access based on [user attributes](/administration-guide/manage/admin/user-attributes) rather than static groups.
|
||||
- Continuously audit ABAC policies to ensure compliance with multinational operational and legal requirements.
|
||||
|
||||
### Sovereign AI
|
||||
|
||||
AI capabilities enhance mission collaboration with summarization, translation, semantic search, and decision support. Sovereign AI ensures these capabilities remain fully under organizational control, without reliance on public cloud services or external data processing. Deploying AI in a self-hosted or compliance-approved environment enables secure, mission-ready augmentation.
|
||||
|
||||
- Deploy [OpenAI compatible language models](/administration-guide/configure/agents-admin-guide) on local or private cloud infrastructure to maintain data sovereignty and ensure offline availability.
|
||||
- Configure [custom agents](/administration-guide/configure/agents-admin-guide#agent-configuration) for summarization, workflow automation, and decision support while enforcing organizational compliance policies.
|
||||
- Enable multilingual collaboration in shared channels using sovereign AI services to provide [real-time translations](https://github.com/mattermost/mattermost-plugin-channel-translations) across partner organizations.
|
||||
- Embed AI into operational playbooks for automated task execution, situational summaries, and proactive recommendations.
|
||||
- Allow authorized users from partner organizations to securely access locally hosted LLMs through shared channels in [connected workspaces](/administration-guide/onboard/connected-workspaces).
|
||||
|
||||
### High availability and fault tolerance
|
||||
|
||||
Deploy Mattermost in a [cluster-based architecture](/deployment-guide/server/high-availability-cluster-based-deployment) to ensure continued availability during outages or hardware failures. High availability requires redundant infrastructure across each critical component:
|
||||
|
||||
- Application servers: Scale horizontally across multiple nodes with a load balancer distributing client traffic.
|
||||
- Search service: [Elasticsearch or AWS OpenSearch Service](/deployment-guide/scale/scaling-for-enterprise#enterprise-search) provides optimized search performance with dedicated indexing for large-scale deployments.
|
||||
- Object storage: Configure S3-compatible backends with erasure coding or replication for durability. All application servers must access shared file storage (NAS or S3) to ensure consistent data availability.
|
||||
- Calls services: Run multiple `rtcd` and offloader nodes for resilience.
|
||||
|
||||
### Sovereign audio & screensharing
|
||||
|
||||
Deploy [Mattermost Calls](/deployment-guide/calls/calls-deployment-guide) in a self-hosted configuration to ensure voice and screen sharing capabilities remain operational without reliance on the internet, and that media traffic does not traverse non-compliant third-party services.
|
||||
|
||||
- The `rtcd` service, configured using the [RTCD Setup and Configuration](/deployment-guide/calls/calls-rtcd-setup) guide, provides scalable, low-latency media routing hosted on-premises. Run multiple `rtcd` nodes for redundancy.
|
||||
- The `calls-offloader` service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server.
|
||||
|
||||
### Compliance and retention
|
||||
|
||||
Sovereign environments often require strict enforcement of retention policies, legal hold, and export controls. Configure Mattermost's built-in compliance features to meet organizational mandates.
|
||||
|
||||
- Enable [compliance export](/administration-guide/comply/compliance-export) and [monitoring](/administration-guide/comply/compliance-monitoring) to produce auditable exports of message data and user activity logs.
|
||||
- Configure [message retention](/administration-guide/comply/data-retention-policy) and [legal hold](/administration-guide/comply/legal-hold) policies to align with applicable regulations.
|
||||
- Integrate with your organization's [eDiscovery](/administration-guide/comply/electronic-discovery) and archiving systems as required.
|
||||
|
||||
### Mobile notifications
|
||||
|
||||
To prevent sensitive message content from being transmitted to external notification services such as Apple Push Notification Service (APNS) and Firebase Cloud Messaging (FCM), configure Mattermost to use [ID-only push notifications](/deployment-guide/mobile/host-your-own-push-proxy-service). In this mode, only a message identifier is sent to public push notification services, and the client retrieves the content securely from the Mattermost server over an encrypted channel.
|
||||
112
docs/main/deployment-guide/deployment-scenarios/deploy-oob.mdx
Normal file
112
docs/main/deployment-guide/deployment-scenarios/deploy-oob.mdx
Normal file
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: "Deploy for Out-of-Band (OOB) Communications"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
When a critical incident disrupts an organization’s primary infrastructure—due to a cyberattack, cloud outage, or internal failure—a secure, independent communication channel becomes essential. Mattermost can serve as that channel by operating in an Out-of-Band (OOB) environment: isolated, pre-provisioned, and ready to support incident response and business continuity teams.
|
||||
|
||||
This document outlines architectural guidance for deploying Mattermost in an OOB scenario across [generic](#generic-oob-architecture), [AWS](#aws-based-oob-deployment), and [Azure](#azure-based-oob-deployment) environments.
|
||||
|
||||
## Generic OOB architecture
|
||||
|
||||
This platform-agnostic design establishes a fallback communication system, decoupled from primary networks and identity providers.
|
||||
|
||||
<img src={useBaseUrl('/images/oob-generic-architecture.png')} class="align-center" alt="Generic OOB Architecture" />
|
||||
|
||||
### Architecture components
|
||||
|
||||
- **Users (Cybersecurity, IR Teams)**: Pre-authorized personnel trained to access and use the OOB platform during emergencies. Credentials and access methods should be provisioned in advance.
|
||||
- **Secure Access Layer**: A firewall or access gateway protecting entry into the OOB environment. May include network policies, IP allowlists, or WAFs.
|
||||
- **Secondary IdP / Emergency Auth**: A dedicated identity provider not dependent on the organization’s primary SSO or IdP (e.g., a minimal Azure AD tenant, Okta org, or locally stored credentials with MFA).
|
||||
- **VPN / Bastion Host**: A hardened jumpbox or independent VPN granting access to internal OOB components and Kubernetes control plane.
|
||||
- **Failover DNS Manager**: Services like Cloudflare Load Balancer, Azure Traffic Manager, or Route 53 to monitor primary system health and reroute DNS to the OOB ingress.
|
||||
- **Ingress Controller**: e.g., ingress-nginx to handle HTTP(S) routing within the cluster, directing traffic to Mattermost Web, API, and WebSocket endpoints.
|
||||
- **Mattermost Operator & App**: Automates lifecycle of Mattermost instances in Kubernetes; ensures updates, scaling, and configuration consistency.
|
||||
- **PostgreSQL Database**: Persistent storage for channels, messages, users, and configurations; can be self-hosted or managed externally with hardened access.
|
||||
- **Backups**:
|
||||
- **Velero**: Backs up Kubernetes resources to external object store (S3, Blob).
|
||||
- **pg_dump / Cloud-native backup**: Regular logical exports or managed backups.
|
||||
- **Object Storage**: Durable, versioned storage (e.g., S3, Azure Blob) for snapshots and dumps.
|
||||
|
||||
## AWS-based OOB deployment
|
||||
|
||||
Deploying Mattermost in AWS leverages managed services and strong isolation capabilities.
|
||||
|
||||
<img src={useBaseUrl('/images/oob-aws-architecture.png')} class="align-center" alt="AWS OOB Deployment diagram" />
|
||||
|
||||
### AWS components
|
||||
|
||||
- **Amazon EKS**: Managed Kubernetes for Mattermost Operator and application, with HA and auto-scaling.
|
||||
- **Route 53**: DNS service for health-checked failover to the OOB environment.
|
||||
- **Amazon Aurora PostgreSQL**: High-performance managed PostgreSQL with automated failovers.
|
||||
- **Amazon S3**: Object storage for Velero snapshots, configurations, and database backups (with versioning and cross-region replication).
|
||||
- **IAM Roles**: Scoped roles for EKS nodes and Velero using IRSA, enforcing least-privilege.
|
||||
|
||||
<Tip>
|
||||
|
||||
- Use separate AWS accounts or VPCs for full isolation.
|
||||
- Configure Route 53 health checks against public or synthetic endpoints.
|
||||
- Encrypt secrets and enforce least-privilege IAM policies.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Azure-Based OOB deployment
|
||||
|
||||
For Azure customers, AKS and related services provide a robust OOB platform for Mattermost.
|
||||
|
||||
<img src={useBaseUrl('/images/oob-azure-architecture.png')} class="align-center" alt="Azure OOB Deployment diagram" />
|
||||
|
||||
### Azure components
|
||||
|
||||
- **Azure Kubernetes Service (AKS)**: Runs Mattermost workloads with native autoscaling and Azure AD integration.
|
||||
- **Azure DNS + Traffic Manager**: Global traffic routing and DNS failover based on endpoint health.
|
||||
- **Azure Database for PostgreSQL**: Managed DB service with automated backups and patching.
|
||||
- **Azure Blob Storage**: Destination for Velero snapshots and DB dumps; supports lifecycle policies and secure access.
|
||||
- **Azure AD (Secondary Tenant)**: Acts as the IdP for OOB; deployed in a separate directory with scoped permissions and MFA.
|
||||
|
||||
<Tip>
|
||||
|
||||
- Deploy in a dedicated subscription for security and billing separation.
|
||||
- Use Azure Monitor for health checks and Traffic Manager probes.
|
||||
- Harden AKS node pools and isolate workloads with namespaces and network policies.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Operational guidelines
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '80%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><strong>Domain</strong></th>
|
||||
<th><strong>Recommendation</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Access Control</td>
|
||||
<td>Isolate authentication from primary infrastructure. Use MFA, secure vaults, and emergency tokens. Preload user accounts in the secondary IdP.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>DNS Failover</td>
|
||||
<td>Employ TTL-aware health checks via Route 53 or Traffic Manager. Monitor critical HTTP(S) or TCP endpoints.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Backup Strategy</td>
|
||||
<td>Schedule frequent Velero and database backups. Store in versioned, encrypted object storage.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Disaster Recovery Drills</td>
|
||||
<td>Conduct quarterly failover exercises: DNS switching, Mattermost access, and data restores.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Security</td>
|
||||
<td>Treat OOB as Tier 0. Use hardened OS images, audit logging, strict RBAC, and centralized monitoring. Rotate secrets regularly.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Mattermost can be an effective OOB communication platform when deployed with isolation, automation, and operational readiness. Whether on AWS, Azure, or a generic environment, prioritize independence, simplicity, and resilience. Pair these designs with standard IR playbooks and routine failover testing to build a confident, secure response capability.
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: "Deploy for Sovereign Collaboration in Microsoft"
|
||||
---
|
||||
## Overview
|
||||
|
||||
Agencies and critical infrastructure organizations often face strict data sovereignty requirements that restrict the use of public cloud services for sensitive collaboration.
|
||||
|
||||
Deploying Mattermost for sovereign collaboration within Microsoft Teams and Outlook enables secure, compliant, and resilient communication while maintaining workflow continuity inside familiar Microsoft interfaces. Users access both Teams channels and Mattermost channels [from within the Microsoft ecosystem](/integrations-guide/mattermost-mission-collaboration-for-m365), providing a single-pane-of-glass experience and eliminating application switching.
|
||||
|
||||
Mattermost can be hosted on-premises or in sovereign clouds, such as Azure GovCloud or Azure Local, ensuring that messages, files, recordings, and transcriptions remain in compliance-approved systems with encryption and strict policy enforcement.
|
||||
|
||||
Unified authentication with Microsoft Entra-ID extends your Microsoft enterprise IT investments while delivering the compliance, control, and resilience required for mission-critical operations or out-of-band scenarios.
|
||||
|
||||
This document outlines architectural guidance for enabling sovereign collaboration within your Microsoft ecosystem.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
|
||||
Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs support deploying Mattermost and supporting services for soverign collaboration within your Microsoft ecosystem.
|
||||
|
||||
</Note>
|
||||
|
||||
## Architecture components
|
||||
|
||||
The deployment architecture includes the following components:
|
||||
|
||||
- **Users:** Enterprise users within the network boundary accessing client applications for M365 services and Mattermost.
|
||||
- **Microsoft Entra ID (Identity Provider):** Users authenticate to M365 applications and Mattermost using [single sign-on Entra ID](/administration-guide/onboard/sso-entraid) via OpenID Connect (OIDC) or SAML.
|
||||
- **Client Applications:**
|
||||
- **Microsoft 365 Desktop Apps:** Teams and Outlook with [embedded Mattermost application](/integrations-guide/mattermost-mission-collaboration-for-m365) for seamless collaboration within a familiar interface while enforcing regulatory compliance.
|
||||
- **Mattermost Desktop Apps:** Access Mattermost via [desktop](/deployment-guide/desktop/desktop-app-deployment) or web apps in addition to the embedded views from Teams and Outlook. *(Optional - not shown)*
|
||||
- **Mattermost Mobile Apps:** Access Mattermost via [iPhone and Android apps](/deployment-guide/mobile/mobile-app-deployment), with support for [ID-only push notifications](/deployment-guide/mobile/host-your-own-push-proxy-service) to ensure compliance with data sovereignty requirements. *(Optional - not shown)*
|
||||
- **Mattermost Deployment:** Mattermost deployed for sovereign collaboration on enterprise-controlled infrastructure or private cloud, such as [Azure](/deployment-guide/server/deploy-kubernetes) or [Azure Local](https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview), to maintain compliance with STIG, FedRAMP, and NIST 800-53 standards. See [reference architecture](/deployment-guide/scale/server-architecture) documentation for Mattermost deployment configurations based on expected scale.
|
||||
- **Mattermost Server:** Core application server handling collaboration workloads, including:
|
||||
- [Messaging Collaboration](/end-user-guide/collaborate/collaborate-index): DDIL-ready 1:1, group messaging, and structured channel collaboration with [rich integration capabilities](/integrations-guide/integrations-guide-index) and [enterprise-grade search](/deployment-guide/scale/scaling-for-enterprise#enterprise-search).
|
||||
- [Workflow Automation](/end-user-guide/workflow-automation/workflow-automation-index): Playbooks provide structure, monitoring and automation for repeatable processes built-in to your sovereign Mattermost deployment.
|
||||
- [Project Tracking](/end-user-guide/project-management/project-management-index): Boards enables project management capabilities built-in to your sovereign Mattermost deployment.
|
||||
- [AI Agents](/administration-guide/configure/agents-admin-guide): AI Agents run against Azure OpenAI endpoints or a self-hosted LLM that is OpenAI-compatible.
|
||||
- [Audio & Screenshare](/deployment-guide/calls/calls-deployment-guide): Calls offers native real-time self-hosted audio calls and screen sharing within your own network.
|
||||
- **Proxy Server:** The [proxy server](/deployment-guide/server/setup-nginx-proxy) handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services. NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers.
|
||||
- **PostgreSQL Database:** Stores persistent application data on a [PostgreSQL v13+ database](/deployment-guide/server/prepare-database), such as [Azure Database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql).
|
||||
- **Object Storage:** File uploads, images, and attachments are stored outside the application node on an [S3-compatible store](/deployment-guide/server/prepare-file-storage) or an NFS (Network File System) server. [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) can be used, but needs an S3-compatible proxy for Mattermost to interface with.
|
||||
- **Recording Instance:** `calls-offloader` job service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to enterprise-controlled infrastructure or private cloud. *(Optional)*
|
||||
- **Self-hosted integrations:** [Custom apps, plugins, and webhooks](/integrations-guide/integrations-guide-index) can be deployed within the enterprise boundary. *(Optional - not shown)*
|
||||
|
||||
**Secure Access Layer:** A firewall or access gateway protecting entry into the enterprise network. This may include network policies, IP allowlists, or WAFs depending on your networking configurations. *(Optional)*
|
||||
|
||||
**Microsoft Global Network:** [World-wide network](https://learn.microsoft.com/en-us/azure/networking/microsoft-global-network) of Microsoft data centers, delivering public cloud services including M365 and Azure OpenAI.
|
||||
|
||||
**Azure OpenAI Service:** [LLM service](/agents/docs/providers) used for summarization, ai-enhanced search, and agent-assisted workflows, hosted within the Microsoft Global Network. *(Optional)*
|
||||
|
||||
## Operational Best Practices
|
||||
|
||||
The following best practices and deployment configurations help ensure that Mattermost remains compliant, resilient, and fully sovereign when deployed alongside Microsoft 365.
|
||||
|
||||
### High availability and fault tolerance
|
||||
|
||||
Deploy Mattermost in a [cluster-based architecture](/deployment-guide/server/high-availability-cluster-based-deployment) to ensure continued availability during outages or hardware failures. High availability requires redundant infrastructure across each critical component:
|
||||
|
||||
- Application servers: Scale horizontally across multiple nodes with a load balancer distributing client traffic.
|
||||
- Database layer: Use PostgreSQL replication or managed HA services with automatic failover.
|
||||
- Search service: [Elasticsearch or AWS OpenSearch Service](/deployment-guide/scale/scaling-for-enterprise#enterprise-search) provides optimized search performance with dedicated indexing for large-scale deployments.
|
||||
- Object storage: Configure S3-compatible backends with erasure coding or replication for durability. All application servers must access shared file storage (NAS or S3) to ensure consistent data availability.
|
||||
- Calls services: Run multiple `rtcd` and `calls-offloader` nodes for resilience.
|
||||
|
||||
### Sovereign audio & screensharing
|
||||
|
||||
Data sovereignty compliance may require that all voice and screen sharing traffic remain within enterprise-controlled infrastructure and does not traverse third-party services. Deploy [Mattermost Calls](/deployment-guide/calls/calls-deployment-guide) in a self-hosted configuration to ensure that Microsoft Teams users and Mattermost users collaborate without media ever leaving the sovereign network.
|
||||
|
||||
- The `rtcd` service, configured using the [RTCD Setup and Configuration](/deployment-guide/calls/calls-rtcd-setup) guide, provides scalable, low-latency media routing hosted on-premises. Run multiple `rtcd` nodes for redundancy.
|
||||
- The `calls-offloader` service, configured using the [Calls Offloader Setup and Configuration](/deployment-guide/calls/calls-offloader-setup) guide, offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server.
|
||||
|
||||
### Compliance and retention
|
||||
|
||||
Sovereign environments often require strict enforcement of retention policies, legal hold, and export controls. Configure Mattermost's built-in compliance features to meet agency or sectoral mandates.
|
||||
|
||||
- Enable [compliance export](/administration-guide/comply/compliance-export) and [monitoring](/administration-guide/comply/compliance-monitoring) to produce auditable exports of message data and user activity logs.
|
||||
- Configure [message retention](/administration-guide/comply/data-retention-policy) and [legal hold](/administration-guide/comply/legal-hold) policies to align with applicable regulations.
|
||||
- Integrate with your organization's [eDiscovery](/administration-guide/comply/electronic-discovery) and archiving systems as required.
|
||||
|
||||
### Mobile notifications
|
||||
|
||||
To prevent sensitive message content from being transmitted to external notification services such as Apple Push Notification Service (APNS) and Firebase Cloud Messaging (FCM), configure Mattermost to use [ID-only push notifications](/deployment-guide/mobile/host-your-own-push-proxy-service). In this configuration, only a message identifier is sent to public push notification services and the client retrieves the content securely from the Mattermost server over an encrypted channel.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Deployment Scenarios"
|
||||
---
|
||||
This section outlines reference architectures and guidance tailored for specialized Mattermost deployment scenarios, enabling organizations to build secure, compliant, and resilient collaboration environments across diverse operational contexts.
|
||||
|
||||
Whether you’re implementing out-of-band communications, mission partner collaboration, sovereign collaboration within Microsoft ecosystems, or mission-critical operations at the edge, these architectures offer comprehensive guidance, design patterns, and best practices to ensure robust and reliable deployments.
|
||||
|
||||
- [Out-of-Band Communications](/deployment-guide/deployment-scenarios/deploy-oob) - Deploy Mattermost as an isolated, pre-provisioned communication system for incident response and business continuity.
|
||||
- [Mission Partner Collaboration](/deployment-guide/deployment-scenarios/deploy-mission-partner) - Multi-organizational collaboration architecture with secure information sharing between allied networks and coalition partners.
|
||||
- [Enterprise to Edge DDIL Operations](/deployment-guide/deployment-scenarios/deploy-ddil-operations) - Deployment patterns for Denied, Degraded, Intermittent, and Limited (DDIL) communication environments with offline capabilities.
|
||||
- [Sovereign Collaboration in Microsoft](/deployment-guide/deployment-scenarios/deploy-sovereign-collaboration) - Integration architecture for sovereign cloud environments with Microsoft Teams, Outlook and other M365 services.
|
||||
- [Air-gapped Deployment](/deployment-guide/deployment-scenarios/air-gapped-deployment) - Guidance and best practices when deploying Mattermost in air-gapped environments.
|
||||
Reference in New Issue
Block a user