Configure developer mode by going to System Console > Environment > Developer, or by editing the config.json file as described in the following tables. Changes to configuration settings in this section require a server restart before taking effect.

Enable testing commands

Available in legacy Enterprise Edition E10/E20

Enable or disable the /test slash command.

  • true: (Default) The /test slash command is enabled to load test accounts and test data.

  • false: The /test slash command is disabled.

  • System Config path: Environment > Developer

  • config.json setting: ".ServiceSettings.EnableTesting": true",


Enable developer mode

Available in legacy Enterprise Edition E10/E20

Enable or disable developer mode.

  • true: (Default) Javascript errors are shown in a banner at the top of Mattermost the user interface. Not recommended for use in production.

  • false: Users are not alerted to Javascript errors.

  • System Config path: Environment > Developer

  • config.json setting: ".ServiceSettings.EnableDeveloper": true",


Enable client debugging

Available in legacy Enterprise Edition E10/E20

Enable or disable client-side debugging settings found in Settings > Advanced > Debugging for individual users.

  • true: Those settings are visible and can be enabled by users.

  • false: (Default) Those settings are hidden and disabled.

  • System Config path: Environment > Developer

  • config.json setting: ".ServiceSettings.EnableClientPerformanceDebugging": false",


See the client debugging documentation to learn more.

Allow untrusted internal connections

Available in legacy Enterprise Edition E10/E20

Limit the ability for the Mattermost server to make untrusted requests within its local network. A request is considered “untrusted” when it’s made on behalf of a client.

  • System Config path: Environment > Developer

  • config.json setting: ".ServiceSettings.AllowedUntrustedInternalConnections": "",


This setting is a whitelist of local network addresses that can be requested by the Mattermost server. It’s configured as a whitespace-separated list of hostnames, IP addresses, and CIDR ranges that can be accessed.

Requests that can only be configured by System Admins are considered trusted and won’t be affected by this setting. Trusted URLs include ones used for OAuth login or for sending push notifications.

The following features make untrusted requests and are affected by this setting:

  • Integrations using webhooks, slash commands, or message actions. This prevents them from requesting endpoints within the local network.

  • Link previews. When a link to a local network address is posted in a chat message, this prevents a link preview from being displayed.

  • The local image proxy. If the local image proxy is enabled, images located on the local network cannot be used by integrations or posted in chat messages.

Some examples of when you may want to modify this setting include:

  • When installing a plugin that includes its own images, such as Matterpoll, you’ll need to add the Mattermost server’s domain name to this list.

  • When running a bot or webhook-based integration on your local network, you’ll need to add the hostname of the bot/integration to this list.

  • If your network is configured in such a way that publicly-accessible web pages or images are accessed by the Mattermost server using their internal IP address, the hostnames for those servers must be added to this list.

Warning: This setting is intended to prevent users located outside your local network from using the Mattermost server to request confidential data from inside your network. Care should be used when configuring this setting to prevent unintended access to your local network.


  • The public IP of the Mattermost application server itself is also considered a reserved IP.

  • Use whitespaces instead of commas to list the hostnames, IP addresses, or CIDR ranges. For example:,, or

  • IP address and domain name rules are applied before host resolution.

  • CIDR rules are applied after host resolution, and only CIDR rules require DNS resolution.

  • Mattermost attempts to match IP addresses and hostnames without even resolving. If that fails, Mattermost resolve using the local resolver (by reading the /etc/hosts file first), then checking for matching CIDR rules. For example, if the domain “” resolves to the IP address, a webhook with the URL can be whitelisted using, or, but not