Pinokio и Docker Extension: когда уместны сторонние способы

Допустим, вы выбираете, как развернуть новый личный экземпляр Open WebUI на своём компьютере. Вы открываете официальный Quick Start и видите там Pinokio и Docker Desktop Extension. Стоит ли запускать интерфейс через них? Эти варианты имеет смысл рассматривать, когда нужная среда уже работает на вашей машине и вы понимаете, как именно сторонняя оболочка обновляет приложение и хранит данные. Если вам нужен прямой контроль над версией, портами и файлами конфигурации, разумнее выбрать Docker Compose, а если требуется отдельная программа без ручного управления контейнерами — рассмотреть официальное приложение Open WebUI Desktop.

Разберём этот выбор до того, как в чате появятся важные диалоги и загруженные документы; существующие базы мы здесь не трогаем и не переносим. Все выводы ниже основаны на документации и статическом разборе исходного кода пакетов по состоянию на 19 октября 2026 года, без загрузки установщиков и запуска самих приложений.

Что меняется, когда Open WebUI запускает сторонняя программа

Когда вы ставите Open WebUI напрямую, вы сами вызываете Docker или менеджер пакетов Python и точно знаете, с какими флагами запущен сервер. Если же вы выбираете установку в один клик через стороннюю оболочку, между вами и сервером появляется посредник.

Цепочка работы при этом выглядит так:

1. Программа-оболочка (лаунчер Pinokio или среда Docker Desktop).
2. Конкретный пакет автоматизации внутри неё: в Pinokio это рецепт установки (recipe — набор скриптов, который создаёт папки, скачивает зависимости и запускает команды за пользователя), а в Docker Desktop — управляющее расширение (extension), которое само формирует команды для создания контейнера (изолированной среды со своим набором системных файлов).
3. Сервер Open WebUI, который отдаёт веб-интерфейс и сохраняет историю переписки в свою папку или том.
4. Отдельный сервер модели — программа, которая фактически вычисляет ответы нейросети. Сама кнопка установки интерфейса не включает в себя готовую языковую модель.

Поэтому перед выбором проверьте, кто написал обёртку и кто отвечает за её работу. В разделе быстрого старта Open WebUI приведены оба варианта, но с чётким разграничением ответственности:

• Карточка в каталоге Pinokio ведёт к рецепту из репозитория pinokiofactory/open-webui. В документации Open WebUI прямо указано, что поддержка этого способа предоставляется через сайт самого Pinokio.
• Расширение для Docker Desktop развивается в отдельном репозитории rw4lll/open-webui-docker-extension. В статье в блоге Docker от 20 октября 2025 года его автор, Docker Captain Сергей Шитиков, подробно описывал идею этого инструмента. Однако присутствие ссылки в документации или статья в блоге Docker не меняют официального статуса: в самом Quick Start это расширение помечено как неофициальное (not officially supported by Open WebUI) и рассчитанное на одного локального пользователя. Также не путайте это расширение внутри Docker Desktop с самостоятельным приложением Open WebUI Desktop — это разные продукты.

По состоянию на 19 октября 2026 года оба публичных репозитория не архивированы: в рецепте Pinokio последнее зафиксированное Git-изменение относится к 18 августа 2026 года, а у расширения для Docker Desktop релиз 0.3.0 на GitHub выпущен 12 апреля 2026 года (при этом публичные метаданные тегов 0.3.0 и latest на Docker Hub для rw4lll/openwebui-docker-extension датированы 13 марта 2026 года). Но открытый репозиторий, запись в реестре образов и работающее приложение на вашем компьютере — это разные уровни подтверждения. Наличие опубликованных метаданных не доказывает ни содержимое самого образа, ни то, что карточка расширения прямо сейчас откроется и установится в вашей копии Docker Desktop.

Допустим, у вас на компьютере уже стоит Pinokio для других нейросетевых утилит. Что сделает его рецепт для Open WebUI и какие задачи останутся на вашей стороне?

Pinokio: знакомый лаунчер и отдельный рецепт Open WebUI

Если вы уже пользуетесь Pinokio, логично сначала оценить его рецепт, а не ставить рядом вторую среду виртуализации ради одной кнопки запуска. Выбор зависит от того, какие команды выполняют скрипты рецепта pinokiofactory/open-webui.

При установке скрипт install.js создаёт внутри папки рецепта отдельное окружение Python по пути app/env и устанавливает туда пакеты через утилиту uv. Здесь uv работает как быстрый установщик пакетов, а виртуальное окружение (Python environment) — как отдельная папка с библиотеками, чтобы зависимости Open WebUI не конфликтовали с другими программами на компьютере. Сам пакет ставится командой uv pip install open-webui -U без фиксации конкретного номера выпуска.

В этом способе установки есть несколько обозначений версий, которые легко перепутать:

• Версия самого приложения-лаунчера Pinokio (на момент проверки в релизах pinokiocomputer/pinokio наблюдалась v8.2.0).
• Версия схемы скрипта: в файле меню pinokio.js указано поле version: "3.4.0". Как объясняет руководство Pinokio, это script_schema_version — технический маркер версии скриптового API, а не номер релиза самого рецепта и не доказательство того, что скрипт гарантированно заработает в вашей среде.
• Ревизия самого рецепта, которая определяется только конкретным коммитом в Git-репозитории pinokiofactory/open-webui.
• Фактическая версия пакета Open WebUI. Поскольку рецепт не фиксирует номер выпуска пакета, точную установленную версию Open WebUI нельзя определить по версии лаунчера или схемы: она зависит от конкретной установки или обновления.

Когда установка завершена, активный пункт меню Start в pinokio.js обращается к скрипту start.js (лежащие в репозитории файлы start.sh и start.bat в текущем меню не задействованы). Скрипт start.js выполняет два действия:

1. Устанавливает переменную окружения DATA_DIR так, чтобы рабочие данные сохранялись в каталог app/data внутри папки этого рецепта. Согласно документации Pinokio, сам лаунчер размещает скачанные рецепты в подкаталоге api внутри того домашнего каталога, который вы выбрали в настройках Pinokio. Поэтому искать свои данные нужно в app/data внутри вашей копии рецепта, а не по единому для всех систем абсолютному пути.
2. Запускает сервер командой open-webui serve --port 42004 --host 127.0.0.1. Интерфейс привязывается к локальному адресу 127.0.0.1 и фиксированному порту 42004.

Что при этом происходит с языковой моделью? В меню рецепта есть кнопка Download Models, которая вызывает скрипт down.js и выполняет команду ollama pull. Меню также предлагает ссылку на установку Ollama. Для локального сценария через этот пункт меню нужны отдельно работающий сервер Ollama и загруженная модель; сама установка интерфейса их готовность не подтверждает (о том, как устроена эта связка, мы говорили в уроке про подключение модели через Ollama). Без уже скачанных компонентов и локальной модели такой запуск не даст готового автономного чата.

Виртуальное окружение app/env изолирует только библиотеки Python, но не является защитной песочницей (sandbox). Рецепт Pinokio исполняет обычные системные команды и операции с файлами на вашем компьютере от вашего имени, а общая поддержка Windows, macOS и Linux со стороны самого лаунчера не означает, что каждый конкретный рецепт проверен на вашей операционной системе и архитектуре процессора. Выбирая этот путь, вы доверяете авторам репозитория pinokiofactory/open-webui.

Если вы не используете Pinokio, но на компьютере уже постоянно запущен Docker Desktop, исходные условия меняются. Для расширения Docker Desktop нужно проверить те же вещи: версии, модель и сетевой доступ.

Docker Extension: контейнер, Docker Model Runner и границы личного доступа

Допустим, Docker Desktop у вас уже установлен, и вы хотите добавить в него Open WebUI через внутренний каталог расширений, чтобы не писать конфигурационные файлы вручную.

Внутри Docker Desktop работает управляющее расширение rw4lll/open-webui-docker-extension, оно обращается к движку Docker и создаёт отдельный контейнер с сервером Open WebUI, а в качестве локального исполнителя моделей по умолчанию настраивает Docker Model Runner (DMR).

Если заглянуть в исходный код релиза 0.3.0, видно, что файл docker-compose.yaml в корне репозитория служит лишь заглушкой, а реальный контейнер запускается программно через containerService.ts с параметрами из constants.ts. Контейнер получает имя openwebui-extension-service, автозапуск и образ ghcr.io/open-webui/open-webui:main. Как и в случае с Pinokio, версии различаются: 0.3.0 — это версия самого расширения, тогда как контейнер Open WebUI скачивается с плавающим тегом :main, и точный выпуск приложения зависит от момента загрузки образа.

Подключение к языковой модели в текущей версии расширения тоже отличается от старых обзоров. Сейчас провиженер openAIEnvProvisioner.ts по умолчанию связывает Open WebUI с локальным сервисом Docker Model Runner по внутреннему адресу http://model-runner.docker.internal/engines/llama.cpp/v1, передавая техническую заглушку not-required вместо ключа API. Название OpenAI-compatible в настройках описывает только стандартный формат обмена данными (протокол, знакомый нам по уроку про подключение OpenAI-совместимого API), а не отправку ваших сообщений в облако компании OpenAI.

Прежде чем считать этот вариант готовым личным решением, нужно проверить четыре условия из кода и документации:

1. Отключённая авторизация и публикация порта. В containerService.ts контейнер создаётся с переменной WEBUI_AUTH=False, которая выключает экран входа с паролем, а порт публикуется аргументом -p ${port}:8080 (по умолчанию порт 8090) без явного указания локального адреса 127.0.0.1. Согласно документации Docker по публикации портов, публикация порта без привязки к IP-адресу по умолчанию открывает его на всех сетевых интерфейсах хоста. Будет ли ваш чат без пароля реально доступен с соседних устройств в локальной сети, зависит от настроек конкретного Docker Desktop, демона и системного межсетевого экрана. Мы не проверяли сетевую доступность на практике. Адрес localhost в браузере сам по себе не доказывает сетевую изоляцию интерфейса.
2. Двойные требования к платформе и доступность карточки. В описании расширения указано общее требование Docker Desktop 4.x+ с включёнными расширениями, а для установки приведена ссылка перехода в Marketplace (extensionId=rw4lll/openwebui-docker-extension). Поскольку мы не открывали интерфейс Docker Desktop, проверьте в своей среде, отображается ли карточка в Marketplace сейчас. Кроме того, если вы рассчитываете на локальные модели через Docker Model Runner, общей пометки «4.x+» недостаточно: в актуальной документации Docker Model Runner отдельно прописаны версии Docker Desktop (например, 4.40+ для macOS и 4.41+ для Windows) и аппаратные требования к видеокартам и процессорам. А существование варианта DMR для серверного Docker Engine не означает, что само графическое расширение заработает без Docker Desktop.
3. Включённые по умолчанию интеграции с инструментами. Расширение не ограничивается только окном чата. В configRepository.ts по умолчанию включена опция enableDockerMcpToolkit: true, а при работающем контейнере компоненты App.tsx и useDockerMcpToolkit.ts вызывают процедуру автоматической настройки интеграции с Docker MCP Toolkit. Сработает ли этот шлюз без дополнительных компонентов — отдельный вопрос, но перед началом работы стоит заглянуть в настройки расширения и проверить, какие именно интеграции активны.
4. Привилегии самого расширения. Как предупреждает документация по безопасности Docker Extensions, расширения обладают широкими полномочиями: они могут обращаться к сокету Docker, файловой системе и запускать исполняемые файлы на хосте, а проверка в Marketplace не равна гарантии безопасности.

Личный чат выбирают для долгой работы. Что произойдёт с диалогами и настройками после обновления, сброса или удаления?

Что сохранится после обновления, сброса или удаления

В сторонних упаковках кнопки Update и Reset выглядят одинаково просто, но выполняют разные операции с файлами и хранилищами. Чтобы данные не пропали неожиданно, нужно заранее разделить три слоя: базу самого Open WebUI (чаты и загруженные файлы), настройки программы-упаковщика и файлы языковых моделей.

В Docker для сохранения базы между перезапусками используется постоянный том (named volume) — отдельное хранилище под управлением Docker, которое остаётся на диске, даже если сам контейнер удалить и создать заново. Однако сохранённый на диске том или папка не равны резервной копии (backup): резервная копия — это отдельно сохранённый и проверенный комплект файлов, из которого систему можно восстановить после поломки или неудачного обновления (общие принципы мы разбирали в уроке про обновления и резервную копию, хотя приведённые там команды для Compose не переносятся автоматически на сторонние лаунчеры).

В изученных исходниках Pinokio и Docker Extension хранение и обслуживание устроены так:

Из этого сравнения следуют три практических вывода:

1. В Pinokio нельзя нажимать Factory Reset ради «чистой переустановки» с сохранением истории. Поскольку папка app/data находится внутри app, скрипт сброса сотрёт пользовательскую базу. Если рецепт Pinokio стоял давно, есть ещё одна деталь: в старых установках данные могли находиться внутри виртуального окружения app/env. В текущем start.js предусмотрено копирование старой папки данных из app/env в app/data, если каталога app/data ещё нет, но мы не испытывали этот перенос на практике, поэтому полагаться на него без собственной подстраховки рискованно.
2. В Docker Extension именованный том — это ещё не вся конфигурация. Да, при штатном нажатии Update & Restart код удаляет только контейнер, оставляя том open-webui-docker-extension-data на месте. Однако настройки самого расширения и ключ WEBUI_SECRET_KEY лежат отдельно — в хранилище самого расширения (localStorage). Кроме того, имена томов расширения (open-webui-docker-extension-data) не совпадают с именами томов из нашего базового курса по Docker Compose, поэтому новый контейнер Compose не подхватит их автоматически.
3. Удаление контейнера или рецепта не очищает диск от тяжёлых моделей. И Ollama, и Docker Model Runner складывают многогигабайтные веса нейросетей в собственные каталоги, не связанные с папкой чатов Open WebUI.

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

Когда выбрать сторонний способ, а когда перейти к Compose или Desktop

Мы не измеряли скорость работы или потребление памяти, поэтому здесь нет универсального «победителя». Разумный выбор зависит от того, какие программы уже стоят на вашем компьютере и насколько вы хотите управлять настройками:

• Остаться на Pinokio уместно, если этот лаунчер уже служит вашей основной рабочей средой, вы доверяете репозиторию pinokiofactory/open-webui, готовы отдельно настроить сервер модели (в рассмотренном локальном сценарии это Ollama) и помните, что кнопка Factory Reset удаляет папку app/data.
• Рассмотреть Docker Extension имеет смысл, если вы уже работаете в Docker Desktop с поддержкой Docker Model Runner на совместимой версии ОС и оборудования, карточка расширения доступна в вашем Marketplace, а отсутствие пароля по умолчанию (WEBUI_AUTH=False), способ публикации порта и включённая по умолчанию интеграция MCP Toolkit вас устраивают или будут проверены перед работой.
• Перейти к установке через Docker Compose стоит во всех случаях, когда вам нужна предсказуемая эксплуатация: явная привязка порта к 127.0.0.1, сохранённый в вашем файле WEBUI_SECRET_KEY, понятное имя тома и возможность в любой момент зафиксировать конкретную версию образа Open WebUI.
• Выбрать Open WebUI Desktop логично тогда, когда вам нужно отдельное нативное приложение для компьютера без сторонних каталогов-лаунчеров и без управления контейнерами через расширения Docker. Если же вы в целом сомневаетесь, какая архитектура подходит под вашу задачу, вернитесь к базовому уроку, где мы выбираем схему установки.

Например, до первой установки решение можно записать так. Допустим, на вашем компьютере уже настроен Docker Desktop и вы используете Docker Model Runner:

• Рассматриваемый кандидат: расширение rw4lll/open-webui-docker-extension (в изученных исходниках — релиз 0.3.0).
• Кто поддерживает упаковку: сторонний автор расширения; команда Open WebUI официально этот способ не поддерживает.
• Правило для версии Open WebUI: по умолчанию скачивается плавающий образ ghcr.io/open-webui/open-webui:main, поэтому точная версия сервера определится только в момент загрузки образа.
• Где будут данные и что изменит обновление: чаты и файлы попадут в том open-webui-docker-extension-data (код штатного обновления Update & Restart этот том не удаляет), а настройки самого расширения и WEBUI_SECRET_KEY будут храниться отдельно в localStorage расширения.
• Кто отвечает за модель: отдельный сервис Docker Model Runner, подключённый по внутреннему OpenAI-совместимому адресу.
• Что нужно проверить до начала работы: открывается ли карточка в Marketplace вашей копии Docker Desktop, подходит ли ваша система под актуальные требования DMR и допустимы ли в вашей сети работа с WEBUI_AUTH=False, публикация порта без 127.0.0.1 и включённая по умолчанию интеграция Docker MCP Toolkit.
• Итоговое решение: пока эти условия в вашей среде не проверены, установку расширения лучше отложить или сразу развернуть контролируемый проект в Docker Compose.

Чтобы закрепить результат урока, сформулируйте для своей системы такую же короткую карточку из шести пунктов: назовите один выбранный способ (или переход к Compose/Desktop), кто поддерживает эту упаковку, как в ней определяется версия Open WebUI, где лежат данные при обновлении, какая отдельная программа отвечает за модель и какое одно условие вам осталось проверить перед стартом.

Выбранная оболочка запуска не определяет сама по себе ни официальную поддержку Open WebUI, ни точный выпуск сервера, ни готовность модели, ни автоматическую сохранность данных. Ставить оба сторонних варианта ради сравнения или пытаться на ходу переносить в них существующую базу чатов не нужно: переходите сразу к выбранному практическому уроку по Docker Compose или Open WebUI Desktop либо сначала проверьте открытое условие своей упаковки на чистой среде.