Rocket.Chat vs Zulip: which to choose

Rocket.Chat vs Zulip: when should a team choose each?

Choose Rocket.Chat when you want a broad chat workspace that includes calls and omnichannel style features, and when you expect to grow toward paid high availability or air-gapped deployment. Choose Zulip when your work runs as long asynchronous threads that need to stay organized by topic, and when you want the full authentication stack (LDAP, SAML, SCIM) on the self-hosted server without buying a plan. The decision turns on four questions: how many users you will have against each free tier, whether you need mobile push notifications for everyone, how much your teams depend on threaded conversations, and who will carry the upgrade work.

Start with user count and push. Rocket.Chat's free Starter plan allows up to 50 users and includes LDAP, Active Directory, SSO and MFA, while the free Community workspace allows up to 100 concurrent users with core messaging. Zulip's free self-hosted Community plan includes all features but limits mobile push notifications to 10 users for most organizations, and the paid Basic plan removes that limit at a listed per-user price. If most of your staff will use the phone apps daily, model the Zulip per-seat cost against Rocket.Chat's quote-based paid plans before you commit. Confirm current limits on each vendor's plan page, since these figures change.

Consider how your teams will run upgrades. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and its standard releases are supported for 6 months while LTS releases are supported for 12 months. Unsupported versions can lose connection to the official mobile and desktop clients, so someone must schedule upgrades on that cadence. Zulip Server releases are published on GitHub with a different cadence, and its software is the same one Zulip Cloud runs. Ask each vendor for its current support window in writing, then decide whether your platform team or an implementation partner will own that calendar.

Which scenario favors Rocket.Chat and which favors Zulip?

This table maps common team situations to the platform that usually fits better, with the condition that drives each choice. Read each row against your user count, mobile usage, compliance needs and current chat tool, because the limits that decide the answer are specific.

Scenario	Better fit	Why
A 40-person engineering team that wants SSO without paying	Rocket.Chat	The free Starter plan allows up to 50 users and includes LDAP, Active Directory, single sign-on and MFA, so the team can stay within the free tier if headcount stays under the cap.
A 40-person engineering team that wants SSO without paying, with growth expected past 50 users	Zulip	Zulip's self-hosted server includes SAML and LDAP without a paid plan, so the authentication requirement does not force a plan change as headcount grows.
A 300-person company with many cross-functional channels and heavy mobile use	Zulip	Zulip's Community plan limits mobile push notifications to 10 users for most organizations, so mobile-heavy teams need the paid Basic or Business plan, while Rocket.Chat's Starter plan includes unlimited push notifications.
A 300-person company with heavy mobile use on Rocket.Chat Starter	Rocket.Chat	Starter includes unlimited push notifications, which removes the per-user notification cost for mobile users, but the 50-user Starter cap means the team needs a paid plan for this headcount.
A regulated team that needs tamper-evident audit trails or air-gapped operation	Rocket.Chat	Tamper-evident audit trails and air-gapped deployment are listed as paid Rocket.Chat plan capabilities, so the team should confirm the Commercial or Government plan scope before committing.
A regulated team that needs SAML, LDAP sync and data exports on a paid plan	Zulip	Zulip's self-hosted Business plan adds email and chat support for SAML, AD/LDAP sync and data exports, and the Zulip Enterprise tier is priced by custom quote.
A team migrating from Slack with a full workspace export	Rocket.Chat	Rocket.Chat supports full Slack workspace exports directly, while Zulip also documents a Slack import path, so confirm which history and attachments each importer carries before choosing.
A team that needs conversations organized by topic within each stream	Zulip	Zulip's topic-based threading is its core conversation model, which suits asynchronous work where a single thread should stay readable for days.
A team that must run multiple load-balanced instances or Kubernetes microservices	Rocket.Chat	Rocket.Chat's multi-instance and microservice reference architectures require a paid plan, so this scenario favors Rocket.Chat only once the commercial budget and plan scope are confirmed.

How Rocket.Chat and Zulip are built and what that means for operations

Rocket.Chat and Zulip make different architectural bets, and those bets shape day-two work: database operations, upgrade cadence, backup scope and how many moving parts your team owns. The cards below cover the components and checks that matter most before you commit to either platform.

MongoDB replica set requirement

Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so your team must operate a database topology that many Zulip deployments do not need. The vendor recommends three members for high availability, which means three database nodes to patch, monitor and back up. Confirm whether your existing database team supports MongoDB in this topology, and ask who owns replica set failover testing in your environment.

Bundled Node.js runtime

Node.js is bundled in the official Rocket.Chat Docker image and Helm chart, so you do not manage a separate Node runtime for the standard container path. That reduces one layer of patching, but your team still owns the container host, image pulls and Helm values. If you plan a non-container install, confirm with the vendor how Node.js versions are pinned and upgraded against your Rocket.Chat release.

Reference architecture stages

Rocket.Chat's reference architectures start with one instance and a MongoDB replica set for up to 500 concurrent users, then move to multiple load-balanced instances linked by NATS above 500, and to microservices on Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan. Sizing for your headcount needs the vendor's reference architecture and your own load test, not a single figure from a comparison page.

Zulip self-hosting routes

Zulip can be installed directly on Ubuntu or Debian, run in Docker through docker-zulip, or deployed from prebuilt DigitalOcean or Render images. A direct install gives your team full control of the operating system and PostgreSQL setup, while the Docker route moves that work into a container layer you must also maintain. Choose the route that matches how your platform team already patches and upgrades services, and confirm which route the vendor's upgrade guidance covers.

Topic-based conversation data model

Zulip organizes conversations into streams with topics, so each thread is a discrete, searchable unit that can be reviewed later. Rocket.Chat organizes conversations into channels and direct messages, which map more closely to how many teams already chat. The difference matters for backup and retention: confirm how each platform exports message history, how retention policies apply per channel or stream, and whether your legal team can search and produce threads from the exports.

Upgrade cadence and backup scope

Rocket.Chat standard releases receive six months of support and LTS releases receive twelve months, and an unsupported version can lose connection to official mobile and desktop clients. Your backup plan must cover the MongoDB replica set, uploaded files and configuration, and every restore test must include a version match. Ask for the upgrade path between your current and target releases, and ask Zulip how database migrations are handled between major server versions such as 12.0 and 12.3.

Which features does each platform offer in free and paid tiers?

This table compares which authentication, compliance, data and deployment features each platform includes without a paid plan and which need a paid tier. Read each row against your own identity provider, audit obligations and mobile user count, because the free tier boundary differs sharply between the two products.

Capability	Rocket.Chat	Zulip
Conversation model	Channels, direct messages and team rooms organized by channel	Streams divided into topics, designed for threaded live and asynchronous conversation
Self-hosted license	MIT core, with enterprise code under a separate Rocket.Chat enterprise license	Apache License 2.0 for the server, with the same software used by Zulip Cloud
LDAP and Active Directory	Included in the free Starter plan (up to 50 users)	Included in the self-hosted server without a paid plan, with AD data synchronization
SAML and SSO	SSO included in Starter; SAML user group mapping listed on paid plans	SAML included in the self-hosted server, with IdP-initiated SSO and Single Logout
MFA	Included in the free Starter plan	Confirm MFA options and IdP-side enforcement with Zulip for your setup
SCIM provisioning	Confirm availability and plan level with Rocket.Chat before planning	Documented and available on the self-hosted server without a paid plan
End-to-end encryption	Included in the free Starter plan	Confirm E2EE scope with Zulip, since it is not listed in the supplied material
Audit trails	Tamper-evident audit trails of messages, files and sessions on paid plans	Confirm audit logging and data export options on Zulip paid plans with the vendor
Data import sources	Slack full workspace exports, Slack users from CSV, generic CSV, Mattermost via CSV conversion	Documented imports from Slack, Mattermost and Rocket.Chat
High availability	Built-in redundancy and automated failover on paid plans; multi-instance designs need a paid plan	Confirm high availability architecture and supported topologies with Zulip before committing
Air-gapped deployment	A paid-plan capability, not available on Starter	Self-hosted deployment with no paid gate listed in the supplied material; confirm offline operation with Zulip
Mobile push notification limits	Starter includes unlimited push notifications; confirm current terms with Rocket.Chat	Free Community plan limits push notifications to 10 users for most organizations; Basic plan at $3.50 per user per month (Zulip plans page) removes the limit; confirm Business and Enterprise terms with Zulip

Which authentication and compliance features are free on Zulip and Rocket.Chat?

The first question is not which product has more features but which controls you can run without a paid plan. On Zulip, the self-hosted server is the same software Zulip Cloud customers use, with no open core restrictions, so LDAP (including Active Directory with data synchronization), SAML (including IdP-initiated SSO and Single Logout), SCIM and custom roles are available on the Community plan. Zulip's documentation also includes setup guides for Keycloak and Authentik as SAML identity providers. On Rocket.Chat, the free Starter plan, which allows up to 50 users, includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption and retention. Rocket.Chat's paid Commercial, Government and Defense plans add LDAP and SAML user group mapping, tamper-evident audit trails of messages, files and sessions, built-in redundancy with automated failover, and air-gapped deployment, which is not available on Starter.

The gap matters in three situations. If an auditor asks for evidence that access to chat is logged and tamper-evident, Rocket.Chat's audit trail sits behind a paid plan, so you would need to price that plan into the decision before you need it. If access must follow group membership, such as giving a project group access to specific channels, check whether you need group mapping from the directory, which Rocket.Chat reserves for paid plans, while Zulip's directory sync is available on the free server. If offboarding must be automatic, directory sync and SCIM determine whether a departing employee loses access when the directory account is disabled, rather than when someone remembers to remove them by hand. Map each of these to a control in your own register before you choose the plan.

Confirm the current identity provider support with each vendor before you rely on it, including the exact SAML and SCIM behaviors your IdP needs, such as Single Logout handling and attribute mapping. Ask Rocket.Chat which audit log fields and retention periods its paid plans provide, and ask Zulip how its audit and data export features map to your evidence requirements. Your auditor or regulator decides what evidence is sufficient, so test the controls in a pilot with your own directory before you commit to a plan. Deployment and integration effort for either product is a quote item, not a figure this comparison supplies.

What do the licenses and paid editions actually include?

Rocket.Chat's core repository is MIT licensed, but the code under the apps/meteor/ee and ee directories is covered by a separate Rocket.Chat enterprise license. That split matters because a free deployment and a paid deployment do not run identical code paths for every feature, so the license you accept at install time is part of the decision. The plans are tiered as Community, Starter, and then Commercial, Government and Defense, with the last three priced by quote.

Community workspace: the free tier allows up to 100 concurrent users with core messaging.
Starter plan: the free tier allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts.
Commercial, Government and Defense: these paid plans are priced by quote and add SAML user group mapping, tamper-evident audit trails, built-in redundancy with automated failover, and air-gapped deployment, which Starter does not include.
Support windows: standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, and cloud services such as the push notification gateway stop working.
Client compatibility: unsupported versions may lose the ability to connect with official mobile and desktop clients, so upgrades are an operating cost in every tier.

Confirm with Rocket.Chat which plan covers your required features, and ask for the quote in writing against your user count and deployment design.

What drives the running cost of each platform?

Running Rocket.Chat or Zulip costs more than the software line on a quote. The cards below cover the components each platform needs, the skills your team must already have, the upgrade cadence you must keep, and the seat and implementation charges that recur or arrive once.

Database and instance footprint

Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and a three-member set is strongly recommended for high availability. Reference architectures move from one instance to multiple load-balanced instances linked by NATS above 500 concurrent users, and that step requires a paid plan. Zulip runs as a single self-hosted server stack. Ask each vendor to size your user count and concurrency against these tiers before you commit.

Operations skills to hire or train

Rocket.Chat operators need MongoDB administration, including replica set health, backups and version compatibility. Zulip operators need the PostgreSQL and Python-based operations its production documentation describes. Confirm the exact stack, supported database versions and any Redis or RabbitMQ requirements in the current vendor docs before you map the skills to your existing staff.

Version end-of-life exposure

Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life, push notifications, Marketplace and Omnichannel integrations stop working, and unsupported versions may lose compatibility with the official mobile and desktop clients. Budget recurring upgrade work for this reason. Zulip's release cadence, including Zulip Server 12.0 on April 27, 2026 and 12.3 on September 21, 2026, sets a different rhythm that your operators should plan around.

Per-user Zulip seats against quoted Rocket.Chat plans

Zulip's self-hosted Community plan is free and includes all features, but limits mobile push notifications to 10 users for most organizations. The Basic plan costs $3.50 per user per month billed monthly, and the Business plan costs $6.67 per user per month billed annually or $8 billed monthly with a 25-user minimum. Rocket.Chat's Commercial, Government and Defense plans are priced by quote, so request the seat basis, minimums and renewal terms in writing.

One-time implementation and recurring support

Implementation covers installation, identity integration, the chat data import from Slack, Mattermost or Rocket.Chat, and operator handover. These are generally one-time costs, while support subscriptions, retainers and upgrade windows recur. Ask for a fixed-scope quote that lists import sources, identity providers, backup and restore testing, and the upgrade runbook separately, so you can compare the one-time and recurring lines across both platforms.

How do you move users from Rocket.Chat to Zulip or the reverse?

This sequence moves channels, members and history from one chat platform to the other with a tested import path, identity sync in place before cutover, and a clear record of what must be rebuilt by hand.

Inventory channels, users and integrations
The workspace owner exports a list of active channels, private groups, direct message volume, members, admins and bot accounts from the current instance, and records which integrations, outgoing webhooks, apps and retention rules are in use. Mark which channels hold regulated or contractual records, since those decide the retention and archive plan. The step is done when every channel has an owner, a member count and a keep, merge or retire decision, reviewed by the security and records owners.
Map channels to streams and topics
Work out how each Rocket.Chat channel maps to a Zulip stream, and how threads that relied on message order in a channel map to topics. Zulip's model is stream plus topic, so a busy general channel usually needs several streams and a naming convention agreed in advance. Document the mapping in a shared table with one row per source channel. The step is done when the table has been approved by the channel owners and no channel is left without a destination.
Confirm the import path for your source data
Confirm the path for your data before any user is told a date. Zulip's help center documents importing from Rocket.Chat, Slack and Mattermost. In the other direction, Rocket.Chat's import tools accept full Slack workspace exports, Slack users from CSV and a CSV importer for other sources, with Mattermost data converted into CSV. A reverse import from Zulip into Rocket.Chat is not covered by the supplied facts, so ask Rocket.Chat and DeployOpen to confirm whether a Zulip export can be loaded and what it preserves. The step is done when a written note records the chosen path, its version and its known gaps.
Set up identity sync before cutover
Connect the target platform to the same identity source before any import. Zulip documents LDAP including Active Directory with data synchronization, SAML including IdP-initiated SSO and Single Logout, and SCIM. Rocket.Chat's Starter plan lists LDAP, Active Directory and single sign-on, with group mapping on paid plans. Confirm which of these your edition and plan include, then test that a pilot account signs in, receives the right groups and is deprovisioned when disabled in the directory. The step is done when a test user passes sign-in, group and removal checks on the target.
Run a pilot with one team
Import one representative team's channels into a non-production copy of the target, then run it with a small group of volunteers for normal work. Check that message history, file links, mentions, user names, avatars and channel membership arrived as expected, and compare search results and read states against the source. Record every defect with its owner. The step is done when the pilot team has worked on the target through a full working cycle and the open defects are either fixed or accepted in writing.
Rebuild integrations, bots and roles
Plan these items by hand, because they rarely move cleanly. Bots, webhooks, custom roles, Marketplace apps and retention rules must be recreated and tested on the target, with their permissions reviewed again. Mobile sessions and client registrations will not carry over, so users must sign in again on each device. Confirm mobile push behavior on your plan before relying on it, since Zulip's free Community plan limits mobile push notifications to 10 users for most organizations. The step is done when each integration has a tested replacement and a named owner.
Cut over and freeze the source
Announce a cutover window, set the source workspace to read-only where the platform allows it, run a final incremental import of changes made since the pilot, and point users, links and integrations at the target. Keep the source available in read-only form for the period your records policy requires. The step is done when the final import reconciles with the source channel counts, sign-in works for the full user list, and the help desk has the new links.
Retire the old instance and keep the records
After the agreed read-only period, export the archive needed for legal hold or audit, document where it is stored, and then shut down the old instance and remove its data stores and backups on the schedule your retention policy sets. Keep the mapping table, import logs and cutover record with the archive. Confirm the old version's support status first, since Rocket.Chat says unsupported versions can lose connection to the official clients. The step is done when the archive is verified, the decommissioning record is signed off, and no live users depend on the old system.

Where do Rocket.Chat and Zulip projects usually run long?

Rocket.Chat projects tend to slip in three places. The first is the database layer: Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Teams that treat MongoDB as an afterthought often discover late that backups, failover testing and replica set monitoring need their own owner. The second is upgrade discipline. Standard releases are supported for 6 months and LTS releases for 12 months, and an unsupported version can lose the ability to connect with the official mobile and desktop clients. Agree on an upgrade cadence and a test environment before go-live, not after the first end-of-life notice. The third is the plan decision. Starter covers up to 50 users, and the free Community workspace covers up to 100 concurrent users with core messaging, so a rollout that grows past those caps mid-project forces a paid plan choice, and multi-instance designs require one.

Zulip projects slip for different reasons. Topic-based threading only works if the organization agrees on topic naming conventions and stream design before users arrive. Without that agreement, channels multiply, topics drift and the search and catch-up benefits fade within weeks. Identity integration is the second risk. Zulip supports LDAP including Active Directory with data synchronization, SAML including IdP-initiated SSO and Single Logout, and SCIM, and documents setup guides for Keycloak and Authentik as SAML identity providers. Your identity provider's attribute mappings, group structure and certificate handling still need to be confirmed against Zulip's production documentation, and that work belongs in the schedule. The third risk is the mobile push plan. The free Community plan limits mobile push notifications to 10 users for most organizations, so the number of mobile users must be known before the rollout is scoped.

Fixed-scope engagements agree deliverables, timelines and acceptance criteria in writing before work starts, which is the main protection against these slips. Before any kickoff, prepare four inputs: a current user list with roles and mobile usage, read access or an admin contact for your identity provider, an inventory of existing channels or rooms with owners, and a written decision on data retention, including how long messages and files are kept and who may change those settings. Confirm the decision before migration starts, because retention rules change what an import from Slack, Mattermost or Rocket.Chat must carry over.

What do buyers ask before they choose between Rocket.Chat and Zulip?

How much does a self-hosted Rocket.Chat or Zulip deployment cost?

The software licence is not the main cost for either platform, because the server code is free to run. Cost comes from the infrastructure you provide, the people who install and operate it, and any paid plan you adopt. Rocket.Chat's paid Commercial, Government and Defense plans are priced by quote, so ask for a written figure tied to user count, deployment model and support level. Zulip's self-hosted Business plan lists published per-user prices, with a 25-user minimum, and Enterprise pricing is custom. Ask each vendor what recurs (subscriptions, support renewals) and what is one-time (installation, configuration, migration). Source for both plan structures: Zulip plans and Rocket.Chat plans.

How long does it take to migrate a team from Slack or Mattermost?

The timeline depends on three things: how many channels and how much history you hold, which import path applies, and how identity is set up before users arrive. Zulip documents import paths from Slack, Mattermost and Rocket.Chat. Rocket.Chat documents a full Slack workspace export, a Slack user CSV and a generic CSV importer, and it migrates Mattermost by converting the export into CSV. Inventory your channels, private groups, attachments and retention rules first, then test one representative channel in a staging instance. Ask any implementation partner for a written duration tied to that inventory rather than a generic estimate.

Can our own team run Rocket.Chat or Zulip without an outside partner?

A team with Linux administration, database operations and identity integration skills can run either platform, but the skill mix differs. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and its multi-instance and microservice designs require a paid plan, so you need someone comfortable with MongoDB and, at larger scale, Kubernetes. Zulip runs on Ubuntu or Debian directly, in Docker, or from prebuilt images, and its production documentation covers PostgreSQL-backed operation, LDAP and SAML. Rocket.Chat also requires regular upgrades, because unsupported versions can lose connections to the official mobile and desktop clients. Estimate the recurring hours for upgrades and on-call cover, not only the first install.

Can the free self-hosted Zulip server use SAML and LDAP?

Yes. Zulip's self-hosting page states that the self-hosted server is the same software used by Zulip Cloud customers, with no open core restrictions, so SAML, LDAP and custom roles are available without a paid plan. Zulip's production documentation covers LDAP with Active Directory data synchronization, SAML with IdP-initiated single sign-on and Single Logout, and SCIM, with setup guides for Keycloak and Authentik as SAML identity providers. Confirm the exact configuration with your identity team against the current production documentation before you commit, because your identity provider and directory layout will determine the work.

Does Rocket.Chat deliver mobile push to a large team on the free plan?

The answer depends on current vendor terms, so confirm them before you plan. Rocket.Chat's free Starter plan includes LDAP and Active Directory, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts, and the free Community workspace allows up to 100 concurrent users. Rocket.Chat's paid plan material lists unlimited push notifications as a Starter-plus capability, and push runs through a cloud push notification gateway. Ask Rocket.Chat in writing which push terms apply to your user count, whether the gateway is available to self-managed deployments on your plan, and what happens to push after a version reaches end of life. Zulip's free Community plan limits mobile push notifications to 10 users for most organizations, while its Basic plan lists unlimited mobile notifications at a published per-user price.

Can we move back to Slack, Mattermost or another tool later?

Moving out is possible in principle, but the documented paths are the part to verify. Zulip's help center documents imports from Slack, Mattermost and Rocket.Chat, which means data can come into Zulip from those sources. Export formats and reverse paths from either platform are a separate question. Before you commit, ask each vendor for its current export options, including whether messages, threads, files, user identities and retention metadata survive a round trip. Test an export and re-import on a sample dataset, and record which fields are lost. Budget for this test as part of the switching cost, because the cost of moving later is usually higher than the cost of a careful first move.

What does a DeployOpen engagement need from our team?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. To scope a Rocket.Chat or Zulip engagement, expect to provide the target environment (cloud account, data centre or air-gapped network), your user count and channel inventory, the identity provider and directory details, retention and compliance requirements, and a named decision-maker for choices such as import scope and plan selection. You will also need access for the people who will run the platform after handover. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen helps teams choose, implement and migrate chat platforms

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Rocket.Chat vs Zulip, that means working from your identity, compliance and hosting requirements to a written scope before any system is changed.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map which user counts, authentication methods and paid-plan features your team needs on each platform.
We confirm mobile push, data import and hosting requirements against current vendor documentation before recommending either option.

How we build

We deploy the chosen platform in your cloud account, data center or air-gapped network, using your own infrastructure.
We configure identity integration, such as LDAP, Active Directory or SAML, and document each setting for your team.
We test imports from Slack, Mattermost or Rocket.Chat exports on sample data before any production migration runs.

How we hand over

You receive documentation of architecture, configuration, backup procedures and upgrade steps for your environment.
We provide a runbook covering user onboarding, retention settings and the version lines your team must track.
Handover includes a review with your administrators so they can operate the platform without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades so the platform stays on a supported release line.
DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.

Rocket.Chat vs Zulip