Spurred on by the huge success of tools such as WhatsApp and Telegram, increasing numbers of business users are now showing an interest in chat services as an alternative to email for internal company communication. Tools, bots, and plugins that integrate other applications directly into the chat forums are also useful. Office staff can discuss current business cases with coworkers in the team chat while a bot from the ticket system feeds information on currently open tickets and processing status.

Slack is currently one of the most popular chat services for businesses, partly because it integrates with more or less any commercially available business application and tool. However, as with all cloud applications, you must be careful: Confidential company communications end up somewhere in the Amazon cloud. Business users can choose the region in which they want to store their data and even which (other) country will store a backup, but basic organizational data and user profiles still end up on third-party servers.

Of course, you already know what's coming next at this point. If you love the convenience and functionality of tools like Slack but don't want to (or aren't allowed to) entrust your data to a cloud or a third party, you can always turn to self-hosted open source programs. In this article, I take a close look at the complicated setup and operation of the popular open source options Zulip [1], Mattermost [2], and Rocket.Chat [3] and discover how well these platforms integrate with other applications.

Functions and Features

A number of questions should be considered when looking for local chat groupware:

• Do clients exist for all required target platforms (web, desktop, mobile), and do they have push notifications?
• For which target platforms do ready-made plugins and bots exist?
• If no ready-made add-ons exist, how time-consuming is it to write your own and integrate them on the chat and application side?
• How secure is the data storage and backup of the platform?

Unlike earlier platforms such as the Internet Relay Chat (IRC) protocol or Network News Transfer Protocol (NNTP), modern chat groupware software no longer relies on proprietary binary protocols. All communication, including communication to the bots, relies on HTTPS. The chat server itself can hide behind an SSL-terminating proxy, which means that a chat environment does not require a dedicated IP address on the Internet, but runs on a hosted system or in the demilitarized zone (DMZ, a subnet that separates an internal network from the Internet) of the local data center behind a reverse proxy with name-based routing.

In security-relevant environments with an air gap (isolated network), self-hosted chat servers can also completely do without an Internet connection. They all work with the usual web application server architecture, involving a database server and a chat app, and the whole setup can be installed in the traditional way on a virtual machine (VM) or on a container platform such as Docker, Podman, or Kubernetes. I look at the advantages and disadvantages of each of these operating modes and try out various approaches.

Zulip

The Zulip chat server has been around longer than Slack, having first seen the light of day in 2012. The Zulip company offers both a software-as-a-service (SaaS) version in the cloud and commercial support for local setups. Although the community version is available at no charge, it also has no support. Technically and functionally, the commercial and the free versions are not different, and both have the full feature set.

Zulip requires a whole zoo of services on the back end. Redis, Memcached, and RabbitMQ team up with a PostgreSQL server for data storage. Memcached improves performance, especially in environments with many users, but Redis and RabbitMQ offer similar functionality, so choosing one of the two should be fine. The developers describe in the documentation why they decided not to consolidate the two services. The slightly more complex setup – especially in larger environments – is intended to distribute the load more evenly across services and improve performance.

Zulip can be set up along the classic approach (e.g., with a VM), although the vendor prefers an installation with containers and Docker. In the test environment for this article, I used a Linux, Ansible, Nginx, and Podman (LANP) setup, as described previously [4]. The Podman setup groups all the components as containers in a single pod and only shares one HTTP port with the outside world. The upstream Nginx reverse proxy takes care of SSL termination.

In principle, you just need to convert the Docker Compose file [5] provided by the vendor into an Ansible playbook (which I do not print here because of its sheer length), but with two changes: (1) Memcached tries to create a temporary directory in the current container, which will work in Docker with root privileges, but not in Podman; therefore, the Memcached container needs a persistent volume for the /home/memcache directory to run in Podman. (2) For Zulip to use HTTP behind a reverse proxy, you will need to edit the configuration file, because in the basic setup, the software tries to control the HTTPS protocol and integrate the certificates itself. Unfortunately, the Compose file does not envisage the Zulip configuration file being stored on a persistent volume. You need to add this option in the Ansible playbook:

volumes:
  - "/var/pods/zulip/zulip:/data:Z"
  - "/var/pods/zulip/etc:/etc/zulip:Z"

You can modify the zulip.conf configuration file in the host subdirectory (/var/pods/zulip/etc) to match by adding the lines

[application_server]
http_only = true

to transfer SSL termination to Nginx. You can then also customize the settings.py and zulip-secrets.conf configuration files to suit your organization's needs and to give Zulip access to a mail server. The software needs to be able to use SNMP to send messages with invitations for users. If you extend the mail setup to include an IMAP configuration, Zulip can receive email on its own addresses and add them to chat forums.

Zulip offers clients for all the popular client operating systems and mobile devices and runs in a browser, as well. In fact, all of the clients are basically just wrappers for a browser. The user interface (UI) in version 8.4 is tidy but looks a little old-fashioned with its 2010-ish frame and box look. Zulip comes with all the usual features, such as chat forums and private messaging. The bot and the plugins are where things start to heat up. Users with appropriate authorizations can add one or more bots to their profile that either send outgoing messages to webhooks or provide a webhook for incoming messages themselves.

Zulip supports a number of popular JSON formats from other services such as GitHub, GitLab, or Ansible. For example, users can create a Gitea webhook URL for one of their bots and then enter the URL in their Gitea repository. When events occur in the repository (e.g., commit or pull requests), Gitea then sends a message to the Zulip forum or directly to the user (Figure 1).

Figure 1: Incoming bots evaluate incoming messages with previously configured JSON parsers. The JSON formatter displays the raw format and helps you build your own bots.

The bot's account can also be used for external access by REST API. Outgoing bots transmit messages from the active forums to webhook URLs. Users can specify whether to use the Slack or Zulip format. If external tools have an incoming webhook for Slack, they will also work with Zulip. If you need more than the simple webhook and REST API functionality offered by the Zulip bots, you can also program your own bots in Python. The Zulip documentation describes how this works in detail.

Zulip provides a small management tool for housekeeping, but if the server is containerized, the tool requires some overhead. You can use it to reset passwords or create users without detouring with an invite mail. Theoretically, manage.py could also create a backup of your Zulip environment directly, but this only works correctly in a traditional VM setup with Postgres and Zulip running on the same system. In a containerized setup, the backup tool does not have access to the database server because it runs in a different container. The manage.py backup command will only work if you specify the --skip-db option, and you will also need to back up the database in the PostgreSQL container yourself.

The Zulip server is fast and easy to set up with Podman. The flexible bot system is ideal for anyone who wants to integrate the chat platform with other tools. The free open source version is fully featured.

Mattermost

Mattermost was originally created as a proprietary, in-house communication tool for a game development company. It was outsourced as an open source project in 2015 and has been maintained by Mattermost Inc. ever since; in fact, the company was founded specifically for this purpose and offers commercial support contracts for Mattermost installations and additional features that are not included in the open source version.

Mattermost only needs a PostgreSQL database and its own server for operation. The server could take care of SSL but prefers to hide behind an SSL-terminating reverse proxy; therefore, you can run Mattermost as a containerized solution on Docker, Podman, or Kubernetes. I used a classic VM in this example. The installation on CentOS Stream 9 is very simple, involving just two steps – database preparation [6] and service setup [7] – that take just a few minutes to complete. The Enterprise Linux (EL) setup uses a tarball image, which makes upgrading the server to new versions slightly more complex. The setup on Debian and Ubuntu is easier to manage, because a PPA repository for these platforms is available, and installation and upgrades are therefore easy with apt.

For a straightforward function test on the LAN, I did not use an HTTPS setup with proxy. HTTP access to port 8065 on the server was fine. As with Zulip, you only need a web browser to access the chat server. Clients for various desktop and cellphone platforms are also available. The Mattermost UI looks a little tidier and more modern than Zulip, although users do have to search through submenus for some functions, which are probably easier to find in the Zulip UI.

The system console allows you to manage the server and its functions, as well as teams and users. The mmctl admin command-line interface (CLI) tool is on the server itself. The premium functions that are only available to commercial users can also be found in the system console. They primarily include tools for integrating the Mattermost server with an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) user directory and the single sign-on services. Guest access with restricted rights for users from outside the organization is also unavailable in the open source version.