How the Mattermost GitHub integration and GitLab integration post events to channels
The GitHub and GitLab integrations post events by having the source platform send webhook deliveries to your Mattermost server, which then posts them into the channels that users subscribe to. Each integration depends on an OAuth app and a webhook that exist on both sides, so the design work sits in two places: the source platform and the self-hosted Mattermost server. A team that wants pull request, merge request and issue activity in channels needs to decide which side owns each piece before anything is configured. Mattermost documents a GitHub integration that can be set up with a /github setup wizard, which walks through creating the GitHub OAuth app and webhook, or set up manually. It also documents a GitLab integration that supports both GitLab SaaS and on-premises GitLab.
On the GitHub side, the OAuth app and webhook are created in the GitHub organization or repository that the team wants to monitor. Whoever runs the wizard or the manual steps needs permission to create OAuth apps and webhooks there, which is often narrower than the permission to administer the whole organization. Confirm with the Mattermost GitHub documentation which account and role must perform setup, and whether the wizard can be used by a Mattermost system administrator who is not a GitHub administrator. The Mattermost side of the connection is a system administrator decision: it determines which instance receives the events and who can later change subscriptions.
The GitLab integration follows the same two-sided pattern, but the owner of the GitLab side depends on where GitLab runs. With GitLab SaaS, the connection crosses the public internet. With on-premises GitLab, the Mattermost server and the GitLab instance must be able to reach each other on the network paths and addresses you choose, and any internal certificate authority must be trusted by the systems that call each other. Confirm in the Mattermost GitLab documentation exactly which OAuth application and webhook are created on the GitLab side, which GitLab role is required to create them, and whether they are created at group or project level. Those answers decide who in your organization must approve the setup.
Our work typically begins once the team has chosen the source platform and the event types it wants in channels. Before configuration, we would map which repositories or projects feed which channels, confirm the network route from GitHub or GitLab to the Mattermost server URL, including how a high availability cluster routes inbound requests if your plan includes one, and decide where the OAuth client secret and webhook secret are stored. We would also agree on who may create or change subscriptions, because the Mattermost integration lets channel members add notifications, and that permission should match how your teams already control repository access.
The main risk is a setup that works in a test repository but breaks when real projects are added. Plan a test that sends a merge, an issue comment and a merge request comment through the intended channel, and check that the events arrive once and only in the intended channel. Record which GitHub or GitLab account owns the OAuth app and webhook, so that a departing administrator does not silently break notifications. Finally, plan how the integration is removed or re-created during a Mattermost server upgrade, since the server version and the integration settings must remain compatible with the upgrade path you choose.
What you need before connecting GitHub or GitLab to Mattermost
Both integrations depend on three things: a Mattermost server and plan that support the work, the GitHub or GitLab rights to create the OAuth app and webhooks, and a network route that lets events reach Mattermost. Confirm each one before configuration starts, because a gap in any of them stops setup even when the steps are correct.
Mattermost server version and plan
Start by confirming which Mattermost server release you run and which plan your organization holds. Mattermost publishes server releases monthly and labels some as Extended Support Releases, so check the server releases page before choosing a target version. Confirm with the Mattermost pricing page whether the GitHub or GitLab integration requires a specific plan, since that page lists no public prices and directs buyers to sales. Record the plan in the change request so the integration scope matches what you licensed.
Mattermost system admin and channel rights
Setup needs a Mattermost account that can manage integrations, and each target channel needs members who can add an integration to it. Decide who holds system admin rights for the initial configuration, who may change channel subscriptions afterward, and which channels will receive pull request, merge request, issue or pipeline notifications. Keep the list short and named, and agree it with your Mattermost administrators before the change window opens so access requests do not hold up the work.
GitHub organization or repository owner rights
Creating the GitHub OAuth app and webhook requires rights that most developers do not hold. For organization-owned repositories, confirm who the organization owners are and whether your policy lets owners approve OAuth apps. For a single repository, identify the repository admin who can add webhooks. Check whether your organization restricts third-party app access, because a blocked OAuth app stops setup even when the webhook steps are correct. Name an approver and a backup so the change does not depend on one person's availability.
GitLab group or project maintainer rights
On GitLab, the person who configures a webhook or integration needs the role that GitLab's permissions documentation assigns for that action, typically maintainer on a project or owner on a group. Decide whether the integration is set at group or project level, because a group-level setup reaches every project beneath it and changes who sees events. Confirm whether your instance is GitLab SaaS or self-managed. Self-managed instances also depend on administrator settings that control whether webhooks may call internal addresses, so involve the GitLab administrator early.
Network path for webhooks
Webhooks are sent by the source platform, so GitHub or your GitLab instance must reach the Mattermost server over HTTPS at the address you publish. Map the route through firewalls, reverse proxies and any web application firewall, and confirm that the Mattermost site URL matches the address the source platform calls. For GitHub Enterprise Server or self-managed GitLab, check the path from that platform's own network. Test delivery to a non-production channel before releasing the integration to teams.
Supported Mattermost and GitLab versions
Mattermost v11.7 is an Extended Support Release, released on 2026-05-15 with support ending 2027-05-15. Set your target release against that end date and against the monthly server releases Mattermost publishes on the 16th. GitLab publishes a new minor release each month and currently maintains 19.5, 19.4 and 19.3, but that list changes. Confirm the maintained GitLab versions on the GitLab maintenance policy page on the day the work starts, and record both product versions in the design so testing covers releases that still receive fixes.
Choosing between the /github wizard and manual setup for GitHub
The /github setup wizard is the fastest documented way to connect GitHub to Mattermost, because it walks an administrator through creating the GitHub OAuth app and the webhook from inside Mattermost. Manual configuration reaches the same end state by hand. The choice is less about features and more about who performs each step, where the work is recorded, and whether your network rules allow the wizard's flow to complete as written. Before anyone runs either path, settle three decisions: which GitHub organization and repositories will send events, which Mattermost channels will receive them, and who will own the OAuth app after go-live.
The ownership decision matters more than most teams expect. The OAuth app and webhook are tied to a GitHub identity and to the organization that authorizes them. If the person who ran the wizard leaves, the app may need to be transferred, re-authorized or recreated, and the team must know who can approve that change. Record the organization owner, the GitHub account that holds the app, the Mattermost system admin responsible for the integration, and the repository list in a change ticket before setup starts. Confirm with your GitHub administrators how your organization restricts OAuth app approval, since policies differ between organizations.
A self-hosted Mattermost server with strict egress or inbound rules may favor manual steps. The wizard assumes it can complete the GitHub side of the handshake and deliver webhook traffic to your server. In a segmented network, you may need to open specific paths, route callbacks through an approved endpoint, or have the network team review each URL the integration uses. Manual configuration lets you read each value, verify it against your network design and keep a written record of every setting. Check your Mattermost server's callback and webhook URL settings, and confirm with GitHub's documentation which addresses must be reachable.
GitLab follows a separate path and should be scoped on its own. Mattermost's GitLab integration supports both GitLab SaaS and on-premises GitLab, but the two use different base URLs, and the hosting responsibilities differ. With GitLab SaaS, GitLab operates the service and you manage only the Mattermost side and the credentials. With self-managed GitLab, your team also operates the GitLab instance, its certificates, its network reachability to Mattermost and its upgrades. Confirm which deployment you run before copying any URL from the Mattermost documentation, because a SaaS URL pasted into a self-managed setup, or the reverse, will fail in ways that look like authentication errors.
For the GitHub path, write down the expected result of each step before you begin: the OAuth app registration, the webhook creation, the channel subscription and a test event. Run one test in a non-production channel first, then confirm that only the intended repositories post into the production channel. Keep the manual steps as a runbook so the next administrator can repeat or audit them. Ask your DeployOpen contact or your own GitHub and network teams to confirm the current wizard behavior and required endpoints in your environment, since those details depend on your GitHub edition and your Mattermost version.
Configuring the Mattermost GitHub integration and GitLab integration in order
This sequence takes a self-hosted Mattermost server from a reachable URL to confirmed GitHub and GitLab event delivery in a chosen channel. Each step ends with a check that shows the next step can begin safely.
Confirm the Mattermost server URL
Before any integration is created, confirm the public URL that GitHub or GitLab will call to reach your Mattermost server. The owner of the Mattermost deployment should check the site URL in the system console, confirm it uses HTTPS with a certificate the source platform trusts, and confirm the URL resolves and accepts inbound requests from the internet or from the network where your GitLab instance runs. If GitLab is self-managed inside a private network, confirm that route as well. Done means a test request to the webhook path returns a response from Mattermost, not a timeout or certificate error. Verify exact setting names against the current Mattermost GitHub and GitLab integration docs.
Create the GitHub OAuth app and webhook
A Mattermost administrator with access to the GitHub organization or repository owner account starts the GitHub setup through the /github wizard in a Mattermost channel, or follows the manual steps in the Mattermost GitHub documentation. The wizard walks through creating the GitHub OAuth app and the webhook, and the administrator copies the generated values back into Mattermost as the documentation describes. Confirm the scope of access granted to the app against what your security team has approved. Done means the wizard reports a successful connection and a test message or event from the connected repository reaches Mattermost. Check the current wizard prompts and any permission names against the docs before starting.
Enable and configure the GitLab integration
Decide whether the connection targets GitLab SaaS or a self-managed GitLab instance, since Mattermost supports both. On the Mattermost side, enable the GitLab integration and enter the instance details, then create the matching application or webhook configuration in GitLab according to the Mattermost GitLab documentation. For self-managed GitLab, confirm that the GitLab server can reach the Mattermost URL from step one and that its outbound request settings allow the call. Done means GitLab reports a successful test delivery to Mattermost. Confirm the names of GitLab settings and any token or permission requirements against the current docs and your GitLab version.
Create a dedicated test channel
Create a channel for testing, separate from any team channel that will receive production notifications. Limit membership to the people who will verify the events, so that test messages do not reach a broad audience. Decide who may add or remove subscriptions in this channel, because subscription changes determine what the channel receives. Done means the test channel exists, the people verifying events are members, and you have written down its name so that every later check refers to the same place.
Subscribe the test channel to merge and comment events
In the test channel, subscribe to the repository or project events you plan to use, covering merge events, issue comments and merge request comments for each source. Use the subscription commands or settings that the Mattermost GitHub and GitLab documentation describes, and note exactly which event types you selected. Keep the list short for testing so that any unexpected traffic is easy to spot. Done means the subscription list for the channel shows the selected repositories or projects and event types, and you can point to the list in your change record.
Trigger test events and confirm delivery
Create a controlled test: open a test issue, add a comment to it, open a test merge or pull request, comment on it, and merge it in a sandbox repository. Watch the test channel for each event and confirm that the message content, sender and linked item match what you did. Then check that events from an unsubscribed repository do not appear. Done means every selected event type arrives in the intended channel once, and no event lands in a different channel. If an event is missing, check the webhook delivery log on the source platform before changing Mattermost settings.
Record the configuration and move to production channels
Write down the Mattermost URL, the integration settings, the subscription list and the test results, and store them with your change records. Remove the test subscriptions, then add the production channels and event types agreed with the owning teams. Repeat the trigger test on one production repository to confirm the final configuration. Done means the production channels receive the approved events, the test channel is either retired or kept for future checks, and the owners of the integration know who can change subscriptions and secrets.
Which GitHub and GitLab events map to which Mattermost channel messages
This table lists the GitHub and GitLab event types that Mattermost integrations can post to a channel, with the kind of message each produces and the role that should manage each subscription. Read each row as a planning question: which events the team needs, which channel receives them, and who can change the subscription later. The main takeaway is that the event list depends on the integration version and configuration, so confirm each row against the Mattermost integration documentation before you roll out subscriptions.
| Source system | Event type | What appears in the channel | Who should own the subscription |
|---|---|---|---|
| GitHub | Pull request events | Pull request activity posted to the subscribed channel, such as new or updated pull requests (confirm which actions are included) | Repository admin who runs the /github setup wizard or creates the OAuth app and webhook |
| GitHub | Issue events | Issue activity posted to the subscribed channel for the connected repository (confirm the exact issue actions) | Repository admin, with the channel admin approving which issue events reach the team |
| GitLab | Merge request merges | A message when a merge request is merged in the connected project, with a link back to GitLab | Project maintainer or owner who can add the webhook, confirmed against the GitLab integration doc |
| GitLab | Merge request comments | Comments left on merge requests in the connected project, posted to the subscribed channel | Project maintainer, with the channel owner reviewing whether comment traffic suits the channel |
| GitLab | Issue comments | Comments added to issues in the connected project, posted to the subscribed channel | Project maintainer, with the channel owner deciding whether issue discussion belongs in that channel |
| GitLab | Issue events | Issue activity in the connected project (confirm whether issue creation and state changes are included) | Project maintainer or owner, confirmed against the GitLab integration doc |
| GitLab | Pipeline events | Pipeline status messages for the connected project (confirm whether this event is available in your Mattermost version) | Project maintainer who owns CI/CD, with the platform team reviewing channel noise |
| All rows | Verify before rollout | Check the exact event list in each Mattermost integration doc for your server version and GitLab or GitHub setup before you finalize subscriptions | Integration owner, who records the confirmed event list and the approver for each subscription |
How identity and channel permissions shape who can receive and change events
The account that authorizes each integration decides which events can reach Mattermost, so this choice belongs in the design phase, before anyone runs the GitHub setup wizard or configures the GitLab connection. The GitHub setup creates an OAuth app and a webhook, and the authorization is tied to a specific user. That user's repository access determines which repositories the integration can see, so an account with access to a few projects will produce a narrower feed than one with access to the whole organization. GitLab follows the same principle through the account that authorizes the connection and the groups and projects that account can read. For self-managed GitLab, confirm how access is granted in the GitLab authentication and authorization documentation, including group membership, project roles and the token scopes your GitLab version uses.
Within Mattermost, two things decide who can add or edit subscriptions: channel membership and integration administration rights. Anyone who can manage integrations for a team, or who administers the target channel, can effectively decide what that channel receives. Separate the people who read notifications from the people who can change them, because a large channel can still be controlled by a handful of administrators. Before rollout, confirm in your Mattermost version which team and system roles can manage integrations, whether channel members with lower privileges can create subscriptions, and how private channels limit who sees delivered events. Record the answers in the design document so that changes to roles later are reviewed against a known baseline.
The most common access risk appears when the person who authorized an integration leaves the organization. Illustratively, a developer sets up merge request notifications for a project under a personal GitLab account, then changes teams. When the account is disabled, the authorization may stop working, and notifications can stop without an obvious error in the channel. In other cases, the remaining access can change because the user's group memberships shift. Either outcome leaves the integration depending on someone who is no longer responsible for it. Offboarding should therefore include a step that lists every integration owned by the departing person and assigns a new owner before the account is closed, with a check that events still arrive afterward.
The safer pattern is a shared service identity owned by the organization, not by an individual. For GitHub, this can be a dedicated service account or an app installation that the organization controls, with read access limited to the repositories intended for chat notifications. For GitLab, use a dedicated service account with the narrowest project or group roles that still deliver the events you need. Name at least two administrators, record the identity in your asset register, and store its credentials in your secrets management system. Confirm with GitHub and GitLab whether an OAuth app or another app type fits your governance model, and schedule a review of the identity's scope each quarter, since a service identity can see everything it has been granted.
Securing the Mattermost GitHub integration and GitLab webhooks
These controls decide who can connect a repository to a channel, what data travels with each event, and how each webhook is protected in transit and at rest. Work through them together during setup, then confirm them again after a Mattermost or GitLab upgrade changes the integration.
Least-privilege OAuth and token scopes
Create the GitHub OAuth app and any GitLab application or access token with only the scopes the integration needs, and record each scope in your configuration review. Confirm the requested permissions in the /github setup wizard or the manual steps before you approve them, because a broad grant gives the Mattermost server more repository access than event notifications require. For self-managed GitLab, also work through the GitLab hardening recommendations for the instance, since the integration inherits the security posture of the server it talks to.
Restrict channels that receive sensitive events
Decide which repositories and event types may post into which channels before anyone subscribes. Merge request and pull request activity for security-sensitive projects, such as infrastructure or payment code, can reveal unreleased changes to every member of a broad channel. Use private channels for those subscriptions, reserve open channels for general project status, and review channel membership whenever a team changes. Confirm that channel permissions match your data classification policy.
Protect webhook secrets and tokens
Webhook signing secrets and OAuth client credentials let anyone who holds them forge events or act as the integration. Keep them in the server's secret store or protected environment configuration, and keep them out of channel messages, wiki pages and setup notes. Limit read access on the host to the service account that runs Mattermost, rotate credentials after staff changes, and check that admin console views and logs do not display stored values. Confirm the rotation steps against the documentation for your Mattermost and GitLab versions.
Limit who can edit subscriptions
A subscription decides what a repository sends into a channel, so editing one changes your data flow. Decide which Mattermost roles or channel administrators may create, modify or delete GitHub and GitLab subscriptions, and keep that group small. Record an owner for each subscription, review subscriptions when projects are archived or renamed, and check audit logs for changes to integration settings. Confirm which permissions govern integration management in your Mattermost version, since role details change between releases.
TLS on the Mattermost endpoint
GitHub and GitLab send webhook payloads to the Mattermost server URL, and those payloads can include commit titles, comment text and branch names. Terminate TLS on that endpoint with a certificate that the source systems trust, whether it comes from a public authority, an internal authority or a reverse proxy. Confirm that the certificate chain validates from GitHub or GitLab, because a private chain may need trust configuration on the code host side. Test one delivery after go-live and watch for certificate errors in both systems.
Offline and air-gapped event delivery
Hosted GitHub and GitLab SaaS send webhooks from the internet, so they need a network route to the Mattermost server. In an offline or air-gapped network, that route usually does not exist, so the team must confirm which delivery path the environment supports before the design is final. Options to evaluate include a self-managed GitLab instance inside the same network, an internal relay that you operate, or a delivery method the vendor documents for restricted networks. Ask Mattermost and your code host to confirm each option in writing, then test it with sample events from a non-production project.
Why the Mattermost GitHub integration stops posting and how to fix it
This table maps the most common ways Mattermost GitHub and GitLab notifications stop arriving to their likely causes and a check the team can run. Read each row as a starting point for diagnosis, since the fix depends on your server configuration, repository permissions and GitLab deployment. Work through the rows in order, and confirm each check against the current Mattermost and GitHub or GitLab documentation before changing production settings.
| Symptom | Likely cause | Check or fix to run |
|---|---|---|
| Events do not arrive in Mattermost | The webhook URL is unreachable from GitHub or GitLab, often because the Mattermost site URL or firewall rules do not match what the source system calls | From the source system, send a test delivery to the webhook and review the delivery log for connection errors. Confirm the Mattermost site URL in System Console matches the address the source can reach. |
| Events do not arrive in Mattermost | The webhook secret configured on the source does not match the one Mattermost expects | Compare the secret stored in the GitHub or GitLab webhook settings with the integration configuration in Mattermost. Regenerate the secret in both places if you cannot confirm a match. |
| Events do not arrive for some repositories or projects | The account that created the webhook lacks admin or maintainer rights on those repositories or projects | List the affected repositories and confirm the webhook exists on each one. Check the role of the user who completed setup and reconnect with an account that has the required rights. |
| Integration stops working after a user leaves | The OAuth authorization was granted by an individual account that was deactivated, removed or had its access revoked | Identify who authorized the GitHub or GitLab OAuth app. Reauthorize the integration with a current team owner account, and document which account holds the authorization. |
| Integration stops after a permissions change | The OAuth token was revoked in GitHub or GitLab, or the scopes granted no longer cover the events being subscribed | Check the authorized applications list in the source system for the Mattermost app. Reauthorize and confirm the subscribed event types still match what the channel expects. |
| GitLab on-premises events fail with certificate errors | The Mattermost server does not trust the certificate chain of the self-managed GitLab instance, often because an internal certification authority is not installed | Test the connection from the Mattermost server to the GitLab host using the same hostname. Confirm the internal root and intermediate certificates are installed in the trust store the Mattermost process uses, and check for certificate expiry. |
| Notifications appear in the wrong channel | The channel subscription or webhook was created for a different channel, or a channel was renamed or archived and the subscription now points elsewhere | Open the subscription list for the integration in each channel and confirm which repositories or projects it covers. Remove duplicate subscriptions and recreate any that point to archived channels. |
| Notifications stop after a Mattermost upgrade | The integration or plugin version no longer matches the server release, or configuration settings changed between versions | Review the release notes for the Mattermost version you installed and check the integration status in System Console. Test one event in a non-production channel before assuming the webhook is at fault. |
| Notifications stop after a GitLab upgrade | The GitLab version changed event payloads or the integration settings were reset during the upgrade, and the instance may have stopped at a required upgrade stop | Confirm the GitLab upgrade path was followed, then verify the Mattermost webhook still exists in the project. Send a test event and compare the delivery log with the expected payload. |
Testing the integration and keeping it working through upgrades
Test the integration against a written plan before anyone depends on it, and repeat that plan after every upgrade. The plan needs three things: one test repository or project on the GitHub or GitLab side, one test channel in Mattermost used only for these tests, and a checklist of the event types the integration must deliver. Start the checklist with the events your teams rely on. Mattermost documents GitLab notifications for merges, issue comments and merge request comments, so those belong on the list alongside the issue and pipeline events you intend to forward. For GitHub, list pull request, issue and review events the same way. Note the setting that produces each item, so a failed item points to a specific configuration.
Next, write down the expected message for each checklist item. For every event, record the target channel, the title and fields the message should show, the link back to the source object, and whether it should appear only once. Generate each event from a test account so the audit trail shows who triggered it. Keep the test repository private and limit membership of the test channel, because the messages carry repository names, commit titles and comment text. Store the record alongside the integration configuration, including the GitHub OAuth app and webhook settings or the GitLab webhook settings, and the setup path you used, whether the /github setup wizard or manual configuration. After each upgrade, compare live output against this record item by item and resolve any difference before the change reaches production.
Mattermost publishes server versions in binary form on the 16th of each month, so the upgrade calendar moves monthly. The release page lists v11.11 as released on 2026-09-16 with support ending 2026-12-15, and v12.0 as released on 2026-10-16 with support ending 2027-01-15. If your organization runs an Extended Support Release, changes arrive more slowly and support lasts longer. Mattermost lists v11.7 as an ESR released on 2026-05-15 with support ending 2027-05-15, and v10.11, the previous ESR, reached end of life on 2026-08-15. Whichever track you follow, retest the integration after each planned server upgrade, not only the major ones. Check the release notes for changes that touch integrations, and confirm the support end date for your version against your upgrade calendar, because running past it leaves the server without further fixes.
GitLab moves on a different rhythm. It ships a minor release on the third Thursday of each month and patch releases twice a month. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11. Plan the path through each stop and confirm it against the upgrade paths documentation before scheduling. GitLab backports bug fixes only to the current stable release, while security fixes also reach the previous two monthly releases, so the version you run determines how quickly fixes arrive. GitLab-side changes can alter webhook payloads, which means a GitLab upgrade can break the Mattermost integration with no change on the Mattermost side. Retest after every GitLab upgrade, including patch releases that carry security fixes you need.
Questions buyers ask before hiring help with the Mattermost GitHub and GitLab integrations
How much does a Mattermost GitHub and GitLab integration cost to set up?
DeployOpen does not publish a price list, so the cost follows from a written scope and is quoted after that scope is agreed. Most of the spend is labor for the one-time build, with recurring costs only if you buy a retainer or keep paying for your own Mattermost and GitLab subscriptions. The main drivers are the number of GitHub repositories and GitLab projects that will post events, the number of GitLab instances (SaaS and self-managed count separately), how many channels and routing rules you want, and the security review and testing you require before go-live. Ask for a quote that lists each driver as its own line, states what the OAuth app and webhook setup includes, and names the handover documents you receive.
What drives the cost of connecting GitHub and GitLab to Mattermost?
The cost moves with how much variation the integration must handle. A single GitHub organization posting to one channel is a small build, while several organizations, multiple GitLab instances and per-team channel routing add design, configuration and test work. Event selection matters too: choosing which merges, issue comments, merge request comments and pipeline events go to which channels takes decisions from your engineering leads and time to validate. Security review adds cost when your team needs documented OAuth app ownership, secret storage and a test record. Network work adds cost when self-managed GitLab or Mattermost sits behind firewalls or in a segmented network. Ask the quote to show which items are fixed and which depend on counts you still need to confirm.
How long does the GitHub and GitLab integration work usually take?
The duration depends on the scope, so no timeline is given here. The biggest factors are how many repositories, projects and GitLab instances are involved, how many channel and event decisions your teams must make, and how quickly your team returns access, approvals and test results. Waiting on OAuth app registration approval, firewall changes for webhook delivery, or a change window on a production Mattermost server can add elapsed time even when the build itself is short. Testing with real events from each repository and project usually takes more than one cycle. Ask for a timeline in the written scope that separates discovery, build, test and handover so you can see which steps depend on your team.
What must our team provide before the Mattermost integration work starts?
Your team needs to provide four things. First, admin access to the Mattermost System Console and the ability to enable integrations on the server. Second, GitHub organization or GitLab group access sufficient to register OAuth apps and create webhooks, plus a named owner who will hold those OAuth apps after handover. Third, a test plan that lists the repositories, projects, channels and events to verify, along with the people who will confirm each result. Fourth, network changes so that GitHub or GitLab can reach the Mattermost endpoint for webhooks and so the Mattermost server can reach a self-managed GitLab instance. Confirm these with your security team before scheduling, because approvals often take longer than the configuration itself.
Can our internal team set up the Mattermost GitHub and GitLab integrations alone?
A capable internal team can usually do it alone, because Mattermost documents both integrations. The GitHub integration offers a /github setup wizard that walks through creating the OAuth app and webhook, and the manual route is also documented. The GitLab integration supports both GitLab SaaS and on-premises GitLab. The harder parts are rarely the first configuration. They include owning the OAuth app and its secrets over time, deciding channel routing that matches your teams, running a security review, testing edge cases, and repeating the checks after Mattermost server upgrades or GitLab upgrades. Decide who on your team will own each of these before starting, and compare that effort with a fixed-scope engagement that includes documentation and handover.
Do we need an ongoing retainer after the integrations go live?
A retainer is optional. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, but a fixed-scope build can end at handover if your team can operate the integrations. A retainer becomes more useful when you expect frequent changes to repositories, projects and channel routing, when you want someone to review OAuth app permissions and secret rotation on a schedule, or when you need the integration checked after each Mattermost server release and each GitLab upgrade. Mattermost publishes server releases monthly, and self-managed GitLab requires planned upgrade stops. Ask the quote to state what the retainer covers, how requests are logged, and what happens to the integrations if the retainer ends.
How much does GitLab Premium cost if we also buy GitLab for this?
The GitLab pricing page lists GitLab Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate with custom pricing. All three tiers are available for self-managed installations. Treat this as a separate line item from the Mattermost integration work, because the integration is not a GitLab purchase. The Mattermost documentation does not tie the GitHub or GitLab integration to a particular GitLab tier in the sources reviewed here, so do not assume a tier is required. Confirm with GitLab which features your team needs, and confirm the integration behavior on the exact GitLab version you run before you buy or upgrade.
Does the GitLab integration work with self-managed GitLab instances in our network?
Yes, the Mattermost GitLab integration is documented for both GitLab SaaS and on-premises GitLab, and it sends notifications for events such as merges, issue comments and merge request comments. Your team still needs to confirm three points for your environment. The Mattermost server must be able to reach the self-managed GitLab instance, the GitLab instance must be able to reach the Mattermost webhook endpoint, and the GitLab version must match the integration steps you follow. If your GitLab runs in an offline or air-gapped network, GitLab documents separate guidance for that setup, and the integration path should be checked against it. Ask the implementation plan to list each network path that must be opened and who approves it.
How DeployOpen scopes, delivers and supports the GitHub and GitLab integrations
DeployOpen scopes the GitHub and GitLab integrations as part of your Mattermost server, with OAuth apps, webhooks and channel routing designed against your own repositories and GitLab instance. We build them inside infrastructure you control and hand over documented runbooks that your team can operate.
How we scope
- Written scope that names each source: GitHub organization, GitLab SaaS or self-managed instance, and the repositories or projects included
- Event map covering pull requests, merge requests, issues, comments and pipeline events, each routed to a named channel
- Who may manage subscriptions, and which GitLab tier includes the events you need, confirmed in writing
How we build
- Setup through the /github wizard or manual OAuth app and webhook creation, chosen per GitHub environment
- GitLab webhook and token configuration for SaaS or on-premises GitLab, with the network path from GitLab to Mattermost tested
- Test each event type end to end in a staging channel before production channels receive traffic
How we hand over
- Runbook covering OAuth app ownership, webhook secrets, rotation steps and where each credential is stored
- Channel and subscription inventory so administrators can see which repositories post to which channels
- Documented verification checklist your team repeats after Mattermost or GitLab upgrades, with results recorded
How we support
- Upgrade planning that follows Mattermost monthly releases or Extended Support Releases and GitLab required upgrade stops
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Retesting of integration events after each upgrade, so a broken webhook is found before a team notices it
