Поставили LiveKit рядом с Jitsi Meet и месяц смотрели, что выберут люди

MAATRIX

Идея сравнить LiveKit и Jitsi Meet родилась из спора, который звучал примерно так: «зачем нам два видеосервера, разверни один нормальный». Спор был не совсем честным — это разные по природе инструменты, и сравнивать их напрямую примерно как сравнивать конструктор с готовым домом. Но вопрос был законный: если оба закрывают тему «видео без Zoom», зачем платить за инфраструктуру дважды. Мы подняли оба рядом на конец августа 2026 года и месяц смотрели, кто чем реально пользуется — не в теории, а по факту открытых вкладок и логов.

Зачем ставить рядом два разных по природе инструмента

Формальный повод был практический: команде нужны были обычные созвоны — стендапы, встречи с клиентами, планёрки, а продукту параллельно нужна была видеосвязь внутри самого приложения — звонок консультанта с клиентом прямо на странице заказа, без перехода в сторонний сервис. Это две разные задачи, и решать обе одним инструментом означает либо городить в приложение чужой готовый интерфейс через iframe, либо тащить в обычные созвоны сложность SDK, которая там просто не нужна.

Поэтому решение развернуть оба сервиса параллельно было не экспериментом ради статьи, а рабочей необходимостью. Статья — побочный продукт: захотелось честно зафиксировать, где каждый инструмент выигрывает, а где создаёт лишнюю работу, потому что заранее в документации это не всегда очевидно.

Здесь же стоит сразу закрыть путаницу в терминах, с которой сталкивается почти каждый, кто гуглит «LiveKit vs Jitsi». Jitsi Meet — это готовое приложение видеоконференций: устанавливаете, открываете ссылку, звоните. LiveKit — это открытый WebRTC-фреймворк с сервером, клиентскими SDK и API: чтобы получить работающий звонок, нужно написать (или взять готовый пример и доработать) собственный интерфейс. Формально оба можно назвать «self-hosted видеоплатформой», но по сути это разные слои стека.

LiveKit: фреймворк для видео внутри своего продукта, а не приложение для звонков

LiveKit — это open-source SFU (Selective Forwarding Unit) на Go с набором клиентских SDK: JavaScript/TypeScript, Swift, Kotlin, Flutter, React Native, Unity, серверные SDK для Node.js, Python, Go, Rust. Сервер занимается маршрутизацией медиапотоков между участниками, а вся логика интерфейса — комнаты, кнопки, список участников, чат — остаётся на стороне разработчика.

Из коробки LiveKit даёт:

• livekit-server — сам SFU, конфигурируется одним YAML-файлом;
• встроенный TURN-сервер (можно не поднимать coturn отдельно, если устраивает встроенный);
• Egress — сервис записи звонков и трансляции в RTMP/HLS;
• Ingress — приём внешних потоков (например, с камеры или RTMP-источника) внутрь комнаты;
• LiveKit Agents — фреймворк для голосовых и видео-агентов на базе LLM, если планируете AI-ассистента внутри звонка.

Ключевой момент: у LiveKit есть демо-приложение (LiveKit Meet), но это витрина возможностей, а не production-ready замена Zoom. Чтобы получить рабочую видеосвязь для конечных пользователей, придётся написать компонент на React/Flutter/нативном SDK, подключить его к API LiveKit (генерация JWT-токенов для доступа в комнату, управление правами), и уже это встроить в свой продукт. Это осмысленная плата за гибкость: интерфейс звонка можно сделать любым — с брендингом, кастомной логикой допуска, интеграцией в CRM, — но время на разработку идёт не в счёт установки сервера, а в счёт написания приложения.

Для команды, где есть фронтенд-разработчик и понятная задача «встроить видео в наш продукт», это разумный путь. Для команды, которой просто нужна комната для созвонов к вечеру пятницы, LiveKit — избыточный инструмент: вы получите SFU без интерфейса и потратите время не на настройку сервера, а на написание клиента, которого у Jitsi уже есть готовым.

Jitsi Meet: открыл ссылку — и в конференции

С Jitsi Meet всё наоборот: это законченное приложение. Устанавливаете deb-пакет jitsi-meet (подробно разбирали в пошаговой установке на Ubuntu 24.04) — и получаете готовую страницу конференции с чатом, демонстрацией экрана, поднятой рукой, фоновым размытием и записью через Jibri. Никакого кода писать не нужно: открыл ссылку в браузере — и участник уже в звонке.

Архитектурно Jitsi Meet — это тоже связка из нескольких сервисов (Jicofo, JVB как SFU, Prosody для сигналинга, веб-интерфейс на React), но пользователю и администратору всё это видно как один продукт с одной точкой входа. Кастомизация возможна — можно поменять брендинг, подключить SSO, настроить права — но происходит она через конфиги готового приложения, а не через написание собственного фронтенда с нуля.

Именно поэтому в паре с LiveKit Jitsi Meet сразу занял нишу «обычные внутренние созвоны»: сотрудникам не нужно объяснять, что это и как этим пользоваться — интерфейс интуитивно понятен, как у любого видеозвонка. LiveKit для той же задачи потребовал бы отдельного проекта по разработке интерфейса, которого у нас на тот момент попросту не было в приоритете.

Требования к серверу: где LiveKit и Jitsi расходятся сильнее всего

Оба инструмента используют SFU-архитектуру и не занимаются транскодированием видео по умолчанию (транскодирование — это отдельная, куда более прожорливая по CPU история, и оба продукта её по умолчанию избегают за счёт симулкаста — клиент сам присылает несколько версий потока в разном разрешении). Поэтому по общей логике нагрузка похожа: узкое место — сеть и количество одновременных медиапотоков, а не диск.

Но есть различия, которые стоит учитывать при выборе сервера:

Практическая разница, которая сразу бросилась в глаза при развёртывании: LiveKit проще положить за один порт с TURN «из коробки» — не нужно отдельно поднимать coturn, если устраивает встроенный сервер, тогда как для Jitsi TURN чаще настраивается отдельно при сложных NAT-сценариях. А Egress в LiveKit и Jibri в Jitsi одинаково требовательны, если включена запись — на практике на сервер, где параллельно идёт активная запись нескольких сессий, лучше закладывать отдельные vCPU сверх расчёта под SFU, и для LiveKit, и для Jitsi.

Для обоих сервисов канал остаётся главным ограничением: если видеотрафик идёт через сервер (а не P2P, который у обоих поддерживается только для звонков один на один), закладывайте ориентировочно 2-3 Мбит/с на активного участника с видео в средне-высоком качестве — это грубая оценка, у вас цифра может отличаться в зависимости от разрешения и битрейта, который согласуют клиенты.

Что показал месяц параллельной работы: кто чем реально пользовался

Здесь честно: точных цифр вроде «столько-то процентов звонков ушло туда-то» мы не считали — не было задачи вести телеметрию использования ради статьи, и придумывать проценты задним числом не будем. Но общая картина по факту, кто к какому сервису какие вопросы адресовал за месяц, сложилась довольно чётко.

Jitsi Meet забрал себе всё, что можно назвать «человеческими» созвонами: ежедневные стендапы, встречи с внешними подрядчиками, разборы инцидентов, где важно было быстро скинуть ссылку и не тратить время на объяснение интерфейса. Никто из команды не спрашивал, как этим пользоваться — это же просто ссылка на видеозвонок, все умеют.

LiveKit не использовался «людьми» напрямую вообще — и это ожидаемо, потому что мы сознательно не стали городить общий интерфейс поверх него для внутренних созвонов. Всё обращение к LiveKit шло через код: разработчик встраивал его в тестовую версию модуля видеоконсультаций внутри продукта, дергал API для генерации токенов доступа в комнату, тестировал сценарий «клиент нажал кнопку на сайте — соединился с оператором». То есть сравнение «что выбрали люди» в чистом виде оказалось не совсем корректной постановкой вопроса для LiveKit — его не выбирают вместо Jitsi, потому что конечный пользователь с LiveKit-сервером вообще не взаимодействует напрямую, только с интерфейсом, который поверх него написали.

Единственный момент, где решения реально конкурировали — это ровно та задача, с которой всё начиналось: видеозвонок внутри продукта. Тут пробовали и вариант «встроить Jitsi через iframe с параметрами конфигурации», и вариант «написать минимальный клиент на LiveKit React SDK». Iframe с Jitsi поднялся кардинально быстрее — буквально несколько строк конфигурации, и работающий звонок внутри страницы. Но с кастомизацией сразу начались ограничения: часть интерфейса Jitsi через iframe-параметры не убирается и не перекрашивается до нужного вида, поведение при потере соединения не подстроить под свой UX, а глубокая интеграция с состоянием продукта (например, автоматически подставить данные клиента в звонок) требует обхода через постMessage API, что ощущается как костыль поверх чужого приложения.

LiveKit-клиент на старте потребовал заметно больше работы — нужно было написать компонент с нуля, разобраться с токенами и правами доступа, — но результат получился ровно таким, каким его хотели видеть: свой интерфейс, свой брендинг, звонок, который выглядит частью продукта, а не встроенным чужим окном. Для разовой задачи это было бы избыточно, но для функции, которая становится постоянной частью продукта, оверхед на старте разработки окупился управляемостью на дистанции.

Как выбрать: сценарии, где однозначно годится один, а не другой

По итогам месяца выбор свёлся к простому правилу, зависящему от того, что вы на самом деле строите:

• Нужны обычные видеозвонки для команды или клиентов (стендапы, встречи, консультации через отдельную ссылку) — берите Jitsi Meet. Это готовое приложение, разворачивается за час-два (см. установку на Ubuntu 24.04), не требует разработки, и участникам не нужно ничего объяснять.
• Нужно встроить видео как функцию внутри своего продукта — с кастомным интерфейсом, интеграцией с бизнес-логикой, возможно с AI-агентом в звонке — берите LiveKit. Здесь неизбежна разработка клиента, но взамен вы получаете полный контроль над UX и логикой доступа.
• Нужен быстрый прототип видео внутри продукта, а полноценная разработка клиента пока не приоритет — временный вариант с iframe от Jitsi ближе к MVP, но закладывайте, что при росте требований к кастомизации придётся мигрировать на что-то вроде LiveKit — путь назад через доработку iframe быстро упирается в потолок возможностей встраивания.
• Нужны и то и другое одновременно (наш случай) — не пытайтесь свести к одному инструменту. Разные серверы, разные ресурсы, разные ответственные — это нормально, если задачи действительно разные, а не результат нежелания разобраться в одном инструменте до конца.
• Не уверены, что вам вообще нужен именно Jitsi, а не другое готовое self-hosted решение — например, если созвоны у вас чаще похожи на вебинары с десятками слушателей, а не на равноправные встречи — стоит заодно свериться с сравнением Jitsi Meet и BigBlueButton: второй лучше заточен под обучение и презентации, а не про звонки один-на-один или небольшой командой.

Отдельно стоит сказать про ресурсы, если ставите оба на одну инфраструктуру, как это было у нас: с точки зрения сервера они не конкурируют напрямую за одни и те же ядра постоянно — Jitsi нагружен неравномерно в течение рабочего дня (пики на созвонах), LiveKit нагружен точечно тестовыми звонками разработки. Но при выходе LiveKit-модуля в продакшен с реальным трафиком клиентов закладывайте отдельный сервер или как минимум чёткие лимиты по CPU/RAM для каждого сервиса — SFU при перегрузке начинает деградировать по качеству видео у всех активных участников сразу, и разбираться, чей процесс съел ресурсы в момент падения качества у клиента, в общем контейнере или общей VM неприятно.

Частые вопросы