Обзор Arcane для Docker: готов ли он заменить Portainer?

Arcane выпустил полноценное управление доступом на основе ролей 7 июня 2026 года, в релизе v2.0.0. Он также сканирует ваши образы на известные уязвимости по расписанию, которое задаёте вы. Ничего из этого не было, когда Брэндон Ли (Brandon Lee) опубликовал свои первые впечатления от Arcane 29 декабря 2025 года — чуть больше чем за пять месяцев до релиза с RBAC.

Этот разрыв — самая неудобная часть любого обзора Arcane для Docker прямо сейчас. Инструмент уже на v2.10.2, выпущенной 5 сентября 2026 года, меньше чем через две недели после v2.9.0. Релиз v2.10.0 исправил утечку клонов GitOps, о которой речь ниже, и добавил экспериментальный сценарий Convert to Compose для работающих контейнеров. Список функций, написанный даже на несколько дней раньше, описывает уже другой продукт.

Кратко (TL;DR)

Arcane на v2.10.2 — рабочая замена Portainer для подходящего оператора. Он даёт полный RBAC, единый вход по OIDC, сканирование уязвимостей Trivy и повторное развёртывание GitOps без оплаты и без потолка по узлам. Portainer держит эту иерархию ролей в Business Edition, когда узлов больше трёх. 4 из 5. Сдерживает его не функциональность, а короткая история.

• Переходите, когда у вас больше трёх узлов Portainer и нужны роли, ограничивающие, кто к чему имеет доступ. Вы получаете шесть встроенных ролей, собственные роли, назначение по окружениям и сопоставление групповых claim OIDC — без оплаты и без счётчиков.
• Сканирование уязвимостей идёт из коробки. Arcane запускает Trivy, сканер образов с открытым исходным кодом, по расписанию cron и хранит результаты по каждому образу.
• Portainer Business Edition бесплатен до трёх узлов, без ограничений функциональности. Ниже этой черты у вас уже есть RBAC и SSO, так что аргумент Arcane о бесплатном доступе там намного слабее.
• Прямого импорта стеков Portainer по-прежнему нет. v2.10.0 умеет экспериментально преобразовывать работающие контейнеры в проекты Compose, что снимает часть ручной работы, но вам всё равно нужно проверить сгенерированный YAML и спланировать переключение: имена и опубликованные порты могут конфликтовать, пока оригиналы работают. Сначала сделайте резервные копии томов.
• Защитите ENCRYPTION_KEY до продакшена и задайте APP_URL правильно. ENCRYPTION_KEY по-прежнему имеет значение по умолчанию для разработки, а вход по passkey не заработает, пока APP_URL не будет указывать на HTTPS-имя хоста, которое пользователи реально открывают. JWT_SECRET больше не используется, согласно актуальной документации по установке.
• Ошибка GitOps с переполнением диска, о которой сообщали для v2.8.0 и v2.9.0, исправлена в v2.10.0. Исправление очищает оставшиеся временные каталоги клонов Git вместо того, чтобы позволять им копиться на хосте менеджера.
• LDAP по-прежнему нет. Интеграция с провайдерами идентификации — только через OIDC.

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

Что Arcane даёт бесплатно, чего не даёт Portainer?

В основном одно: полноценное управление доступом на основе ролей. Portainer CE даёт базовое управление пользователями; иерархия ролей — это Business Edition. Arcane предоставляет её бесплатно при любом числе узлов, вместе со сканированием Trivy, повторным развёртыванием GitOps, поддержкой Swarm, входом по passkey, удалёнными агентами и резервными копиями в S3, добавленными в v2.9.0.

RBAC — та часть, к которой стоит присмотреться, потому что «есть RBAC» может означать очень разные вещи. Документация Arcane по управлению доступом описывает шесть неизменяемых встроенных ролей: Admin, Editor, No-Shell Editor, Deployer, Monitor и Viewer. Любую из них можно клонировать в собственную роль и отметить отдельные разрешения, которые имеют <resource>:<action> вид наподобие containers:start. Назначения бывают глобальными или по окружениям, и у пользователя их может быть несколько одновременно. Документация приводит пример напрямую: Editor на prod, Viewer на staging.

Для внедрения SSO важно то, что назначением ролей может управлять сам провайдер идентификации: «При каждом входе Arcane читает групповой claim пользователя и заново синхронизирует его назначения, полученные из OIDC», а пользователь в нескольких сопоставленных группах получает их объединение. Это та модель разрешений, которой у Portainer CE никогда не было.

Сканирование уязвимостей — второй элемент. Документация Arcane по сканированию сообщает, что «сканирование включается по желанию, выполняется по расписанию cron, а результаты хранятся по каждому образу», при этом результаты показываются в интерфейсе. По умолчанию оно запускается ежедневно в полночь, trivyIgnoreUnfixed сужает результаты до уязвимостей с известным исправлением, а Trivy поставляется в образе с инструментами с закреплённой версией, так что за обновлениями сканера следить не вам.

Теперь противовес, и он серьёзный. Собственная страница Portainer о сравнении CE и BE говорит, что Business Edition «бесплатна навсегда до 3 узлов. Без пробного периода. Без банковской карты. Без ограничений функциональности». Это полный набор BE: RBAC с собственной иерархией ролей, OIDC, журналы аудита с экспортом в Syslog, продвинутый GitOps. Условия программы Take 3 выдают годовую лицензию, которая ежегодно продлевается бесплатно, пока у вас три узла или меньше.

Так что арифметика бесплатного уровня начинает работать в пользу Arcane только с четвёртого узла. Ниже этой границы платного барьера нет. Arcane всё же кое-что даёт и при одном-двух узлах: никакого лицензионного ключа, никакого продления, о котором нужно помнить, проект, который можно форкнуть. Но это не тот же аргумент, что «RBAC стоит денег».

Arcane — один из четырёх инструментов, всерьёз претендующих на место Portainer, и остальные расходятся по другим линиям.

ЧИТАТЬ

Альтернативы Portainer: практическое руководство по Dockge, Arcane, Dockhand и Komodo

Насколько надёжен Arcane прямо сейчас?

Лучше, чем казалось на v2.9.0, но всё ещё молод. История ошибок Arcane читается как история активного проекта, который чинит проблемы, а серьёзная ошибка GitOps с переполнением диска, о которой сообщали для v2.8.0 и v2.9.0, была исправлена в v2.10.0 31 августа 2026 года.

26 августа 2026 года один оператор сообщил, что синхронизация GitOps оставляет после себя каталог клона: "gitops-<N> каталоги клонов накапливаются примерно по 1000 в день (~9 ГБ/день) и никогда не очищаются, в итоге заполняя диск." Шесть дней такого режима дали примерно 6467 каталогов и 40 ГБ. Когда диск заполнился, менеджер больше не мог писать в свою базу SQLite и ушёл в цикл перезапусков, дойдя до 389 перезапусков и утянув за собой соединения edge-агентов и вызовы API. Задача уже закрыта, а v2.10.0 содержит исправление, которое очищает оставшиеся временные каталоги клонов Git.

Если вы всё ещё на v2.8.0 или v2.9.0: обновитесь, прежде чем полагаться на частую синхронизацию GitOps. Исправление утечки клонов выходит в v2.10.0.

Более ранняя история обнадёживает больше. Одно зависание после обновления между 2.0 и 2.0.1 было устранено. Ошибка, при которой «Update Projects» затрагивал каждый контейнер на хосте вместо контейнеров выбранного проекта, была закрыта влитым PR с исправлением #2289. Опрос образов, который молча не срабатывал в v1.13.2, исправлен в v1.14.0. Три ошибки, три исправления.

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

Моя оценка по-прежнему такова: это проблема возраста, а не возможностей. Быстрый выпуск релизов — причина, по которой пробелы в RBAC и сканировании вообще закрылись, и та же причина, по которой v2.10.0 пришлось исправлять серьёзный дефект GitOps меньше чем через неделю после v2.9.0. Риск сидит в новом коде, и брать его — осознанный выбор.

Во что на самом деле обходится переход с Portainer?

Грубо говоря, окно простоя и немного ручной уборки. Прямого импорта стеков Portainer в Arcane по-прежнему нет, но v2.10.0 добавляет экспериментальное действие Convert to Compose для работающих контейнеров. Оно генерирует файл Compose, пока оригиналы продолжают работать, что снимает часть работы по восстановлению YAML. Вам всё равно нужно проверить bind-монтирования, сети, значения окружения и само переключение; имена и опубликованные порты могут конфликтовать, пока оригиналы не остановлены, так что это не кнопка миграции без простоя.

До v2.10.0 форум проекта отражал полностью ручной путь. Оператор с более чем 80 контейнерами на пяти серверах спросил, возможна ли живая миграция без предварительной остановки сервисов, смотрящих в веб. Ответ того, кто уже прошёл через это: «у вас не будет иного выбора, кроме как удалить существующие контейнеры (а значит, и стеки Portainer) и пересоздать их с нуля в Arcane». Его последовательность: аккуратно остановить, сделать резервную копию, удалить, перенести данные, пересоздать и развернуть заново.

На практике: резервные копии томов до того, как вы что-либо тронете, и окно обслуживания, рассчитанное и по числу стеков, и по объёму данных, которые нужно перенести. Пересоздание контейнеров обычно быстрая часть; копирование больших томов и поднятие зависимых сервисов в правильном порядке могут растянуть окно. Замечание по терминологии на время планирования: то, что Portainer называет стеком, Arcane называет проектом.

Затраты времени ощутимы даже в масштабе домашней лаборатории. Мойзес Агирре (Moises Aguirre), писавший 28 февраля 2026 года о переезде домашней лаборатории с Portainer, назвал это «полноценными выходными работы (и встречей с собственными демонами)», а демонами был его собственный разнобой: ему пришлось проверить каждый работающий контейнер и написать YAML для сервисов, которые он раньше «просто накликал». Это его опыт, а не правило, но картина узнаваема.

Одна вещь, которую стоит поймать до переноса файлов Compose. Заметки к релизу v2.7.0 сузили разрешение переменных до четырёх источников: ваши глобальные переменные в .env.global, собственный файл .env проекта, значения по умолчанию, прописанные в самом файле compose, а также часовой пояс и локаль из окружения Arcane. Заявленный эффект в том, что проект, развёрнутый через Arcane, разрешает переменные так же, как docker compose up в каталоге проекта. Это более корректное поведение. Но это также значит, что всё, что негласно наследовало значение из окружения контейнера самого менеджера, теперь разрешится во что-то другое или в пустоту — и сделает это без единого предупреждения.

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

Разрабатывайте на Linux VPS с root-доступом, NVMe и мощью AMD EPYC.

Посмотреть тарифы Linux

Что нужно защитить перед продакшеном?

Один ключ шифрования, публичный URL и TLS. Arcane создаёт учётную запись администратора по умолчанию при первом запуске и требует сменить пароль при первом входе — разумное поведение по умолчанию. Две настройки должны быть правильными до продакшена. Первая — ENCRYPTION_KEY; вторая — APP_URL.

Справочник переменных окружения по-прежнему указывает ENCRYPTION_KEY со значением по умолчанию arcane-dev-key-32-characters!!!, тогда как документация по установке требует задать уникальное 32-байтовое значение. Смените его до продакшена. Изменилось ещё кое-что: документация по установке теперь говорит, что JWT_SECRET больше не используется. Arcane сам генерирует ключ подписи сессий; если оставить JWT_SECRET в конфигурации, это лишь даст предупреждение при запуске, так что уберите его из окружения. Документация по установке указывает, что ENCRYPTION_KEY «должен иметь длину 32 байта (в сыром виде, base64 или hex)».

Гигиена версий тоже входит в этот список. В 2026 году Arcane опубликовал несколько бюллетеней безопасности; один из них, высокой серьёзности, опубликованный 29 июля 2026 года, указывает уязвимыми версии до v2.5.0 и описывает, как делегированное разрешение users:update позволяло сбросить пароль администратора. Исправленным релизом назван v2.6.0, так что v2.10.0 не затронут, но это конкретная причина не оставлять продакшен-развёртывание на старом теге.

APP_URL по умолчанию равен http://localhost:3552, и у этого есть функциональное последствие помимо гигиены. Вход по passkey и MFA по passkey работают на WebAuthn, а документация Arcane по passkey говорит прямо: «Браузеры предоставляют API WebAuthn только в безопасном контексте, поэтому passkey требуют HTTPS (или localhost)». Идентификатор relying party выводится из APP_URL, passkey привязаны к этому имени хоста, и если APP_URL не содержит имени хоста, сервис passkey не инициализируется. На обычном HTTP Arcane полностью скрывает элементы управления passkey. Разверните на голом IP с портом — и главной функции аутентификации v2 просто не будет. Документация формулирует это ясно: «Задайте APP_URL равным URL, который ваши пользователи реально открывают, по HTTPS, до того, как кто-либо зарегистрирует passkey».

Удалённые агенты определяют, что вам придётся открыть. Документация Arcane по окружениям говорит, что в прямом режиме «Manager подключается к Agent по TCP 3553», так что этот порт должен быть доступен для входящих подключений на удалённом хосте. В режиме edge «Agent подключается к Manager исходящим соединением» и не требует входящего порта вовсе.

Дальше я предпочитаю указать, а не делать вид. Arcane публикует руководство по настройке прокси для сокета , исходная посылка которого в том, что прямое монтирование сокета «даёт Arcane полный доступ к Docker», а прокси сужает его до нужных вызовов API. Та же уязвимая поверхность, из-за которой изоляция сокета Docker стоит усилий где угодно — и здесь тоже. Я читаю эти документы так, как их читает тот, кто разворачивает, а не аудитор схемы токенов.

Чего Arcane по-прежнему не умеет?

Два пробела всё ещё сохраняются, если судить по актуальной документации Arcane: нет LDAP и нет общего обозревателя файловой системы самого контейнера. Несколько других пробелов, существовавших до v2, с тех пор закрылись.

LDAP отсутствует. Документация Arcane по единому входу описывает OIDC и только OIDC, и ни она, ни страница управления доступом нигде не упоминают LDAP или Active Directory. Business Edition от Portainer, напротив, интегрируется с «Active Directory, LDAP и провайдерами идентификации, совместимыми с OIDC». Если ваша организация аутентифицируется через каталог без OIDC-прослойки перед ним, это жёсткий стоп, а не обходной путь.

Нет общего файлового обозревателя внутри контейнеров. Представление контейнера в Arcane показывает конфигурацию, монтирования, журналы и исходник Compose, но не обозреватель файловой системы самого контейнера. Зато теперь есть Volume Workspace, который позволяет просматривать и редактировать файлы внутри томов Docker, так что оставшийся пробел уже уже, чем старое описание «нет файлового обозревателя».

Эти поправки стоит проговорить прямо, потому что описание Arcane как «без RBAC, без сканирования уязвимостей» больше не соответствует действительности. RBAC появился в v2.0.0 7 июня 2026 года, а сканирование Trivy задокументировано и работает по расписанию. Журналирование активности тоже изменилось: документация Arcane по активности описывает Activity Center, охватывающий загрузки, сборки, действия жизненного цикла, сканирования и очистки, а рядом — журнал событий с серьёзностью, типом, отметкой времени и пользователем, инициировавшим каждое действие, когда Arcane может его определить. Экспортирует ли он в Syslog, как это делает уровень Business у Portainer, документация не проясняет.

Чего скорость релизов не исправляет, так это возраста. Репозиторий Arcane создан в апреле 2025 года. За Portainer стоят годы накопленных ответов на Stack Overflow, сторонних руководств и интеграций, и когда в 11 вечера вы натыкаетесь на что-то странное, именно эту разницу вы и чувствуете.

Кому стоит перейти на Arcane, а кому нет?

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

Три профиля, для которых Arcane — однозначное «да»:

• Операторы за пределами трёхузлового потолка Portainer, которым нужен доступ с ограниченными правами. Свыше трёх узлов эти возможности стоят денег у Portainer и ничего не стоят у Arcane, а роли достаточно детальны, чтобы дать кому-то Deployer в одном окружении и Viewer во всех остальных.
• Операторы, которые хотят видеть файлы Compose источником истины. Если переход мотивирован тем, что определения стеков живут в базе данных, а не в репозитории, это структурное совпадение, а не предпочтение. Миграционные выходные уходят в основном на то, чтобы записать то, что у вас и так уже работает, а эту работу вы и без того были должны.
• Операторы, объединяющие несколько хостов, в том числе за NAT. Агентам в режиме edge не нужен входящий порт на удалённой стороне, кластеры Swarm управляются с узла-менеджера, а удалённые окружения ничего не стоят.

Два профиля, для которых это не так:

• Все, у кого три узла или меньше. Business Edition в этом масштабе бесплатна с полным набором функций, так что переход тратит окно простоя и выходные ради возможностей, которые у вас уже есть. Как альтернатива Portainer Arcane состоятелен; но это всё равно не повод переезжать.
• Все, кому нужен LDAP или кто не может остановить стеки. Аутентификации через каталог нет, а миграция по-прежнему требует спланированного переключения. Ни для того, ни для другого нет хитрого обходного пути.

К этому вердикту прилагается одно условие. Если вы переходите именно ради повторного развёртывания GitOps, используйте v2.10.0 или новее. Ошибка с переполнением диска, о которой сообщали для v2.8.0 и v2.9.0, там исправлена.

ЧИТАТЬ

Как поставить Docker на VPS: подробное руководство по использованию VPS для контейнеризации 🗂️

Часто задаваемые вопросы