Self-host Zulip or use Zulip Cloud: when each model fits
Choose Zulip Cloud if you want the vendor to run the server and accept its hosting location and data handling terms. Choose self-hosted Zulip if your policy requires chat history, uploads and user records to stay inside your own cloud account, data center or air-gapped network. Both run the same Apache-2.0 software, so the decision is about control, operating effort and cost, not features. Zulip's self-hosting page states that the self-hosted server is the same software Zulip Cloud customers use, with no open core restrictions, so SAML, LDAP and custom roles do not require a paid plan on your own server.
Zulip Cloud suits teams that have no hard residency rule, no internal staff for database upgrades, backups and patching, and no need to control the server's network path. Self-hosting suits organizations where an auditor or regulator needs to see where messages are stored, where identity lives in your own directory, or where the chat must run during an outage of a public service. Confirm first which data classes the chat will carry, whether your regulator or contracts restrict where message content and attachments may be stored, and who on your team will own upgrades and restores. Ask the Zulip sales team to confirm the Cloud hosting regions and data processing terms in writing, since those details decide the Cloud option before any price comparison.
Self-hosting moves cost from a subscription to labor and infrastructure. You pay your own hosts, storage and staff time, and you choose whether to buy a paid plan. Zulip's plans page lists per-user prices for the self-hosted Basic and Business plans, and those prices, not the software license, determine whether push notifications for more than 10 users are included. Before deciding, price the recurring work: operating-system and Zulip upgrades, PostgreSQL maintenance, backup testing and on-call coverage. Ask any implementation partner for a written scope covering these tasks, plus the one-time migration work from Slack, Mattermost or Rocket.Chat if your history must follow you, and confirm the current plan prices directly on the Zulip plans page.
How Zulip Cloud and self-hosted Zulip compare on the factors that decide the purchase
This table sets Zulip Cloud against self-hosted Zulip across the factors that usually decide the purchase, from license and plan prices to push notifications and who runs the server. Read each row as a question to put to Zulip and to your own platform team, since several Cloud limits and residency details are not covered by the facts available here. The main takeaway is that the software is the same on both, so the choice turns on operations, data location and plan economics.
| Factor | Zulip Cloud | Self-hosted Zulip |
|---|---|---|
| Software license | Same Zulip server software, licensed under Apache-2.0 | Apache-2.0, the same software Cloud customers run |
| Feature availability | Cloud customers use the same software with no open core restrictions | SAML, LDAP and custom roles available without a paid plan, per Zulip's self-hosting page |
| Published plan prices | Confirm current Cloud plan prices with Zulip | Community free; Basic $3.50 per user per month billed monthly; Business $6.67 per user per month billed annually or $8 billed monthly (25-user minimum); Enterprise custom |
| Mobile push notifications | Confirm the push notification terms for your Cloud plan with Zulip | Community limits push to 10 users for most organizations; Basic and higher include unlimited mobile notifications |
| Storage and search limits | Confirm storage and search limits for your plan with Zulip | Set by your own servers, disks and database; sizing depends on your team's message and file volume |
| Data location | Confirm hosting regions and data residency with Zulip | You choose where the server and its database run, including your own data center or cloud account |
| Who operates the server | Zulip operates the hosted service | Your team installs, upgrades, backs up and secures the server, or a partner does under contract |
| Import from other chat tools | Confirm import options for your workspace with Zulip | Zulip's help center documents importing from Slack, Mattermost and Rocket.Chat |
What control over data location and access changes for your compliance work
Hosting Zulip yourself moves data location, server access and log custody into your own control, while Zulip Cloud shifts those duties to the vendor under its contract. Each card below is a control area to map against your own scope before you choose a model, because an auditor will test the controls you actually operate.
Data location and residency
On Zulip Cloud, the provider decides where messages and uploads are stored, so you need to ask for that location in writing and confirm it covers backups. On your own servers, location follows your infrastructure choice, whether a data center, a private cloud account or an air-gapped network. Document each copy of the database, uploads and backups, including any offsite replica, and confirm that the chosen hosting region meets your residency rules.
Administrator access to servers and logs
Self-hosting makes your team the only operator with root access, database access and log files, so separation of duties must be designed rather than assumed. Decide who can reach the host, who can read the database and who can export message data, and record those roles. On Zulip Cloud, your administrators control workspace settings but not the underlying infrastructure, so ask the vendor how staff access to customer data is limited and logged.
Identity integration with SAML and LDAP
Zulip's production documentation covers SAML with IdP-initiated SSO and Single Logout, plus LDAP including Active Directory data synchronization. On a self-hosted server, you configure these yourself, so the identity provider, the sync schedule and the deprovisioning path are your evidence. Confirm that account removal in your directory actually ends Zulip sessions, and test it before the assessment window opens.
SCIM and IdP setup guides
Zulip's documentation covers SCIM and setup guides for Keycloak and Authentik as SAML identity providers. Provisioning through SCIM is one of the controls auditors ask about because it governs joiners, movers and leavers. Ask whether your chosen plan and version include the SCIM feature you need, and keep the IdP configuration under change control on your side.
Audit trail and evidence collection
Auditors look for logs of administrative actions, access reviews and data export events. On a self-hosted server, you must decide where those logs are stored, how long they are kept and who can alter them, then forward them to a location outside the chat server. Zulip Cloud customers depend on the export and audit features the vendor exposes, so test what evidence you can pull before you rely on it.
What DeployOpen and auditors each do
DeployOpen plans, hardens, documents and prepares the controls and evidence for a self-hosted Zulip deployment, but it does not issue audit reports, attestations or certifications. Independent auditors or certification bodies decide whether either Zulip Cloud or a self-hosted server meets a framework, based on your defined scope. Agree the scope, the systems in it and the evidence set in writing before work starts.
Which hosting model fits your team's situation
If your rules dictate where messages and uploaded files may be stored, or who may administer the systems holding them, self-hosting gives you direct control over the servers, network paths and backups. Zulip Cloud keeps that control with Zulip, so the question becomes whether its hosting location and operational access meet your obligations. Self-hosting moves that responsibility to your team, which is a trade you should make deliberately.
- Location control: You choose the data center, cloud region or on-premises rack where the server and its database run.
- Access control: You decide who holds root, database and backup access, and you can log it under your own change process.
- Identity integration: The self-hosted server includes SAML, LDAP and SCIM capabilities without a paid plan, which matters if your identity provider is the authority for access.
- Evidence: You own the logs, configuration and backup records that an assessor will ask for.
- Audit posture: Self-hosting does not make a deployment compliant on its own; an independent auditor or certification body makes that determination.
Confirm with Zulip, in writing, where Zulip Cloud stores data and which subprocessors are involved, and confirm in your own environment which regulations and data classes apply before you choose.
A small team that wants chat working on day one, without owning a server, usually gets more value from Zulip Cloud. The main cost of self-hosting is recurring operating work: applying upgrades, watching disk and database growth, renewing certificates, testing backups and restoring them. Those tasks do not shrink because the team is small, and they fall on the same few people who run everything else.
- Setup: Cloud removes the need to provision Linux hosts, a database and a reverse proxy before anyone can post a message.
- Upgrades: Zulip operates the hosted service, so you do not schedule server version upgrades yourself.
- Staffing: A single administrator covering chat in addition to other duties is a common failure point for self-hosted tools.
- Cost model: Cloud pricing is per user, and the published plan terms should be compared with your headcount and the features you need.
- Exit path: Zulip documents importing data from Slack, Mattermost and Rocket.Chat, which applies in either direction if you later move.
Confirm current Cloud plan terms, storage and search limits on the Zulip plans page before you size the team.
If your organization already runs Linux servers, a Docker platform or Kubernetes clusters with backup, monitoring and patching standards, self-hosted Zulip fits into that operating model rather than creating a new one. Zulip supports direct installation on Ubuntu or Debian Linux, deployment in Docker through docker-zulip, and prebuilt images for DigitalOcean and Render. The choice between those routes depends on what your platform team already supports.
- Direct install: Suits teams that manage hosts with configuration management and want the server on a supported Ubuntu or Debian base.
- Docker: The docker-zulip project packages the server for teams that standardize on containers.
- Prebuilt images: The DigitalOcean and Render images reduce early setup but still leave you responsible for ongoing operation.
- Identity and automation: Your existing LDAP, SAML or SCIM sources can be connected to the server rather than managed separately.
- Ownership: Your platform team carries upgrades, database tuning and incident response for the chat service.
Confirm with the Zulip production documentation which Linux releases, Docker setup and database versions match your standards before you adopt a route.
Mobile push notifications are a plan-dependent feature on self-hosted Zulip, and this is the tab where the numbers matter most. Zulip's free self-hosted Community plan includes all features but limits mobile push notifications to 10 users for most organizations. Above that, you need a paid plan or must accept a different notification model, so the user count drives the decision.
- Community plan: Notifications work for up to 10 users for most organizations, which suits small pilots.
- Basic plan: Published at $3.50 per user per month billed monthly, with unlimited mobile notifications.
- Business plan: Published at $6.67 per user per month billed annually or $8 billed monthly, with a 25-user minimum, and adds email and chat support for SAML, AD/LDAP sync and data exports.
- Enterprise: Pricing is custom, so request a written quote for your scope.
- Cloud comparison: Compare the per-user cost of a self-hosted paid plan against Zulip Cloud pricing for the same headcount.
Confirm with Zulip which notification terms apply to your organization's size and whether your user count qualifies for any exemption.
Why push notification limits and SAML features matter more than the license
The license is the same for both paths, so the decision turns on what a self-hosted server gives you for free and what it does not. Zulip's self-hosting page says the self-hosted server is the same software Zulip Cloud customers use, with no open core restrictions, so SAML, LDAP and custom roles are available on a self-hosted server without a paid plan. Your identity team can wire SAML single sign-on to Keycloak or Authentik, or run LDAP and Active Directory synchronization, on the free tier. What you pay for on the self-hosted side is the infrastructure and the operating effort, not the security features.
The constraint that matters most is mobile push notifications. The free Community plan includes all features but limits mobile push notifications to 10 users for most organizations. If your workforce uses the Zulip mobile app across more than that group, the other users will not get push alerts unless you move to a paid plan. The Basic plan, published at $3.50 per user per month billed monthly, removes that limit with unlimited mobile notifications. Model the cost against your actual headcount that needs push, and confirm the current eligibility terms on the Zulip plans page before you commit.
Business is the tier that adds the administrative controls most regulated teams ask about. Per the Zulip plans page, it is published at $6.67 per user per month billed annually or $8 billed monthly, with a 25-user minimum, and adds email and chat support for SAML, AD/LDAP sync and data exports. Note that the self-hosted paid plans are published for self-hosted use, so confirm the Zulip Cloud price and included features on the same plans page rather than assuming they match. Ask your vendor to confirm in writing which tier covers support for your identity provider and whether a support response applies to your server.
What your team runs in each model
This table lists the recurring duties of running Zulip, and who performs each one on Zulip Cloud versus a self-hosted server. Read it by matching each row to your own constraints, such as release cadence, identity setup and where your data must stay, since those conditions decide how much work lands on your team.
| Operating duty | Zulip Cloud | Self-hosted Zulip |
|---|---|---|
| Installation and hosting | Zulip operates the servers; your team configures the organization | Your team installs on Ubuntu or Debian, in Docker or on a prebuilt image, and keeps the host running |
| Upgrades across releases (for example 12.0 to 12.3) | Zulip applies upgrades to the hosted service | Your team plans and applies each server release, such as the move from 12.0 (April 27, 2026) to 12.3 (September 21, 2026), and tests it first |
| Backups and restore | Handled by Zulip as part of the hosted service; confirm recovery targets in writing | Your team owns database, file upload and configuration backups, and tests restores |
| Identity configuration (SAML, LDAP, SCIM) | Configured through Zulip with your identity provider; confirm which options your plan includes | Your team configures SAML, LDAP or Active Directory sync and SCIM against your own identity provider |
| Mobile push notifications | Covered by the plan you buy; confirm limits for your user count | Free Community plan limits push to 10 users for most organizations; paid Basic removes that limit |
| Data retention and exports | Set by Zulip's hosted terms and your plan; confirm export and deletion procedures | Your team sets retention policy, runs exports and manages deletion on your own storage |
| Monitoring and incident response | Zulip operates the service; your team handles user-side issues and escalations | Your team monitors availability, logs and capacity, and responds to incidents on its own schedule |
Moving between Zulip Cloud and your own server
This sequence moves an existing Zulip organization from Zulip Cloud to a server you run, or back again, with identity, data, notifications and the old instance each handled in a set order. Each step ends with a check you can confirm before the next one starts.
Confirm the target plan and identity setup
Decide which direction the move goes and which plan the destination needs. On the self-hosted side, the Community plan includes every feature but limits mobile push notifications to 10 users for most organizations, while Basic adds unlimited mobile notifications at $3.50 per user per month billed monthly, and Business lists $6.67 per user per month billed annually or $8 billed monthly with a 25-user minimum, according to Zulip's plans page. Confirm with Zulip which plan covers your user count and which identity provider you will use, since SAML, LDAP and SCIM setups differ. Done when a written plan decision and an identity design sit in your change record.
Stand up the destination and test identity
The platform administrator builds the destination realm, whether that is a self-hosted server installed on Ubuntu or Debian, through Docker, or from a prebuilt image, and connects it to the identity provider. Zulip's production documentation covers SAML with IdP-initiated SSO and Single Logout, LDAP including Active Directory synchronization, and SCIM, with setup guides for Keycloak and Authentik. Test with a small group of pilot accounts, including a deprovisioning test. Done when pilot users sign in, roles map correctly and a disabled account loses access.
Export and import the data
Zulip's help center documents importing from Slack, Mattermost and Rocket.Chat, so if your history comes from one of those platforms, follow the matching import guide and run it against a test realm first. For a Zulip-to-Zulip transfer, the steps are not covered by the documentation supplied for this page, so ask Zulip to confirm the supported method, the data it includes, and any limits before you plan around it. Verify channel names, topic history, user mapping and attachments on the destination. Done when a sample of old conversations reads correctly and the import log shows no unresolved errors.
Check search and storage limits on the destination
Before users arrive, confirm how much storage, file history and search capacity the destination gives you. On Zulip Cloud, the hosted service manages these limits for you, while on a self-hosted server you size disk, backups and the search index yourself, so ask Zulip to confirm the current limits for each plan. Record the expected growth from the imported history so storage is sized before cutover, not after. Done when the capacity figures and your backup target are written down and tested with a restore.
Reconfigure mobile push notifications
Mobile push notifications depend on the plan and on how the server reaches Zulip's push relay, so configure them as a separate step and do not assume they carry over. Check that your user count matches the notification entitlement on the chosen plan, since the Community plan limits push notifications to 10 users for most organizations. Ask users to sign out and sign in on the mobile app after cutover so the device registers with the new server. Done when a test device on each platform receives a notification from a test topic.
Cut over users and announce the change
Pick a cutover window, freeze new activity on the old instance, run a final incremental import if your method supports one, and point users to the new URL. Users change their login and mobile app server address, and admins update bots, integrations and webhooks to the new endpoint. Keep the old instance read-only for a set period you agree with your team, so people can check old history. Done when the admin inventory shows every bot and integration pointing at the new server and a sample of users have signed in without help desk tickets.
Decommission the old instance
Once the read-only period ends and you have a verified backup of the old data, remove the old instance or close the Cloud organization according to your records policy. Confirm with Zulip how the old organization's data is deleted or exported before you close it, and record the deletion in your asset register. Revoke old SSO clients, API keys and service accounts so no path back to the retired instance remains. Done when the old endpoint no longer responds, the backup is catalogued and the access review confirms the old credentials are gone.
Questions buyers ask before choosing between Zulip Cloud and self-hosted Zulip
What drives the cost of Zulip Cloud compared with self-hosted Zulip?
Cloud costs are a per-seat subscription that Zulip bills, while self-hosted costs split between the software and the people who run it. The free self-hosted Community plan includes all features, so the license line is zero, but you pay for servers, backups, upgrades, monitoring and administrator time. Per-user prices for the self-hosted Basic and Business plans are published on the Zulip plans page, with Business starting at a 25-user minimum. Ask any quote to separate one-time setup from recurring hosting, support and upgrade work, and to state which plan and user count it assumes.
How long does moving Zulip onto our own servers take?
The duration depends on the size of the workspace, the hosting target and how much history you need to bring across. No timeline figure is supplied for this move, so ask for one in writing. The main variables are the server footprint you choose, whether you run Zulip directly on Ubuntu or Debian or in Docker, how many streams and messages you import, and how many integrations or SSO connections must be configured before users switch. Fixed-scope work agreed in writing before it starts lets you compare timelines across providers on the same assumptions.
What does running a self-hosted Zulip server need from our internal team?
Your team needs people who can operate a Linux server and a stateful chat service over its lifetime. The work includes provisioning and patching the host, keeping the database and file storage backed up, applying Zulip upgrades, managing TLS and reverse proxy settings, and watching logs and capacity. Identity work also falls to the team: the production documentation covers LDAP with Active Directory synchronization, SAML with IdP-initiated SSO and Single Logout, and SCIM, plus guides for Keycloak and Authentik. Confirm which of these you need before you size the team.
Can a team run self-hosted Zulip without outside help?
A team with Linux, database and identity skills can run Zulip alone, and the software itself is the same on Zulip Cloud and on your servers. Whether you should depends on how many people carry the on-call and upgrade duties, how fast you must recover from an outage, and whether the team has time for routine maintenance. Some organizations keep the server in-house and buy support for upgrades or incidents. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer.
Do self-hosted Zulip deployments change how mobile push notifications work?
Yes, the notification limit is the main difference. The free self-hosted Community plan limits mobile push notifications to 10 users for most organizations. The Basic plan, priced at $3.50 per user per month billed monthly according to the Zulip plans page, includes unlimited mobile notifications. Check which plan covers your user count before rollout, and confirm with Zulip how push traffic is routed from a server you host, since notification delivery depends on your network and that relay path.
What changes if our data residency rules apply to chat history?
Self-hosting lets you decide where chat data is stored, which matters when rules require data to stay in a specific country, region or on premises. Zulip Cloud stores your workspace on Zulip's infrastructure, so confirm its storage locations and contractual terms against your rules before you choose it. On your own servers, residency becomes an architecture decision covering the database, uploaded files, backups and any log or push relay. Ask the vendor and your compliance lead to confirm each location in writing, and note that DeployOpen prepares systems and evidence for compliance assessments but does not issue certifications or audit reports.
Which storage and search limits should we check before choosing?
Storage and search limits differ by plan and hosting model, and the numbers are not supplied here, so check the current figures on the Zulip plans page before you decide. On your own servers, storage is governed by the disks and backup targets you provision, so growth planning becomes your job. Ask for the search behavior on your expected message volume, how file uploads count against storage, and how exports and retention settings work on the plan you pick.
What should a quote for self-hosted Zulip include?
A useful quote lists scope, deliverables and timeline in writing before work begins. Ask for the hosting target and sizing assumptions, the identity integrations in scope, the data import sources and the volume to migrate, backup and restore procedures, upgrade handling, and the handover documents. Separate one-time work such as installation, configuration and migration from recurring work such as patching, monitoring and retainer support. Most DeployOpen engagements are fixed-scope, and the quote follows from that written scope rather than from a published price list.
What you pay for in each model and what recurs
The Cloud subscription is the only cost Zulip Cloud customers pay directly for the software, and it recurs for as long as you keep the organization on a paid plan. Zulip's published plan prices are the place to start, and the Zulip plans page lists the self-hosted Basic and Business tiers as per-user monthly or annual charges. A self-hosted Community plan carries no software fee but limits mobile push notifications to 10 users for most organizations, so a team larger than that will face a paid tier either way. Confirm on the plans page which tier applies to your user count, billing cycle and notification needs before you compare totals, because the same headcount can cost quite different amounts depending on whether you pay monthly or annually. Self-hosting moves the recurring spend to people and infrastructure rather than eliminating it. Your team pays for the servers or cloud accounts that run Zulip, for backups, for the database and storage that grow with message history and uploads, and for staff time to apply upgrades such as the 12.3 release published on September 21, 2026. Those costs recur monthly or per release cycle and rise with user count, retention periods and file volume. Ask whoever will run the server to estimate the hours per upgrade and per incident, and whether a retainer covers that work, since Zulip's own Cloud subscription includes operations that you would otherwise staff yourself. The one-time costs are concentrated at setup: standing up the server, configuring SSO through SAML or LDAP, syncing directory data, and importing history from Slack, Mattermost or Rocket.Chat using Zulip's import guides. Those projects are priced by scope and by the number of identity and data sources involved, so get them quoted as a separate line from the subscription. For a self-hosted team that wants paid features such as SAML, AD/LDAP sync or data exports, the Business plan price is the recurring item to model against the one-time integration effort.
How DeployOpen scopes, delivers and supports self-hosted Zulip
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Zulip, that means working from a written scope that decides whether the server belongs in your cloud account, a data center or an air-gapped network, and what identity, storage and notification setup it needs.
How we scope
- Written scope agreed before work starts, covering hosting location, user count and the Zulip server version to deploy.
- Identity decisions defined up front, including whether SAML, LDAP or Active Directory sync, or SCIM provisioning applies.
- Mobile push notification approach and data residency requirements recorded so the Cloud or self-hosted choice is documented.
How we build
- Install on Ubuntu or Debian directly or in Docker, configured to your network, DNS, TLS and backup standards.
- Identity provider integration tested end to end, with the Keycloak or Authentik setup adapted to your environment where needed.
- Data import from Slack, Mattermost or Rocket.Chat planned and rehearsed on a copy before any production cutover.
How we hand over
- Runbooks covering upgrades, backups, restores and the steps to move between Zulip server releases.
- Security testing results and hardening decisions recorded so your auditors and security team can trace each control.
- Administrator training and a handover session so your own staff can operate the server without us.
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover.
- Upgrade planning for each new Zulip server release, tested in a staging copy before production.
- Clear ownership agreed in writing for patching, backups, incident response and vendor contact after go-live.
