Chatops with Zulip
Build a scalable, open-source ChatOps pipeline using Zulip — with a practical guide and custom chatbot integration
Chatops with Zulip
Build a scalable, open-source ChatOps pipeline using Zulip — with a practical guide and custom chatbot integration
Photo by Volodymyr Hryshchenko on Unsplash
Introduction
ChatOps brings your operations, development, and product workflows into a shared chat interface — making deployments, version tracking, and collaboration faster and more transparent. While tools like Slack and Mattermost are popular, they often lack the flexibility and privacy of self-hosted solutions. In this guide, we explore why Zulip is a strong choice for ChatOps, compare it to similar platforms, and walk through setting it up with Docker alongside a custom CI/CD chatbot to streamline your DevOps processes.
Zulip vs. Slack vs. Mattermost vs. Rocket.Chat
Zulip is an enterprise-grade messenger (similar to Slack or Mattermost) that can help you create your own on-premises messaging platform. In the following table, I’ve compared Zulip with its competitors:
Feature | Zulip | Slack | Mattermost | Rocket.Chat
-----------------------|---------------------|----------------------|--------------------------|---------------------
Threading Model | ✅ Streams + Topics | ⚠️ Optional, messy | ✅ Slack-style | ⚠️ Basic threads
Real-time Chat | ⚠️ Async-first | ✅ Excellent | ✅ Excellent | ✅ Excellent
Open Source | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes
Self-Hosting | ✅ Full support | ❌ Not available | ✅ Supported | ✅ Supported
Free Plan Limit | ✅ No user limit | ⚠️ Limited history | ❌ 250-user/ldap paywall | ❌ 50-user cap
LDAP Integration | ✅ Free + built-in | ❌ Paid only | ❌ Paid only | ⚠️ Limited support
RTL Support | ✅ Great RTL | ⚠️ Minimal | ⚠️ Not great | ❌ Poor RTL
UI/UX Polish | ⚠️ Basic UI | ✅ Sleek + polished | ⚠️ Improving | ✅ Polished, cluttered
Dev Tooling | ✅ APIs + bots | ✅ SDKs + APIs | ✅ DevOps-friendly | ✅ API + integrations
Resource Usage | ⚠️ Moderate-heavy | ✅ Cloud optimized | ✅ Moderate | ⚠️ Heavy at scale
Best Use Case | Async, open teams | Corporate workflows | Secure team chat | Community servers I’ve summarized the table above, and I believe it can help inform your decision-making:
- Zulip: No hard user limit in self-hosted, great LDAP support, good RTL rendering, solid open-source support — best choice overall.
- Rocket.Chat: Limited to 50 users on free tier, and self-hosted still requires paid upgrade for more; poor RTL support.
- Mattermost: LDAP integration is behind paywall, community workarounds outdated, making it unsuitable for free/enterprise-grade setups.
- Slack: Good UI and features, but not open-source and self-hosting not possible.
Zulip Installation
You can use the cloud-based Zulip messenger without installing it on your own servers, but if you care about data ownership and privacy, you can host it yourself. Typically, you’ll need 2 CPU cores and 4 GB of memory for up to 50 users, and 4 CPU cores with 8 GB of memory for 50–100 users. I’ve prepared the following docker-compose.yaml file to help you install it:
[https://gist.github.com/mlkmhd/8b4b24e1cea3e8a49ef16382c6bd458e](https://gist.github.com/mlkmhd/8b4b24e1cea3e8a49ef16382c6bd458e)
you can install it using the following commands:
$ curl https://gist.githubusercontent.com/mlkmhd/8b4b24e1cea3e8a49ef16382c6bd458e/raw/dccb2a494f26eedf7e0e9ccc811f1a5571b37615/gistfile1.txt -o dock
er-compose.yaml
$ docker-compose up -dWhy ChatOps?
Using ChatOps, you can streamline your operations by centralizing them into a single place — like a chat channel. It’s like turning your chat into a unified terminal for interacting with all your tools. This approach makes operations faster, easier, and more transparent, allowing team members to collaborate directly within the conversation.
ChatOps for CI/CD
In the following diagram, I’ve illustrated a ChatOps workflow that facilitates the CI/CD pipeline across different team roles:
As shown in the diagram above, the developer, product owner, and DevOps engineer collaborate in the process of building and deploying a specific version to the production environment. The following steps take place:
- Developer: Triggers the CI pipeline to build a new version.
- Chat Server: a message to a release channel receives to notify the team about the new release.
- Product Owner: Sends a deployment request for a specific version to a specific environment via the chat channel.
- ChatBot server: Reads the command (messages starting with
/) and creates a pull request accordingly. - Devops engineer: Reviews and merges the pull request to update the target environment.
- CD pipeline: Once changes are merged into the CD repository, the pipeline executes to apply the new version to the Kubernetes cluster.
You can see all the steps in a simple ChatOps messaging flow in the screenshot above. I’ve shared the source code for the ChatOps chatbot in the following GitHub repository:
Using a hierarchical model in GitLab to manage your CD repositories can make your process easier. I’ve written another document about structuring CD repositories in GitLab based on your deployment environments. You can find it here:
Chatops Commands
In my Zulip chatbot, I’ve defined several commands such as /deploy and /deployed-version. You can see the full list in the following file:
When you send /help to the chatbot, it returns the following output to help users access the bot manual:
Available commands:
1- prints list of commands
/help
2- deploy a version to an environment:
/deploy
env: [dev, sandbox, prod]
version: 1.2.3
3- prints the current deployed version in an environment:
/deployed-version
env: [dev, sandbox, prod]
4- prints the list of available versions exist in the repository:
/versions
5- prints the list of environment:
/envs
6- replicate a package from an repository to another repository
/replicate-package {source} {destination} {version}Unfortunately, Zulip currently does not support adding chatbot commands directly to a channel’s suggestion list, but I hope this feature will be available in the future. Zulip supports two models for receiving new messages from the server: the pull-based model and the push-based model. Here are their pros and cons:
push-based model
It’s simple and easy to implement, but you need to expose your chatbot API to a public IP because Zulip’s egress rules do not allow sending requests to webhooks that resolve to private IPs.
pull-based model
It’s a bit harder to implement, but it doesn’t require a public IP. Your chatbot server can connect to the chat server, continuously pull new messages in an infinite loop, and store the last received message ID in local storage to keep track of the channel’s last checkpoint.
You can find all the diagrams used in this article in the following GitHub repository:
Conclusion
Zulip stands out as a practical, open-source platform for implementing ChatOps — offering a powerful threading model, strong self-hosting support, and seamless integration with custom bots. Compared to Slack, Mattermost, and Rocket.Chat, it provides more flexibility for privacy-conscious teams and a solid foundation for building CI/CD workflows directly into your chat environment. With a lightweight deployment via Docker and customizable chatbot commands, Zulip empowers teams to streamline operations, boost collaboration, and take full control of their infrastructure — all from within a chat interface.
Feedback
If you have any feedback or suggestions for improving my code, please leave a comment on this post or send me a message on my LinkedIn.
메타데이터
- post_id
- 030e43e14652
- slug
- chatops-with-zulip-030e43e14652
- url
- https://itnext.io/chatops-with-zulip-030e43e14652
- canonical_url
- https://itnext.io/chatops-with-zulip-030e43e14652
- author_url
- https://medium.com/@mallakimahdi
- status
- ok
- fetched_at
- 2026-07-19 00:15:46
