Arcane 于 2026 年 6 月 7 日在 v2.0.0 版本中推出了完整的基于角色的访问控制。它还会按你设定的计划扫描镜像中的已知漏洞。Brandon Lee 在 2025 年 12 月 29 日发表 Arcane 初体验文章时，这两项都还不存在，那距离 RBAC 发布还有五个多月。
这种时间差正是眼下任何 Arcane Docker 评测都绕不开的尴尬之处。这款工具已经到了 v2.10.2，发布于 2026 年 9 月 5 日，距 v2.9.0 还不到两周。v2.10.0 版本修复了下文讨论的 GitOps 克隆泄漏问题，并为运行中的容器新增了实验性的 Convert to Compose 工作流。哪怕只早几天写下的功能清单，描述的都已经是另一个产品。
TL;DR（太长不看版）
v2.10.2 的 Arcane 对合适的运维人员来说，是一个可用的 Portainer 替代品。它提供完整 RBAC、OIDC 单点登录、Trivy 漏洞扫描和 GitOps 重新部署，不收费、不限节点数。Portainer 则在超过三个节点后把这套角色层级留在了 Business Edition 里。 4 分（满分 5 分）。 拖后腿的是资历，而不是能力。
- 一旦你超过了 Portainer 的第三个节点，并且需要用角色来界定谁能动什么，就该切换了。 你可以获得六个内置角色、自定义角色、按环境分配以及 OIDC 组声明映射，不收费、不计量。
- 漏洞扫描开箱即用。 Arcane 按 cron 计划运行开源镜像扫描器 Trivy，并按镜像存储结果。
- Portainer Business Edition 在三个节点以内免费，且没有功能限制。 在这条线以下，你已经拥有 RBAC 和 SSO，所以 Arcane 的“免费访问控制”论点要弱得多。
- 仍然没有直接导入 Portainer 堆栈的功能。 v2.10.0 可以实验性地把运行中的容器转换为 Compose 项目，省掉一部分手工活，但你仍需审查生成的 YAML 并规划切换，因为原容器还在运行时，名称和已发布端口可能冲突。请先备份卷。
- 在上线前加固
ENCRYPTION_KEY，并正确设置APP_URL。ENCRYPTION_KEY仍然带有开发用的默认值，而在APP_URL指向用户实际访问的 HTTPS 主机名之前，通行密钥登录不会生效。JWT_SECRET根据当前安装文档，已不再使用。 - 针对 v2.8.0 和 v2.9.0 报告的 GitOps 磁盘耗尽 bug 已在 v2.10.0 中修复。 该修复会清理残留的 Git 克隆临时目录，而不是任其在管理器主机上堆积。
- LDAP 依然缺席。 身份集成仅支持 OIDC。
本评估是如何完成的： 这是一篇基于证据的评测，而非上手实测。没有赞助、没有酬劳、没有提供产品、没有与维护者接触。每一项功能主张都对照 Arcane 当前的文档和发布说明核实过，每一项可靠性主张都能追溯到项目公开跟踪器上有日期的 issue，或某位实名运维人员对自身部署的记述。我们没有人为了写这篇文章去运行 Arcane，因此在这限制判断的地方（界面用起来什么感觉、持续负载下表现如何），文章会明说，而不是猜测。
Arcane 免费提供了哪些 Portainer 没有的东西？
主要是一件事：完整的基于角色的访问控制。Portainer CE 只提供基础的用户管理，角色层级属于 Business Edition。Arcane 在任意节点数下免费提供它，同时还有 Trivy 扫描、GitOps 重新部署、Swarm 支持、通行密钥登录、远程代理，以及 v2.9.0 新增的 S3 备份。
RBAC 是值得仔细看的部分，因为“有 RBAC”这句话背后可能是截然不同的东西。 Arcane 的访问控制文档 描述了六个不可修改的内置角色：Admin、Editor、No-Shell Editor、Deployer、Monitor 和 Viewer。你可以把任意一个克隆为自定义角色并逐项勾选权限，权限遵循 <resource>:<action> 的形式，例如 containers:start。分配可以是全局的，也可以按环境进行，一个用户可以同时持有多个。文档直接给出了例子： 在 prod 上是 Editor，在 staging 上是 Viewer.
对 SSO 推广真正重要的是，角色分配可以由身份提供方本身驱动：“每次登录时，Arcane 都会读取用户的组声明，并重新同步其来自 OIDC 的分配”，处于多个已映射组中的用户会获得它们的并集。这正是 Portainer CE 从未有过的权限模型。
漏洞扫描是第二块。 Arcane 的扫描文档 指出“扫描需要主动开启，按 cron 计划运行，结果按镜像存储”，并在界面中展示结果。默认每天午夜运行， trivyIgnoreUnfixed 会把结果收窄到已有修复的漏洞，而 Trivy 随一个固定版本的工具镜像一起发布，所以扫描器的更新不用你操心。
接下来是反方的砝码，而且分量不小。 Portainer 自己的 CE 与 BE 对比页面 写道，Business Edition“在 3 个节点以内永久免费。没有试用期。不需要信用卡。没有功能限制。”这是完整的 BE 套件：带自有角色层级的 RBAC、OIDC、支持 Syslog 导出的审计日志、高级 GitOps。 Take 3 条款 签发为期一年的许可证，只要你保持在三个节点或更少，每年免费续期。
所以免费层的账只有到第四个节点才开始对 Arcane 有利。在此之下，付费墙根本不存在。在一两个节点的规模下，Arcane 仍有可取之处：没有许可证密钥，没有需要记住的续期，是一个可以 fork 的项目。但这和“RBAC 要花钱”不是同一个论点。
Arcane 是认真竞争 Portainer 位置的四款工具之一，其余几款的分野在别的维度上。
Arcane 现在有多可靠？
比 v2.9.0 时看起来要好，但仍然年轻。Arcane 的历史 bug 记录读起来像一个积极修复问题的活跃项目，而针对 v2.8.0 和 v2.9.0 报告的严重 GitOps 磁盘耗尽 bug 已于 2026 年 8 月 31 日在 v2.10.0 中修复。
一位运维人员在 2026 年 8 月 26 日报告称 GitOps 同步会泄漏克隆目录："gitops-<N> 克隆目录以每天约 1,000 个（约 9 GB/天）的速度堆积，从不清理，最终填满磁盘。" 六天下来累计约 6,467 个目录和 40 GB。磁盘写满后，管理器无法再写入其 SQLite 数据库，陷入重启循环，重启计数达到 389 次，并连带拖垮了边缘代理连接和 API 调用。该 issue 现已关闭，v2.10.0 附带了清理残留 Git 克隆临时目录的修复。
如果你还在使用 v2.8.0 或 v2.9.0： 在依赖频繁的 GitOps 同步之前先升级。克隆泄漏的修复随 v2.10.0 发布。
更早的记录则更令人放心。一个 2.0 升级到 2.0.1 后的挂起问题 已经解决。一个 “Update Projects”会作用于每个容器 （影响主机上的全部容器而非所选项目）的 bug，随修复 PR #2289 合并而关闭。 镜像轮询静默失效 的问题出现在 v1.13.2，已在 v1.14.0 修复。三个 bug，三个修复。
未关闭 issue 的原始数量 对于一个发布节奏如此之快的项目，本身说明不了什么。没人提 issue 的项目并不因此更可靠。
我的判断仍然是：这是资历问题，而不是能力问题。快速发布是 RBAC 和扫描缺口得以补上的原因，也是 v2.10.0 不得不在 v2.9.0 之后不到一周就修复严重 GitOps 缺陷的原因。风险在新代码里，而采用它是一种选择。
从 Portainer 切换过来究竟要付出什么？
大致是一段停机窗口加一些手工清理。Arcane 仍然没有直接导入 Portainer 堆栈的功能，但 v2.10.0 为运行中的容器新增了实验性的 Convert to Compose 操作。它会在原容器继续运行时生成 Compose 文件，省去一部分重写 YAML 的工作。你仍需检查 bind 挂载、网络、环境变量值以及切换本身；在原容器停止之前，名称和已发布端口可能冲突，所以这不是零停机的迁移按钮。
在 v2.10.0 之前，项目自己的讨论区反映的是一条完全手动的路径。一位在五台服务器上运行着 80 多个容器的运维人员 询问是否可以在线迁移 ，而不必先关停面向 Web 的服务。一位已经做过的人回答说：“你别无选择，只能删除现有容器（也就是 Portainer 堆栈），然后在 Arcane 中从头重建。”他的顺序是：干净地关停、备份、删除、拷贝数据、重建并重新部署。
实际操作上：动手之前先备份卷，并根据你运行的堆栈数量和需要搬迁的数据量来安排维护窗口。重建容器通常是快的部分；拷贝大体积卷以及按正确顺序把有依赖的服务拉起来，可能会拉长窗口。规划时的一个术语提示：Portainer 里叫堆栈的东西，在 Arcane 里叫项目。
即使是家庭实验室规模，时间成本也躲不掉。Moises Aguirre 在 2026 年 2 月 28 日写到 把家庭实验室从 Portainer 迁走时，称之为“扎扎实实一个周末的工作（以及直面我的心魔）”，而这些心魔就是他自己的配置漂移：他不得不逐一盘点正在运行的每个容器，并为那些以前“只是点几下就建起来”的服务编写 YAML。这是他的经历而非定律，但这种模式具有普遍性。
在把 Compose 文件搬过去之前，有一件事需要留意。 v2.7.0 的发布说明 把变量解析收窄到四个来源： .env.global中的全局变量、项目自己的 .env 文件、写在 compose 文件本身中的默认值，以及来自 Arcane 环境的时区和区域设置。其声明的效果是，通过 Arcane 部署的项目解析变量的方式与在项目目录中执行 docker compose up 完全一致。这是更正确的行为。但这也意味着，任何原本悄悄从管理器自身容器环境继承值的配置，现在会解析成别的值，或者什么都没有，而且不会有任何提示。
这些都不是产品缺陷。这是一次性成本，足够可预期，可以提前规划，而这正是你对一次迁移最主要的期望。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 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 或十六进制）。”
版本卫生也应列入这份清单。Arcane 在 2026 年发布了多份安全公告；其中一份高危公告于 2026 年 7 月 29 日发布，将 v2.5.0 之前的版本列为受影响，指出被委派的 users:update 权限可以重置管理员密码。公告将 v2.6.0 列为已修补版本，因此 v2.10.0 不受影响，但这是一个具体的理由：不要让生产部署停留在旧标签上。
APP_URL 的默认值是 http://localhost:3552，而这一项除了卫生问题之外还有功能上的后果。通行密钥登录和通行密钥 MFA 都基于 WebAuthn，而 Arcane 的通行密钥文档 说得很明确：“浏览器只在安全上下文中暴露 WebAuthn API，所以通行密钥需要 HTTPS（或 localhost）。”依赖方 ID 由 APP_URL派生，通行密钥绑定到该主机名，如果 APP_URL 不包含主机名，通行密钥服务就不会初始化。在纯 HTTP 下，Arcane 会完全隐藏通行密钥控件。用裸 IP 加端口部署，v2 的招牌认证功能就不会出现。文档说得很直白：“在任何人注册通行密钥之前，把 APP_URL 设置为用户实际访问的 HTTPS URL。”
远程代理决定了你需要开放什么。 Arcane 的环境文档 指出，在直连模式下“Manager 通过 TCP 3553连接到 Agent”，因此该端口必须能在远程主机上接受入站连接。在边缘模式下，“Agent 主动向外连接 Manager”，完全不需要入站端口。
再往下，我宁愿给出指引，也不愿假装懂。Arcane 发布了 一份 socket 代理配置指南 ，其前提是直接挂载 socket“会让 Arcane 获得对 Docker 的完全访问权限”，而代理可以把它收窄到所需的 API 调用。这与让 隔离 Docker socket 变得值得 的暴露面是同一个，在这里同样值得做。我是以部署者的视角阅读这些文档，而不是在审计其令牌方案。
Arcane 还有哪些做不到？
对照 Arcane 当前的文档，仍有两个缺口：没有 LDAP，也没有针对容器自身文件系统的通用浏览器。v2 之前存在的其他几个缺口，此后已经补上。
LDAP 缺席。 Arcane 的单点登录文档 只涵盖 OIDC，且无论是该文档还是访问控制页面，都没有任何地方提到 LDAP 或 Active Directory。 Portainer 的 Business Edition则相反，可与“Active Directory、LDAP 以及兼容 OIDC 的身份提供方”集成。如果你的组织通过一个前面没有 OIDC 层的目录服务进行认证，这就是硬性障碍，而不是可以绕过的问题。
容器内部没有通用的文件浏览器。 Arcane 的容器视图展示配置、挂载、日志和 Compose 源码，但没有针对容器自身文件系统的浏览器。它现在有了 Volume Workspace，可以浏览和编辑 Docker 卷内的文件，所以剩下的缺口比过去“没有文件浏览器”的说法要窄。
这些更正值得明说，因为“没有 RBAC、没有漏洞扫描”的 Arcane 描述已经不成立了。RBAC 随 2026 年 6 月 7 日的 v2.0.0到来，Trivy 扫描已有文档记载并按计划运行。活动日志也有了进展： Arcane 的活动文档 描述了一个覆盖拉取、构建、生命周期操作、扫描和清理的 Activity Center，以及一份记录严重程度、类型、时间戳和触发者（在 Arcane 能归因的情况下）的事件日志。它是否像 Portainer 的 Business 层那样导出到 Syslog，文档并未说明。
发布速度弥补不了的是年头。Arcane 的仓库创建于 2025 年 4 月。Portainer 背后有多年积累的 Stack Overflow 回答、第三方指南和集成，当你在晚上 11 点撞上一个奇怪的问题时，你感受到的正是这种差距。
谁应该切换到 Arcane，谁不应该？
如果你在 Portainer 上已超过三个节点，想要带作用域的多用户访问和由 git 跟踪的 Compose，又不想谈许可证，就切换到 Arcane。如果你在三个节点或更少，就保持原状。数一数主机，比任何功能清单都能更快解决大部分问题。
Arcane 明确适合的三类人：
- 超过 Portainer 三节点上限、需要作用域访问控制的运维人员。 超过三个节点后，这些能力在 Portainer 要收费，在 Arcane 则免费，而且角色足够细，可以让某人在一个环境里是 Deployer，在其他所有环境里是 Viewer。
- 希望以 Compose 文件为唯一事实来源的运维人员。 如果推动你迁移的原因是堆栈定义存在数据库里而不是仓库里，那这是结构上的契合，而非偏好。迁移的那个周末大部分时间都花在把你已经在运行的东西写下来，这本来就是你欠下的工作。
- 整合多台主机（包括 NAT 后面的主机）的运维人员。 边缘模式的代理在远端不需要入站端口，Swarm 集群从管理器节点统一管理，远程环境不花一分钱。
不适合的两类人：
- 三个节点或更少的任何人。 这个规模下 Business Edition 免费且功能齐全，切换意味着花掉一段停机窗口和一个周末，换来你本来就有的能力。作为 Portainer 的替代品，Arcane 是称职的；但这仍然不是搬家的理由。
- 需要 LDAP，或者无法停掉堆栈的任何人。 目录认证不可用，迁移仍然需要计划内的切换。两者都没有巧妙的变通办法。
这个结论附带一个条件。如果 GitOps 重新部署正是你迁移的原因，请使用 v2.10.0 或更新版本。针对 v2.8.0 和 v2.9.0 报告的磁盘耗尽 bug 已在其中修复。
常见问题
Arcane 免费吗？
是的。Arcane 免费，采用 BSD-3-Clause 许可证，没有付费层级、没有企业版，也不按节点数限制功能。基于角色的访问控制、OIDC 单点登录、漏洞扫描、远程环境和 GitOps 重新部署全部包含在内。唯一的成本是你用来运行它的机器。
Arcane 需要多少内存？
项目没有公布最低要求。Arcane 的安装文档没有给出内存或 CPU 的下限，支持的硬件从 x86 服务器一直到 Raspberry Pi 级别的开发板。一位 记录了自己迁移过程的运维人员 报告称，其管理容器“从约 150MB 内存（Portainer）降到了约 67MB（Arcane）”。规模由你管理的容器决定，而不是由 Arcane 决定。
Arcane 支持多主机吗？
支持，通过远程环境代理实现。边缘模式让代理主动向外连接管理器，因此不需要入站端口，也能覆盖 NAT 或防火墙后面的主机；直连模式则由管理器主动连入。 支持 Docker Swarm ，在管理器节点上拥有完整控制权，在工作节点上提供只读视图。
在生产环境运行 Arcane 安全吗？
取决于你启用了什么。首次登录时修改默认管理员密码，替换 ENCRYPTION_KEY的默认值，并让 Arcane 在 TLS 之后运行，同时配置正确的 APP_URL，这是通行密钥正常工作的前提。 JWT_SECRET 已不再使用，针对 v2.8.0 和 v2.9.0 报告的 GitOps 克隆泄漏也已在其中修复，所以生产部署应从 v2.10.0 或更新版本开始。
Arcane 与 Dockge 或 Dockhand 相比如何？
Dockge 更小巧，只面向 Compose，如果你只想要一个堆栈编辑器，它更合适。Dockhand 更侧重镜像安全扫描。Arcane 是三者中覆盖面最广的工具，也是唯一免费提供 RBAC 的；Dockhand 的 RBAC 属于 Enterprise 层级。
讨论
评论
登录后参与讨论。