Огляд 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 для контейнеризації 🗂️

Часті запитання