docs/production/requirements.md
To run a Zulip server, you will need:
For details on each of these requirements, see below.
The installer expects Zulip to be the only thing running on the
system; it will install system packages with apt (like nginx,
PostgreSQL, and Redis) and configure them for its own use. We strongly
recommend using either a fresh machine instance in a cloud provider, a
fresh VM, {doc}our Docker image <docker:index>, or a dedicated
machine. If you decide to disregard our advice and use a server that
hosts other services, we can't support you, but we do have some notes
on issues you'll encounter.
Ubuntu 22.04, Ubuntu 24.04, Ubuntu 26.04, Debian 12, and Debian 13
are supported for running Zulip in production. You can also
run Zulip on other platforms that support Docker using
{doc}our Docker image <docker:index>.
We recommend installing on the newest supported OS release you're comfortable with, to save a bit of future work upgrading the operating system.
If you're using Ubuntu, the Ubuntu universe repository must be enabled, which is usually just:
sudo add-apt-repository universe
sudo apt update
CPU and memory: For installations with 100+ users you'll need a
minimum of 2 CPUs and 4 GB RAM. For installations with fewer
users, 1 CPU and 2 GB RAM with 2 GB of swap is sufficient. We
recommend against using highly CPU-limited servers like the AWS t2
style instances for organizations with hundreds of users (active or
no).
Disk space: You'll need at least 10 GB of dedicated free disk space for a server with dozens of users. We recommend using an SSD and avoiding cloud storage backends that limit the IOPS per second, since the disk is primarily used for the Zulip database.
See our documentation on scalability below for advice on hardware requirements for larger organizations.
epmd, an Erlang service which does not support binding
only to localhost. Leaving this exposed will allow unauthenticated
remote users to determine that the server is running RabbitMQ, and
on which port, though no further information is leaked.zulip.example.com) that your users will use to
access the Zulip server. In order to generate valid SSL
certificates with Certbot, and to enable other
services such as Google authentication, public DNS name is simpler,
but Zulip can be configured to use a non-public domain or even an IP
address as its external hostname (though we don't recommend that
configuration).Zulip does not, itself, require SSH, but most installations will also require access to incoming port 22 for SSH access for remote access.
Your Zulip server will need an SSL certificate for the domain name it
uses. For most Zulip servers, the recommended (and simplest) way to
get this is to just use the --certbot option in the
Zulip installer, which will automatically get a certificate for you
and keep it renewed.
For test installations, an even simpler alternative is always
available: the --self-signed-cert option in the
installer.
If you'd rather acquire an SSL certificate another way, see our SSL certificate documentation.
Once you have met these requirements, see full instructions for installing Zulip in production.
This section details some basic guidelines for running a Zulip server for larger organizations (especially >1000 users or 500+ daily active users). These guidelines are conservative, since they are intended to be sufficient for a wide range of possible usage patterns that may not be applicable to your installation.
Zulip's resource needs depend mainly on 3 parameters:
In the following, we discuss a configuration with at most two types of
servers: application servers (running Django, Tornado, RabbitMQ,
Redis, Memcached, etc.) and database servers. Of the application
server services, Django dominates the resource requirements. One can
run every service on its own system (as {doc}our Docker deployment <docker:index> does) but for most use cases, there's little
scalability benefit to doing so. See deployment
options for details on installing Zulip with a
dedicated database server.
Dedicated database. For installations with hundreds of daily active users, we recommend using a remote PostgreSQL database, but it's not required.
RAM: We recommend more RAM for larger installations:
CPU: The Zulip application server's CPU usage is heavily optimized due to extensive work on optimizing the performance of requests for latency reasons. Because most servers with sufficient RAM have sufficient CPU resources, CPU requirements are rarely an issue. For larger installations with a dedicated database, we recommend high-CPU instances for the application server and a database-optimized (usually low CPU, high memory) instance for the database.
Disk for application server: We recommend using the S3 file uploads backend to store uploaded files at scale. With the S3 backend configuration, we recommend 50 GB of disk for the OS, Zulip software, logs and scratch/free space. Because uploaded files are cached locally, you may need more disk space if you make heavy use of uploaded files.
Disk for database: SSD disk is highly recommended. For installations where most messages have <100 recipients, 10 GB per 1M messages of history is sufficient plus 1 GB per 1000 users is sufficient. If most messages are to public channels with 10K+ users subscribed (like on chat.zulip.org), add 20 GB per (1000 user accounts) per (1M messages to public channels).
Example: When the Zulip development community server had 12K user accounts (~300 daily actives) and 800K messages of history (400K to public channels), it was a default configuration single-server installation with 16 GB of RAM, 4 cores (essentially always idle), and its database was using about 100 GB of disk.
Disaster recovery: One can easily run a warm spare application
server and a warm spare database (using PostgreSQL warm standby
replicas). Make sure the warm spare
application server has copies of /etc/zulip and you're either
syncing LOCAL_UPLOADS_DIR or using the S3 file uploads
backend.
Sharding: For servers with several thousand daily active users, Zulip supports sharding its real-time-push Tornado service, both by realm/organization (for hosting many organizations) and by user ID (for hosting single very large organizations).
Care must be taken when dividing traffic for a single Zulip realm between multiple Zulip application servers, which is why we recommend a hot spare over load-balancing for most installations desiring extra redundancy.
If you have scalability questions or are unsure whether Zulip is a fit for your use case, contact Zulip sales or support for assistance.
For readers interested in technical details around what features impact Zulip's scalability, this performance and scalability design document may also be of interest.