# Zulip: topic-based team chat you can self-host

> Zulip is an Apache-2.0 team chat server written in Python, built around topic threads rather than a single channel stream. It suits teams that need asynchronous conversations to stay readable, and it asks for real server administration in return.

**zulip/zulip** — Zulip server and web application. Open-source team chat that helps teams stay productive and focused.

- Repository: https://github.com/zulip/zulip
- Website: https://zulip.com
- Stars: 25,964 · Forks: 10,307
- Language: Python
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/zulip-zulip

## The problem Zulip solves: conversations that outlive a meeting

Most chat tools give you channels and a single linear scroll. A channel with forty people and three simultaneous discussions becomes unreadable within a day, and the fix people reach for is to open more channels, which fragments the history further. Zulip's answer is topic-based threading: every message belongs to a channel and a topic, and the client shows topics as separate conversations. The README describes this as combining "the best of email and chat", and the project's own framing is that it is designed for both live and asynchronous conversations. The practical effect is that a topic can be read hours later without wading through unrelated chatter, which is the property that makes long-running projects work in a chat tool.

The audience is teams whose work is decided in writing over days rather than in a burst of messages. The README names Fortune 500 companies, leading open source projects and thousands of other organizations, and points to a case study about Rust. Open source projects are a natural fit because contributors sit in different time zones and cannot attend a synchronous discussion. A team that only ever talks in real time, in one room, all day, gets less from the threading model.

## How the server is put together

The repository layout tells you most of the architecture. zerver/ holds the Django application that serves the API and the web client, zproject/ holds the Django project settings, and zilencer/ is a separate app for the push notification and remote-support side. The web client lives in web/ and is built with pnpm, with package.json pinning pnpm 11.22.0 as the package manager and React, Babel and webpack in the dependency list. Python dependencies are declared in pyproject.toml under a prod dependency group, and set requires-python to ">=3.10".

Those dependencies map onto the moving parts of a running server. Django 5.2 with psycopg2 talks to PostgreSQL. pika talks to RabbitMQ, which carries events between the Django processes and the Tornado-based push system that keeps clients updated. python-binary-memcached and django-bmemcached handle caching, and redis is present as well. pyvips does image processing and thumbnailing, boto3 covers S3 uploads, firebase-admin and aioapns handle Android and iOS push notifications, and python-ldap plus django-auth-ldap cover LDAP authentication. That is a multi-service deployment, not a single process you start and forget. It is the main reason self-hosting Zulip is a different commitment from installing a desktop chat client.

The frontend is not a thin wrapper. The dependency list includes @uppy/tus for resumable uploads, @zxcvbn-ts for password strength, altcha, flatpickr, and emoji-datasource-google and emoji-datasource-twitter for emoji data. The web client is a substantial application in its own right, which is consistent with the README's claim that the code is "thoughtfully tested" and that the project has written 185K words of contributor documentation.

## Installing Zulip and sending a first message

The README gives the supported routes rather than a single command. It states that you can self-host Zulip directly on Ubuntu or Debian Linux, in Docker via the docker-zulip repository, or with prebuilt images for Digital Ocean and Render. It also points to the self-hosting page at zulip.com/self-hosting/ for the details. If you only want to use Zulip, the README lists Zulip Cloud hosting options and notes that the project sponsors free Zulip Cloud Standard for hundreds of organizations, including fellow open source projects. The README does not reproduce the installer commands, so the exact invocation belongs to that self-hosting page, not to this article.

What the repository does show is the shape of the codebase you would be deploying. The Python side is a Django project managed through manage.py, and the dependency group in pyproject.toml is what a deployment installs:

```toml
[project]
name = "zulip-server"
version = "0.1.0"
requires-python = ">=3.10"

[dependency-groups]
prod = [
  "django[argon2]==5.2.*",
  "psycopg2",
  "pika",
  "tornado",
]
```

That snippet is abridged from the real file, which continues with LDAP, S3, push notification and image processing packages. The point of reading it before you install is to see that RabbitMQ, PostgreSQL, memcached and Redis are not optional extras bolted on later; they are the runtime the application expects.

On the frontend, package.json declares the package manager explicitly, which matters if you build the web client yourself rather than using a release tarball:

```json
{
  "private": true,
  "packageManager": "pnpm@11.22.0+sha512.1ff870c4c6133dfd88fb2afc46dd13d47f09c9794b438c6fdb47ca98caf3bc16381ee0be93a091b8e3824cf01f889f46d7d9e20910fb0be1ab0fb5baa80dd621",
  "type": "module"
}
```

The pinned hash means pnpm will refuse a different pnpm build, so install the version the file names instead of whatever your system ships. After a successful install, the first real use is the one the README recommends to anyone evaluating the product: it says the best way to see Zulip in action is to drop by the development community at chat.zulip.org, with no account required. Doing that before you provision a server tells you whether the topic model fits how your team talks, at no cost.

## Where Zulip is the wrong tool

The threading model is the product, and it is also the friction. People arriving from Slack or Discord expect to type into a channel and see their message in one continuous stream. In Zulip they must choose a topic, and a team that treats topics as an afterthought ends up with a channel full of one-message topics, which is worse than a plain channel. The documentation is explicit that the approach is unusual; the README links to a "why Zulip" page precisely because the model needs explaining. If your organization will not adopt the convention, the software's main advantage disappears.

The second limit is operational. Nothing in the repository suggests a single-binary deployment. A running server expects PostgreSQL, RabbitMQ, memcached, Redis and a Tornado push process, plus the Django application, and pyproject.toml lists S3, LDAP, Firebase and APNs integrations that each need configuration if you use them. A small team without anyone comfortable administering those services is better served by Zulip Cloud or by a chat tool with a lighter server footprint. The README itself separates "running a Zulip server" from "using Zulip without setting up a server" as two distinct paths, which is a fair signal about the intended audience for each.

A third consideration is that the README does not document rollback or downgrade for a self-hosted server. If you need a documented reversal path before you upgrade, that documentation is not in the README, and you should find it before you rely on it.

## Zulip compared with Slack and Discord

The search data shows people asking whether Zulip is better than Slack and whether it is like Discord, so the honest answer is that the three organize conversations differently. Slack and Discord both center on channels with a single chronological stream; threads exist in both but are secondary, and the default reading experience is the channel scroll. Zulip inverts that: the topic is the unit you read, and the channel is a container for topics. That is the "best of email and chat" claim in the README, and it is the difference that determines whether the tool fits.

The other axis is deployment. Slack and Discord are hosted services; you use them, you do not run them. Zulip is distributed under Apache-2.0 and the README's first self-hosting sentence is about installing it on your own Ubuntu or Debian machine, in Docker, or from Digital Ocean and Render images. That means the trade is not only about threading. With Zulip you take on the server, and in exchange you get the source, the ability to run it on your own hardware, and no dependency on a vendor's continued goodwill. Teams that want chat to be someone else's operational problem should weigh that honestly rather than assuming self-hosting is strictly better.

## Maintenance, releases and the licence

The repository is not archived, and the last push was on 2026-09-19, so the project is under current development by any reasonable reading. The release cadence is visible in the tags: Zulip Server 12.0 on 2026-04-27, 12.1 on 2026-06-26, and 12.2 on 2026-08-10. Roughly two months between minor releases means a self-hoster who tracks upstream is looking at several upgrade windows a year, and the README does not describe an automated upgrade path or a rollback procedure, so plan the upgrade process as part of the deployment rather than after it.

The licence is Apache-2.0, stated in the README and present as a LICENSE file at the repository root, with a NOTICE file alongside it. Apache-2.0 permits commercial and private use and modification, and it includes an explicit patent grant, which is often the reason organizations prefer it to a copyleft licence. It also requires that you preserve the licence and notice files and state significant changes. That is a summary of the licence text, not legal advice; if your organization has policies about redistributing modified software, have someone read LICENSE and NOTICE rather than relying on this paragraph. The README also points to a support page listing ways to fund the project, including financial contributions.

## Conclusion

Adopt Zulip if your team's conversations outlive a single working session and you want the server on your own hardware, with Ubuntu or Debian as the documented path. Do not adopt it if nobody on the team will own a PostgreSQL, RabbitMQ, Redis and memcached deployment, or if you need a chat tool that a non-technical admin can run unaided. Before committing, read the self-hosting page and confirm which of the documented install routes matches your infrastructure, then check the 12.2 release notes against the version you plan to run.

## FAQ

### Is Zulip better than Slack?

The README does not rank them, but it does describe a real difference in approach: Zulip organizes every message into a channel and a topic, and the README frames this as combining the best of email and chat for both live and asynchronous conversations. Slack is a hosted service you use rather than run, while Zulip can be self-hosted on Ubuntu or Debian, in Docker, or from Digital Ocean and Render images. Which is better depends on whether the topic model fits how your team talks.

### What is Zulip used for?

Zulip is an organized team chat application built around topic-based threading, intended for both live and asynchronous conversations. The README says Fortune 500 companies, leading open source projects and thousands of other organizations use it, and points to a case study about the Rust project.

### Is Zulip like Discord?

Both are chat applications, but the README only describes Zulip's model in detail: messages belong to channels and topics, and the project presents this as the property that makes it suitable for asynchronous work. Discord is not discussed in the README, so a direct comparison is not something the documentation supports.

### How much does Zulip cost?

The README does not list prices. It states that Zulip is distributed under the Apache-2.0 licence and can be self-hosted, and that Zulip Cloud hosting options exist, with the project sponsoring free Zulip Cloud Standard for hundreds of organizations including fellow open source projects. The plans page linked from the README is where pricing would be.

### How do I install the Zulip server on Ubuntu?

The README states that you can self-host Zulip directly on Ubuntu or Debian Linux, in Docker via the docker-zulip repository, or with prebuilt images for Digital Ocean and Render, and it links to zulip.com/self-hosting/ for the details. The README does not reproduce the installer commands, so use that page rather than improvising.

### What is Zulip written in?

The server is a Python project: pyproject.toml declares the package zulip-server, requires Python 3.10 or newer, and lists Django 5.2, psycopg2, pika, tornado and other Python dependencies. The web client is a separate JavaScript and TypeScript application built with pnpm and webpack, with React and Babel in its dependency list.

## Sources

- [License: Apache-2.0](https://github.com/zulip/zulip/blob/main/LICENSE)
- [Project website](https://zulip.com)
- [README](https://github.com/zulip/zulip/blob/main/README.md)
- [Releases](https://github.com/zulip/zulip/releases)
- [zulip/zulip on GitHub](https://github.com/zulip/zulip)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zulip-zulip