When Mattermost customization needs outside help
Most teams that customize Mattermost are building a bounded extension on top of a stable server, not rebuilding the product. The server is a single Linux binary backed by PostgreSQL, and most custom work sits at the edges: incoming and outgoing webhooks, slash commands, bots, a plugin or two, and branding settings. In-house engineers can usually handle small webhook work well. Plugins that touch server behavior and integrations that span several internal systems are where a partner's experience with the platform's build, testing and upgrade cycle tends to pay off. The triggers are usually specific. A security or identity team needs notifications from a ticketing, monitoring or HR system that must authenticate correctly and respect channel permissions. A business unit wants a playbook or approval workflow that routes through an existing case management system. Legal or communications requires branding across the web and mobile clients, or a custom login page that matches corporate identity. Each of these raises a question your team should answer before writing code: which user identity and permission model the integration relies on, and which system owns the data it writes into Mattermost. The short answer: keep webhook and slash command work in-house when it has one owner, one target system and a clear rollback. Hand plugins, server-side hooks and anything crossing three or more systems to a partner when you lack a second engineer who knows the Go or React plugin framework, or when the work has to pass your change control on a tight schedule. Either way, get the decision written down with the owner named. Custom code is not a one-time cost. Mattermost publishes a new server version in binary form on the 16th of each month, and an ESR track exists for slower change. Every plugin, bot token and integration has to be retested against each release it will run on, and the plugin API can change between versions. Ask any partner for a written plan covering who runs regression tests after each upgrade, where custom code is stored and versioned, and who answers when an integration breaks at 2 a.m.
Before you sign, confirm three things with your team: the exact list of integrations and their owners, the Mattermost release track you intend to stay on, and whether your edition includes the features the integration depends on, such as SSO or group sync. Those answers decide whether the work is a small build or a managed program.
What a Mattermost customization engagement includes
Mattermost customization is usually split into design, build, configuration, testing and handover, and each stage leaves something the client owns. The cards below show what each package produces, so the client can compare the work against their own team's capacity and confirm what their edition and deployment method allow.
Requirements and extension design
This package fixes which workflows need custom behavior, which Mattermost extension point fits each one (plugin, slash command, bot, webhook or outbound integration), and which data each extension reads or writes. Design choices made here decide how much code must be maintained across monthly server releases. The client keeps a written design record with the decision for each requirement and the open questions that need an owner.
Plugin or integration build
The build package produces the custom plugin or integration code against the Mattermost plugin framework and the server version the client runs. It covers dependencies, error handling and any admin settings the plugin exposes. Confirm the target server version, whether the plugin uses only documented APIs, and who will review plugin code before it reaches production. The client keeps the source code in its own repository and a deployment package that can be installed on a test server first.
Slash commands and bots
Slash commands and bots let users trigger actions, such as creating a ticket or querying a service, from inside a channel. This package defines each command's syntax, permissions, response format and the account the bot uses to act. Check which identity the bot authenticates as and whether its actions appear in audit logs for your retention policy. The client keeps the command definitions, bot configuration and a list of permissions granted to each bot.
Webhook and outbound integration flows
Incoming and outgoing webhooks connect Mattermost to ticketing, monitoring, CI and other internal systems. This package maps each message flow, its trigger, payload format, retry behavior and the credentials it uses. Confirm where secrets are stored, how failed deliveries are logged, and which endpoints are reachable from the Mattermost network segment. The client keeps the flow map, payload examples and the secrets inventory with rotation owners.
Branding and configuration
Branding covers logos, color themes, site name, email templates and the default configuration for teams and channels, applied through supported settings where possible. Each change is recorded so it can be reproduced on a new server or after a reinstall. Confirm which branding options your edition exposes and which settings require file changes that must survive upgrades. The client keeps a configuration record listing every setting changed from the default and the reason for it.
Test environment, handover and release check
A test environment mirrors the production server version, plugins and integrations so changes can be verified before they reach users. The handover package adds documentation, a runbook for installing, upgrading and disabling each custom component, and a compatibility check against the next Mattermost release. The monthly release date and support windows are published in the Mattermost server releases documentation, so the check can be scheduled ahead of each upgrade. The client keeps the test environment definition, the runbook and a compatibility record for each release tested.
Choosing a plugin, slash command, webhook or bot for each job
Pick the smallest extension point that does the job, because each one carries a different build effort, upgrade exposure, security review burden and operating owner. Incoming webhooks are the lightest option: a script or external system posts a message into a channel through a URL that Mattermost generates for that channel. They suit alerts from build pipelines, monitoring tools or scheduled reports, where the only thing Mattermost must do is accept a message. Because the webhook is a bearer URL, the review question is who holds it and whether it can be rotated, not what code runs on the server. Outgoing webhooks and slash commands fit user-triggered actions. A user types a trigger word or a slash command, and Mattermost calls an external HTTP endpoint that your team owns and operates. The build effort sits in that endpoint, which must validate the request token, handle timeouts and return a well-formed response. Review should cover what the endpoint can reach on your network, what data it returns into channels, and who is on call when it fails. Slash commands are easy to add and easy to forget, so keep an inventory with an owner for each one.
Bots suit conversational or stateful workflows, such as a multi-step approval that remembers where a user is, or a reminder that tracks open items across days. A bot is a Mattermost account driven by code through the API, so it needs its own identity, permissions and credentials, and it is affected by changes to the API. Build effort is higher than for webhooks, and the operating owner is the team that maintains the bot's code and its service account. Confirm how your identity model treats bot accounts before rollout, since they often sit outside the normal user lifecycle. Plugins are for deeper changes to the server and web or mobile interface, such as new message types, custom settings pages or server-side logic that must run inside Mattermost. Plugins are compiled and tied to specific server versions, so each plugin must be rebuilt and tested against every server release you adopt, including the monthly binary releases and any Extended Support Release you run. A plugin that works on one version can fail on the next, which makes plugins the highest upgrade exposure and the item that needs the most regression testing before each upgrade. Plugin code also runs with access to server internals, so it needs the strictest security review and a named owner for updates.
Before choosing, ask three questions for each job: does the logic need to run inside the server, does it need to hold state or conversation, and can an external service carry it safely? If the answer to the first is no, avoid a plugin. If the job needs only one-way posts, use a webhook. Record the owner, the server versions it was tested on and the credentials or tokens involved. Confirm current extension capabilities, supported interfaces and plugin requirements in the Mattermost developer documentation for your target version before scoping any build, because these change between releases. Ask your implementation partner to show the test plan for each plugin across the versions you intend to run, and to confirm which items will be handed over with documented ownership at go-live.
What drives customization cost and duration
This table lists the factors that most change the effort of a Mattermost customization project, why each one matters, and how to keep it contained. Use it to compare scope options before asking for a fixed-scope quote, since the same feature can take very different effort depending on where the logic runs and how many Mattermost versions it must survive. Most of the lever sits in decisions made at the start.
| Driver | Why it changes the effort | How to keep it down |
|---|---|---|
| Number of integrations and source systems | Each external system adds authentication, data mapping, error handling, rate limits and its own test environment. Webhook and slash command flows are cheaper than bidirectional syncs with a system of record. | Limit the first release to the integrations that drive daily work, and specify the direction and frequency of data flow for each one in writing. |
| Logic in a plugin or outside the server | Plugins run inside the Mattermost server and must be compiled, reviewed and upgraded with it. External bots and services that call the API are decoupled from server releases but need their own hosting and monitoring. | Keep business logic in an external service where possible, and reserve plugins for features that need server hooks or deep UI integration. |
| Custom UI versus configuration | Custom web app components and branding beyond the supported settings require front-end code that must be rebuilt when the web app changes. Configuration and built-in options cost far less to maintain. | Start with supported configuration and branding settings, and confirm with the vendor which UI changes are supported before designing custom components. |
| Number of environments | Development, test, staging and production each need a matching Mattermost version, plugin build and configuration. Keeping them aligned adds deployment and testing work for every change. | Automate builds and deployments with the same scripts across environments, and keep the staging environment close to production in version and configuration. |
| User identity and permission rules | Role-based behavior, group-driven channel membership and custom permission checks depend on how identities arrive from SSO or AD/LDAP. Rules that differ by team or data class multiply test cases. | Define roles and group mappings once, in a written permission matrix, and reuse the same groups for the custom features. |
| Compliance review of custom code | Custom code that handles personal data, credentials or audit events needs a documented review, secure coding checks and evidence that changes were tested. Assessors look for change control on that code. | Agree the review scope and evidence format at the start, and keep the custom code small and well-documented so the review stays focused. |
| Target edition and plan features | Features such as SSO, high availability, FIPS 140-3 compliance and air-gapped deployment are tied to specific plans in the pricing documentation. Custom work that relies on a plan feature cannot be tested without that plan's license. | Confirm the edition and the feature list with the vendor before design starts, and avoid building on features that are not included in the licensed plan. |
| Number of Mattermost versions the code must support | Mattermost ships a new server version each month and runs separate Extended Support Releases. Code that must work across several versions, such as a monthly release and an ESR during a transition, needs more testing for each one. | Target one supported version or the ESR line where possible, and schedule plugin and integration tests as part of each upgrade cycle. |
How a customization project moves from requirements to handover
The sequence turns a list of workflow needs into tested, permission-reviewed extensions that run in production, with the runbooks and upgrade test plan your team needs to keep them working after each monthly release. Each phase closes with a named output, so you can see progress and stop or redirect work before it reaches your live server.
Discover workflows and connected systems
We interview the teams that use Mattermost today, map the workflows they want to automate or extend, and inventory the systems those workflows touch, such as ticketing, CI pipelines, identity groups and internal APIs. We also record which Mattermost version, edition and deployment method you run, because that determines which extension mechanisms are available. The phase closes with a requirements register that lists each requirement, its owner, the systems involved and the data it reads or writes. You confirm the register in writing before design starts.
Fix the extension type for each requirement
For every requirement in the register we write a short design note that selects the extension type: a slash command, incoming or outgoing webhook, bot account, plugin, playbook configuration or a custom integration service outside the server. The note states the trigger, the data flow, the credentials used, the permissions required and the upgrade risk of each choice. Plugins carry the most maintenance cost across releases, so the note records why a plugin is needed where a simpler option would not meet the requirement. The output is a design note you approve, which becomes the baseline for the build and the review.
Build in a non-production environment
We build each extension against a test Mattermost server that matches your production version, configuration and database engine as closely as the scope allows. Code, configuration and plugin manifests are kept in version control with a changelog entry per change. Test data is synthetic or anonymized, and test credentials are kept separate from production secrets. Each build item is checked against its design note, and the phase closes when every item passes functional tests on the test server and the build artifacts are recorded with their versions.
Review security and permissions
We review each extension for the permissions it requests, the tokens and secrets it stores, the endpoints it exposes, input handling in commands and dialogs, and the data it sends to external services. Access is checked against the roles defined in your team and channel structure, including what a bot account can read in private channels. Plugin code is reviewed for dependencies and for the settings it exposes to administrators. The output is a review record listing each finding, its severity, the fix and the retest result. Items with open high-severity findings do not move to the pilot.
Run a pilot with a small user group
We deploy the approved extensions to a test or staging instance connected to a small group of volunteer users who represent the teams that will rely on them. Pilot users run the real workflows, and we collect defects, usability issues and any unexpected effects on notifications or channel activity. The pilot also checks behavior under the load pattern you expect, and confirms that bot accounts and webhooks keep working after a server restart. The phase closes with a pilot report listing accepted changes, deferred items and a go or no-go recommendation for production.
Release to production with rollback steps
We schedule the production change with your change management process, back up the database and file storage, and deploy the extensions using the same artifacts that passed the pilot. Each change has a written rollback procedure that names the steps to disable or remove an extension, restore configuration and restore data if a migration has run. We verify the release with smoke tests for each workflow and watch logs and error rates for an agreed period. The output is a release record with versions, timestamps, verification results and whether rollback was needed.
Hand over runbooks and an upgrade test plan
We deliver runbooks for installing, configuring, disabling and restoring each extension, along with the list of secrets, service accounts and external dependencies they need. The upgrade test plan lists the checks to run against a test server before each Mattermost release, including plugin compatibility, API calls used by custom code and the workflows covered by the pilot. We walk your team through both documents and run one dry-run of the upgrade test with your staff. Handover is complete when your team has signed off the documents and the first upgrade test has been scheduled. The schedule for all phases depends on the scoped items and is set in the written scope.
Keeping custom work working across monthly releases
Custom work on Mattermost, whether it is a plugin, a slash command, a webhook receiver, a bot or a branded client build, has to survive a new server version every month. Mattermost releases a new server version in binary form on the 16th of each month, and its server releases page lists a support end date for each version. The supplied examples show the rhythm clearly: v11.11 was released on 2026-09-16 with support ending 2026-12-15, and v12.0 was released on 2026-10-16 with support ending 2027-01-15. Before you agree to any custom work, confirm which version you will run at go-live and when its support ends, because that date sets how often your team must repeat compatibility work.
Extended Support Release (ESR) builds are the main way to slow that cadence. According to the releases page, v11.7 is an ESR, released on 2026-05-15 with support ending 2027-05-15. An ESR lets you stay on one version for a longer period and apply it to fewer, more deliberate upgrades. The trade-off is that you give up newer features and interface changes for that period, and any custom plugin that depends on a feature added after the ESR will not be available to you. Decide early whether your custom work depends on recent server APIs, because that answer determines whether an ESR is a practical choice or a constraint your developers will fight.
Four controls keep custom work stable across releases. First, pin the versions of every dependency your custom code uses, including the Go and Node toolchains for plugin builds, client libraries and any container base images, so that a rebuild does not silently pull in new versions. Second, keep a standing test environment that runs the same database engine, file storage type and plugin set as production, and that receives each new server version before production does. Third, use a written compatibility checklist for each release that covers plugin load and startup, slash command and webhook responses, bot permissions, authentication flows and the custom client build. Fourth, name one owner for the custom code, with a backup, who decides whether a release is acceptable for the custom work.
The checklist should be specific to your code. For each custom component, record what it calls, what it stores, which roles and permissions it needs and how it is deployed. A plugin that reads channel membership or posts through a bot account needs a test that confirms those permissions still work after an upgrade. Ask your implementation partner to deliver the inventory and the checklist as part of the handover, and confirm with the vendor which API areas carry deprecation notices in the release notes for each version you plan to run. Keep those notes with the code so the owner can see what changed since the last approved release.
This section covers how to plan for releases, not how to perform an upgrade. The step-by-step upgrade procedure, plugin retesting before each upgrade and ongoing support terms are covered in the Mattermost upgrades and support topic. Use that topic to plan the execution once the release policy, the pinned dependencies, the test environment and the owner are in place, and use the checklist here to decide whether a given version is ready to receive it.
What goes wrong in Mattermost customization projects
Most Mattermost customization problems surface after go-live, when a release, a migration or a staff change exposes work that was built quickly. The six cards below cover recurring failure patterns in self-hosted projects, each paired with the check that prevents it.
Breakage on the next release
Mattermost releases a new server version in binary form on the 16th of each month, so a plugin or integration that works on one release can fail on the next. The same risk applies to integrations that call API endpoints not documented as supported for the version in use. Prevention: keep a staging server on the target release, run every plugin and integration against it before each production upgrade, and confirm every API call against the reference for that version.
Over-privileged custom code
Plugins, bots and scripts often run with an admin token or a broad system role because that is the fastest way to make them work. Any user who triggers the command or event then indirectly uses those rights. Prevention: create a dedicated bot account for each integration with only the permissions its task needs, limit the teams and channels it can join, and document each grant so a reviewer can trace it.
Webhook secrets in plain text
Webhook tokens, bot tokens and signing secrets often get pasted into shell scripts, cron jobs or repository files. Anyone with read access to the script or its history can post as the integration or call its endpoints. Prevention: move secrets into a secret store or vault, load them at runtime, rotate them after staff changes, and scan repositories for credential patterns before each merge.
Requirements that assume a higher plan
A design may depend on SSO, AD/LDAP sync, high availability or air-gapped deployment. Mattermost's pricing page places SSO and AD/LDAP sync in the Professional plan, high availability and FIPS 140-3 compliance in Enterprise, and air-gapped deployment in Enterprise Advanced. Building around a feature before confirming the license leaves the project blocked at go-live. Prevention: list every feature the design needs, check each against the current plan terms, and confirm the subscription in writing before development starts.
Integrations not rebuilt after migration
Mattermost documents that integrations are not included in a Slack export and cannot be migrated, so apps, slash commands and webhooks from Slack or Rocket.Chat must be rebuilt. Teams often move messages and files successfully and assume their automations came across too. Prevention: inventory every integration before cutover, record its owner and purpose, rebuild each one on Mattermost, and test it in the pilot before the source platform is shut down.
No owner after handover
Custom work often ends with a handover document and a project team that moves on. Without a named owner, nobody reviews plugin updates, rotates credentials or decides whether a monthly release can be adopted. Prevention: assign a technical owner and a backup for each plugin and integration, record the upgrade test steps in the runbook, and agree who approves each release before handover is signed off.
What custom work costs to keep running after go-live
This table lists the recurring cost components of custom Mattermost work after go-live, showing whether each is one-time or recurring and what decides its size. Most ongoing cost comes from keeping custom code aligned with each new server release. The edition or subscription is a separate decision, and Mattermost lists no public prices, so confirm all figures with the vendor.
| Cost component | One-time or recurring | What decides its size |
|---|---|---|
| Test environment hosting | Recurring, with one-time setup | Size of the staging copy, number of release tracks you test, and how long it stays online |
| Maintaining plugin and integration code | Recurring | Number of custom plugins, slash commands, webhooks and bots, and how often their dependencies change |
| Testing against each monthly or ESR release | Recurring | Monthly server releases ship on the 16th, and ESR tracks change the cadence, so set your test cycle to match |
| Dependency and security patching | Recurring | Number of libraries and runtimes in custom code, plus patch cycles for PostgreSQL and the host operating system |
| Credential rotation for integrations | Recurring, with one-time automation | Number of service accounts, tokens and webhook secrets, and whether rotation is scripted or manual |
| Internal skills to own the code | Recurring staff time, plus one-time training | Whether Go and React skills exist in-house, and how many trained people can cover support and upgrades |
How customization changes by starting point and environment
A new install gives the team the most freedom because no legacy integrations need to be carried forward. Build decisions are made once, and the team can set conventions for plugins, slash commands and webhooks before users depend on them.
- Build: Define the integration catalog first, covering webhooks, slash commands, bots and plugins. Record which integrations need server-side code and which only make outbound calls.
- Test: Run a staging server on the same version as production and test every integration there before users see it.
- Release: Pin the server version and each plugin version in a change record. The server ships in binary form on the 16th of each month, so an unpinned version can change without a planned window.
- Operate: Assign an owner to each integration so that upgrade testing always has someone to ask.
Before the first production user signs in, confirm that the team has a written upgrade path for every custom component.
The Slack export does not include integrations, and Mattermost documents that integrations cannot be migrated. Message and file history can move through the documented migration path, but every automation the team relied on must be rebuilt by hand.
- Inventory: Before the export runs, list every Slack app, webhook, slash command and workflow, along with the person who owns each one.
- Build: Rebuild each item as a Mattermost webhook, slash command, bot or plugin. Choose the simplest option that meets the business need.
- Test: Run each rebuilt integration in a test environment against imported data. Imported history does not trigger live automations, so the test must generate new events.
- Release: Plan a cutover window in which Slack automations are disabled and Mattermost automations are enabled, so that messages are not duplicated or lost.
Ask each integration owner which behaviors must match Slack exactly and which can change, because rebuilt automations seldom behave identically on the first pass.
In a container deployment, custom plugins and configuration are packaged into the image. Each new Mattermost release therefore requires a new image build, and the build pipeline becomes a standing part of the upgrade process.
- Build: Create a pipeline that takes the official release image, adds custom plugins and configuration, and tags the result with the server version it was built for.
- Test: Run each rebuilt image against a copy of production data and the same plugin versions before promotion.
- Release: Promote images through environments in the same order every time, and keep the previous image available for rollback.
- Operate: Store plugin binaries in a versioned artifact repository so that a rebuild cannot pull an untested version by accident.
Confirm the exact deployment method for your cluster during planning, because Mattermost supports Kubernetes, Linux and container installs with different upgrade mechanics. Also check that the pipeline can rebuild the image for an earlier release, since a security fix may require it.
On an air-gapped network, nothing can be downloaded at build time or at upgrade time. Every dependency, plugin package and server update must cross into the enclave through an approved transfer path, and the team must confirm that its plugins are permitted under its plan.
- Plan: The pricing page lists air-gapped deployment under the Enterprise Advanced plan. Confirm plugin constraints and license terms with Mattermost in writing before design begins.
- Build: Build and verify plugin packages and dependencies outside the enclave, then move them in through the approved transfer process.
- Test: Test each plugin in a connected staging environment first. Confirm that no plugin depends on an outbound service the enclave cannot reach.
- Release: Move each monthly server binary and plugin update through the same transfer path, and record checksums at each stage.
- Operate: Keep a list of every external endpoint that custom code calls, because those calls fail silently or visibly inside the enclave.
Get the plugin constraints for your plan confirmed in writing before any build work starts, since the answer determines which integrations are possible at all.
A plugin written for an older server version must be checked against the target version before any upgrade. Plugin interfaces and dependencies change over time, so the work is a compatibility project that must be planned and tested.
- Assess: Record the server version the plugin was built for, its dependencies and every server interface it uses. Compare these against the release notes for the target version.
- Build: Update the code and rebuild it with current tooling. Keep the existing version available until the new one passes testing.
- Test: Run an upgrade test on a copy of production with the real plugin configuration, and repeat the test for each release on the cadence you intend to follow.
- Release: Schedule the plugin upgrade alongside the server upgrade, or ahead of it on staging, and write down the rollback path for both.
- Operate: Name the person who maintains the plugin after handover, because the next release may require another round of changes.
Compare the target with the monthly release train and with the Extended Support Release v11.7, which is supported until 2027-05-15. The choice changes how often this compatibility work recurs.
What the client needs to provide before customization starts
The fastest way to lose time on a Mattermost customization project is to start designing before the client has supplied the inputs below. Each item gates a specific part of the work. Some block the design, because the team cannot choose between a slash command, a webhook, a bot or a playbook step without knowing the workflow and the system it touches. Others block testing, because nothing can be verified without a server, credentials and data to run against. Request each item in writing before scope is fixed, and confirm who on your side owns it, since most delays come from unanswered questions during the build.
Start with the environment and the edition. Customization needs a running or planned Mattermost server in a test environment where the client's administrators have full access, including the System Console and the ability to install and disable plugins. Production access is not needed for design, and production should not be the first place custom code runs. Also confirm the plan the organization holds. The Mattermost pricing page places SSO and AD/LDAP user sync from the Professional plan and high availability from Enterprise, so an extension that depends on a feature outside the current plan will block testing or change the design. Because the pricing page lists no public prices, confirm the plan and its entitlements in writing with the account contact.
Next, provide a written list of workflows and the systems each one touches. For every workflow, name the trigger (a slash command, an incoming webhook, a bot reply or a playbook step), the data it reads or writes, and the external system involved, such as a ticketing tool or an identity directory. Without this list, the team cannot pick the right extension type, and that choice drives the code, the permissions and the test plan. Each integration also needs an API credential or service account limited to the actions its workflow requires. Name the owner of each credential so that rotation and revocation are possible after go-live.
Test data must contain no production personal data. Provide synthetic or masked users, channels and messages that reflect the shape of actual traffic, including file attachments of the types each workflow handles. Name a business owner for each workflow who can accept or reject test results and make decisions about behavior, such as message wording, who receives an alert, and what happens when an external system is unavailable. Developers should not make those decisions alone. Name a security reviewer for custom code as well, who will examine plugin code, webhook payloads and secret handling before anything reaches production.
Finally, decide the target server version and release track. Mattermost releases a new server version in binary form on the 16th of each month. The researched release data lists v11.11 with support ending on 2026-12-15 and v12.0 with support ending on 2027-01-15, and v11.7 is an Extended Support Release supported until 2027-05-15. A monthly track means every custom component needs testing on a regular cycle, while an Extended Support Release provides a longer window between changes but may lack newer features the design depends on. Confirm the chosen track before code is written, because plugin APIs and dependencies are validated against a specific server version.
Questions buyers ask about Mattermost customization
How much does Mattermost customization cost, and what drives the price?
The cost follows from the written scope, and each extension is priced by the work it needs. Effort covers requirements, design, build, testing against your Mattermost version, deployment and handover. Cost rises with the number of external systems the code touches, such as identity providers, ticketing tools or data stores, and with the number of users, roles and approval paths the feature serves. A plugin that must run across several environments and support more than one Mattermost version costs more than a single slash command with one owner. Design and build are one-time costs, while testing against new releases and maintenance recur. Ask for a quote that lists each extension separately, the environments it is tested in, who maintains it after go-live and the assumptions about your team's availability. DeployOpen does not publish prices. Mattermost subscription fees are a separate cost.
How long does a Mattermost customization project take?
Duration depends on the number of extensions, their integrations and your approval path, so confirm the schedule in the written scope. The critical path is usually set by inputs outside the code. These include requirements sign-off, API credentials from other teams, a staging environment that matches production, security review of custom code and the number of acceptance test rounds. Work that waits on your identity team, change board or vendor access often delays delivery more than the build does. Plan a staging Mattermost instance on the same version and plugins as production, because plugin tests only mean something there. Ask the provider to show dependencies, name the owner of each input and state the dates by which your team must supply them.
Can our team build a simple webhook or slash command in-house?
Often yes, if one engineer owns the feature and its purpose is narrow. Incoming webhooks post messages from an external system into a channel, and slash commands call an external service when a user types a command. Your team should be able to build one if it can handle tokens securely, validate payloads, log failures and promote the code through staging. Watch for hardcoded secrets, webhooks that post sensitive data into broadly shared channels, no documented owner after the engineer moves on and no test against the version you run. Bring in a partner when the feature touches identity, permissions, personal data or several teams. Confirm the current configuration steps in the Mattermost documentation for your version before you start.
Do Mattermost plugins need retesting on every monthly release?
Yes. Mattermost releases a new server version in binary form on the 16th of each month, and a plugin is only known to work on the versions it has been tested against. A monthly release does not automatically break a plugin, but you should run the plugin's functional tests and your own acceptance checks on staging before each upgrade. Review the release notes for API, configuration or dependency changes that affect your code. If you run Extended Support Releases, testing happens less often, but it still must happen before you adopt an ESR and before its support ends. For example, Mattermost v11.7 is an ESR with support ending 2027-05-15. Record test results per version so each upgrade decision has evidence behind it.
What do we need to provide for a Mattermost customization project?
Your team provides access, decisions and time. Typical inputs include a staging Mattermost server that matches production's version and database, test accounts for each role, API credentials or service accounts for each external system, written requirements with named business owners, a security contact for code review and access to your change process and code hosting. Confirm the Mattermost edition and plan you run, because some features depend on it. Name a product owner who can sign off acceptance criteria within the agreed time. Missing inputs usually delay work more than complex code does. Ask for this list as a written checklist in the scope document before work starts, with a named owner and a due date for each item.
Does custom Mattermost code survive an upgrade?
It can, if it is built on documented extension points and tested on the target version before the upgrade. Code that depends on internal Mattermost APIs, direct database changes or modified binaries is more likely to break. Plugins are installed separately from the server, so each one needs a compatibility check on the new version. Keep configuration changes in version control so they can be reviewed and reapplied. Before each upgrade, run the test suite on staging, check the release notes, verify plugin compatibility and prepare a rollback plan that includes a database backup. An upgrade is complete only after post-upgrade checks confirm messaging, login, integrations and file access work as expected.
Do our Slack integrations carry over when we migrate to Mattermost?
No. Mattermost's documented Slack migration path moves channels, messages, users and files, but integrations are not included in the Slack export and cannot be migrated. Each Slack app, bot, slash command and webhook must be rebuilt or replaced in Mattermost. Start by inventorying every Slack integration: what it does, which channels it uses, what data it reads or writes, who owns it and which credentials it holds. Then decide for each one whether to rebuild it as a webhook, slash command, bot or plugin, replace it with a native feature or retire it. Schedule those rebuilds into the cutover plan, because users notice missing automations quickly.
Can DeployOpen maintain our Mattermost custom code under a retainer?
Yes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so custom code can be maintained after go-live under a written agreement. A retainer can cover the work agreed in scope, such as compatibility testing against new releases, defect fixes, updates to integrations when external APIs change and documentation. Confirm in writing which extensions are covered, which Mattermost versions and release channels are in scope, the response expectations, who holds the repository and credentials and how upgrades are scheduled. Check that the code is documented and readable by your own team. Retainer pricing follows from the written scope, and DeployOpen does not publish prices.
How DeployOpen scopes, builds and hands over Mattermost customization
DeployOpen plans, builds, documents and supports Mattermost customizations inside your own infrastructure, so plugins, bots, webhooks and integrations are owned and run by your team. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every planned plugin, slash command, webhook, bot and integration with its owner, data source and users.
- Confirm the Mattermost server version and plan, since some custom work depends on the edition you run.
- Record which custom features must survive each monthly server release and which ESR line you target.
How we build
- Develop custom code against the documented Mattermost plugin and API interfaces, with version pins recorded in source control.
- Test each customization in a staging instance that mirrors your production PostgreSQL and file storage setup.
- Review permissions, secrets handling and outbound calls for every webhook and bot before it reaches production.
How we hand over
- Deliver source code, build scripts and deployment steps in your repositories, with access granted to your engineers.
- Provide runbooks covering configuration, rollback, known upgrade risks and who approves changes to custom code.
- Walk your administrators and developers through the customizations and the upgrade test checklist before closing the engagement.
How we support
- Offer ongoing support and upgrade testing for custom code as a retainer, covering each monthly release you adopt.
- Retest plugins, slash commands and integrations against each new server version before your production upgrade.
- Confirm with your team the support boundaries, response expectations and retainer scope in the written quote.
