Arcane Docker 리뷰: Portainer를 대체할 준비가 되었나?

Arcane은 2026년 6월 7일 v2.0.0 릴리스에서 전체 역할 기반 접근 제어를 출시했습니다. 직접 설정한 일정에 따라 이미지에서 알려진 취약점도 스캔합니다. Brandon Lee가 2025년 12월 29일 Arcane 첫인상 글을 올렸을 때는 둘 다 없던 기능으로, RBAC 릴리스보다 다섯 달 남짓 앞선 시점이었습니다.

이 간극이 지금 어떤 Arcane Docker 리뷰에서도 곤란한 부분입니다. 이 도구는 이미 2026년 9월 5일에 나온 v2.10.2에 도달했는데, v2.9.0 이후 2주도 지나지 않은 시점입니다. v2.10.0 릴리스는 아래에서 다루는 GitOps 클론 누수를 고쳤고, 실행 중인 컨테이너를 위한 실험적 Convert to Compose 워크플로를 추가했습니다. 며칠만 먼저 작성된 기능 목록도 다른 제품을 설명하는 셈입니다.

요약

v2.10.2의 Arcane은 조건이 맞는 운영자에게는 쓸 만한 Portainer 대체재입니다. 전체 RBAC, OIDC 싱글 사인온, Trivy 취약점 스캔, GitOps 재배포를 비용 없이, 노드 상한 없이 제공합니다. Portainer는 3노드를 넘으면 이 역할 계층을 Business Edition에 묶어 둡니다. 5점 만점에 4점. 발목을 잡는 것은 짧은 이력이지, 역량이 아닙니다.

• Portainer의 세 번째 노드를 넘어서고, 누가 무엇을 만질 수 있는지 범위를 정하는 역할이 필요해지면 전환하세요. 내장 역할 6개, 사용자 지정 역할, 환경별 할당, OIDC 그룹 클레임 매핑을 비용도 사용량 제한도 없이 얻습니다.
• 취약점 스캔이 기본 내장되어 있습니다. Arcane은 오픈 소스 이미지 스캐너인 Trivy를 cron 일정으로 실행하고 결과를 이미지별로 저장합니다.
• Portainer Business Edition은 3노드까지 기능 제한 없이 무료입니다. 그 선 아래에서는 이미 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 디스크 고갈 버그는 v2.10.0에서 수정되었습니다. 이 수정은 남은 Git 클론 임시 디렉터리를 매니저 호스트에 쌓아 두는 대신 정리합니다.
• LDAP은 여전히 없습니다. ID 연동은 OIDC뿐입니다.

이 평가는 이렇게 작성되었습니다: 이 글은 증거 기반 리뷰이지 직접 테스트가 아닙니다. 후원도, 대가도, 제공받은 제품도, 메인테이너와의 접촉도 없습니다. 기능에 관한 모든 주장은 Arcane의 현행 문서와 릴리스 노트로 확인했고, 신뢰성에 관한 모든 주장은 프로젝트 공개 트래커의 날짜가 있는 이슈나 자신의 배포 환경에 대해 쓴 실명 운영자에게로 거슬러 올라갑니다. 이 글을 쓰기 위해 Arcane을 직접 실행한 사람은 없으므로, 그 점이 판단을 제한하는 부분(인터페이스의 사용감, 지속적인 부하에서의 안정성)은 추측하는 대신 그렇다고 밝힙니다.

Arcane이 Portainer와 달리 무료로 주는 것은?

주로 한 가지, 전체 역할 기반 접근 제어입니다. Portainer CE는 기본적인 사용자 관리만 제공하고, 역할 계층은 Business Edition에 있습니다. Arcane은 이를 노드 수와 상관없이 무료로 제공하며, Trivy 스캔, GitOps 재배포, Swarm 지원, 패스키 로그인, 원격 에이전트, v2.9.0에서 추가된 S3 백업도 함께 갖추고 있습니다.

RBAC는 자세히 들여다볼 가치가 있는 부분입니다. "RBAC가 있다"는 말이 아주 다른 것들을 뭉뚱그리기 때문입니다. Arcane의 접근 제어 문서 에는 변경 불가능한 내장 역할 6개가 설명되어 있습니다: Admin, Editor, No-Shell Editor, Deployer, Monitor, Viewer. 어떤 역할이든 사용자 지정 역할로 복제해 개별 권한을 체크할 수 있으며, 권한은 <resource>:<action> 형식을 따릅니다. 예를 들면 containers:start입니다. 할당은 전역 또는 환경별로 이루어지고, 한 사용자가 여러 할당을 동시에 가질 수 있습니다. 문서는 예시를 바로 보여 줍니다: prod에서는 Editor, staging에서는 Viewer.

SSO 도입에서 중요한 부분은 역할 할당을 ID 공급자 쪽에서 주도할 수 있다는 점입니다. "로그인할 때마다 Arcane은 사용자의 그룹 클레임을 읽어 OIDC에서 온 할당을 다시 동기화"하며, 매핑된 여러 그룹에 속한 사용자는 그 합집합을 받습니다. 이것이 Portainer CE에는 한 번도 없었던 권한 모델입니다.

취약점 스캔이 두 번째 요소입니다. Arcane의 스캔 문서 는 "스캔은 옵트인이며 cron 일정으로 실행되고 결과는 이미지별로 저장된다"고 명시하며, 결과는 UI에 표시됩니다. 기본값은 매일 자정이고, trivyIgnoreUnfixed 은 결과를 수정 버전이 알려진 취약점으로 좁힙니다. Trivy는 버전이 고정된 도구 이미지에 포함되어 배포되므로 스캐너 업데이트를 직접 챙길 필요가 없습니다.

이제 반대편 무게추입니다. 그리고 꽤 큽니다. Portainer 자체의 CE 대 BE 비교 페이지 는 Business Edition이 "3노드까지 영구 무료. 체험 기간 없음. 신용카드 불필요. 기능 제한 없음"이라고 말합니다. 이것이 BE의 전체 구성입니다: 자체 역할 계층을 가진 RBAC, OIDC, Syslog 내보내기가 되는 감사 로그, 고급 GitOps. Take 3 약관 은 3노드 이하를 유지하는 한 매년 무료로 갱신되는 1년 라이선스를 발급합니다.

그러니 무료 등급 계산은 네 번째 노드에서야 Arcane 쪽으로 기웁니다. 그 아래에서는 유료 장벽이 없습니다. 1~2노드에서도 Arcane이 주는 것은 있습니다. 라이선스 키가 없고, 기억해야 할 갱신도 없고, 포크할 수 있는 프로젝트라는 점입니다. 하지만 그것은 "RBAC는 돈이 든다"는 논거와는 다릅니다.

Arcane은 Portainer의 자리를 두고 진지하게 경쟁하는 네 가지 도구 중 하나이며, 나머지는 다른 기준으로 갈립니다.

읽기

Portainer 대안: Dockge, Arcane, Dockhand, Komodo 용도별 가이드

지금 Arcane은 얼마나 안정적인가?

v2.9.0 때 보이던 것보다는 낫지만, 아직 젊습니다. Arcane의 버그 이력은 문제를 고쳐 나가는 활발한 프로젝트처럼 읽히고, v2.8.0과 v2.9.0에서 보고된 심각한 GitOps 디스크 고갈 버그는 2026년 8월 31일 v2.10.0에서 수정되었습니다.

한 운영자가 2026년 8월 26일에 보고한 내용은 GitOps 동기화가 클론 디렉터리를 누수한다: "gitops-<N> 클론 디렉터리가 하루 약 1,000개(~9GB/일)씩 쌓이고 한 번도 정리되지 않아 결국 디스크를 가득 채운다." 6일간 그렇게 쌓인 결과는 약 6,467개 디렉터리, 40GB였습니다. 디스크가 가득 차자 매니저는 SQLite 데이터베이스에 더 이상 쓸 수 없게 되어 재시작 루프에 빠졌고, 재시작 횟수 389회에 이르며 엣지 에이전트 연결과 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은 v2.9.0 이후 일주일도 안 되어 심각한 GitOps 결함을 고쳐야 했습니다. 위험은 새 코드에 있고, 그것을 채택하는 것은 선택입니다.

Portainer에서 전환하는 데 실제로 드는 비용은?

대략 다운타임 창구 하나와 약간의 수동 정리입니다. Arcane에는 여전히 Portainer 스택 직접 가져오기가 없지만, v2.10.0은 실행 중인 컨테이너를 위한 실험적 Convert to Compose 동작을 추가합니다. 원본이 계속 실행되는 동안 Compose 파일을 생성하므로 YAML 재구성 작업 일부가 사라집니다. 그래도 바인드 마운트, 네트워크, 환경 값, 그리고 전환 자체는 검토해야 합니다. 원본을 멈출 때까지 이름과 공개 포트가 충돌할 수 있으므로, 이것은 무중단 마이그레이션 버튼이 아닙니다.

v2.10.0 이전에 프로젝트 자체 게시판은 완전히 수동인 경로를 보여 주었습니다. 서버 5대에 80개가 넘는 컨테이너를 운영하는 한 운영자가 라이브 마이그레이션이 가능한지 물었습니다 . 웹에 노출된 서비스를 먼저 내리지 않고 말입니다. 이미 해 본 사람의 답변은 이랬습니다. "기존 컨테이너(즉 Portainer 스택)를 삭제하고 Arcane에서 처음부터 다시 만드는 것 말고는 선택지가 없을 겁니다." 그 사람의 순서는 깔끔하게 종료, 백업, 삭제, 데이터 복사, 재생성 및 재배포였습니다.

실무적으로는 무엇이든 건드리기 전에 볼륨을 백업하고, 운영 중인 스택 수와 옮겨야 할 데이터 양 모두에 맞춰 유지보수 창구를 잡는 것입니다. 컨테이너 재생성은 보통 빠른 부분이고, 큰 볼륨을 복사하고 종속 서비스를 올바른 순서로 되살리는 일이 창구를 늘릴 수 있습니다. 계획할 때 참고할 용어 메모 하나: Portainer가 스택이라 부르는 것을 Arcane은 프로젝트라 부릅니다.

시간 비용은 홈랩 규모에서도 드러납니다. Moises Aguirre는 2026년 2월 28일 홈랩을 Portainer에서 옮긴 경험에 대해 쓰면서 이를 "꼬박 주말 하나 분량의 작업(그리고 내 악마들과 마주하기)"이라고 불렀습니다. 그 악마들은 자신의 관리 느슨함이었습니다. 운영 중인 모든 컨테이너를 점검하고, 예전에 "그냥 클릭해서 만들어 두었던" 서비스를 위해 YAML을 써야 했습니다. 이것은 규칙이 아니라 그의 경험이지만, 같은 모양은 어디서나 반복됩니다.

Compose 파일을 옮기기 전에 짚어야 할 점이 하나 있습니다. v2.7.0 릴리스 노트 는 변수 해석 출처를 네 가지로 좁혔습니다: .env.global의 전역 변수, 프로젝트 자체의 .env 파일, compose 파일 안에 적힌 기본값, 그리고 Arcane 환경에서 오는 시간대와 로캘입니다. 명시된 효과는 Arcane을 통해 배포된 프로젝트가 프로젝트 디렉터리에서 docker compose up 를 실행할 때와 같은 방식으로 변수를 해석한다는 것입니다. 더 올바른 동작입니다. 다만 매니저 자신의 컨테이너 환경에서 조용히 값을 물려받던 것들은 이제 다른 값이나 빈 값으로 해석되며, 아무 불평 없이 그렇게 된다는 뜻이기도 합니다.

이 중 어느 것도 제품의 결함은 아닙니다. 계획에 넣을 수 있을 만큼 예측 가능한 일회성 비용이며, 마이그레이션에 바라는 핵심이 바로 그것입니다.

프로덕션 전에 무엇을 강화해야 하나?

암호화 키 하나, 공개 URL, 그리고 TLS입니다. Arcane은 첫 실행 시 기본 관리자 계정을 만들고 첫 로그인 시 비밀번호 변경을 강제하는데, 합리적인 기본값입니다. 프로덕션 전에 올바르게 잡아야 할 설정이 두 가지 있습니다. 첫째는 ENCRYPTION_KEY이고, 둘째는 APP_URL.

환경 변수 레퍼런스 에는 아직 ENCRYPTION_KEY 이 기본값 arcane-dev-key-32-characters!!!과 함께 실려 있지만, 설치 문서는 고유한 32바이트 값을 넣으라고 안내합니다. 프로덕션 전에 바꾸세요. 한 가지 더 바뀐 점이 있습니다. 설치 문서는 이제 JWT_SECRET 이 더 이상 사용되지 않는다고 말합니다. Arcane은 세션 서명 키를 스스로 생성하므로, JWT_SECRET 을 설정해 두어도 시작 시 경고만 나옵니다. 환경에서 제거하세요. 설치 문서 는 ENCRYPTION_KEY 이 "32바이트 길이여야 한다(원시 값, base64 또는 16진수)"고 명시합니다.

버전 위생도 그 체크리스트에 들어갑니다. 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은 소켓 프록시 설정 가이드 를 공개하는데, 그 전제는 소켓을 직접 마운트하면 "Arcane에 Docker에 대한 전체 접근 권한을 주게" 되고, 프록시를 두면 필요한 API 호출만으로 좁혀진다는 것입니다. Docker 소켓을 격리할 가치 를 어디서든 만들어 내는 바로 그 노출이며, 여기서도 할 만합니다. 저는 이 문서들을 배포하는 사람의 시각으로 읽고 있지, 토큰 체계를 감사하는 것은 아닙니다.

Arcane이 아직 못 하는 것은?

Arcane의 현행 문서에 비추어 아직 남은 공백은 둘입니다. LDAP이 없고, 컨테이너 자체 파일 시스템을 볼 범용 브라우저가 없습니다. v2 이전에 있던 다른 공백들은 그 뒤로 여럿 메워졌습니다.

LDAP이 없습니다. Arcane의 싱글 사인온 문서 는 OIDC만 다루며, 그 문서에도 접근 제어 페이지에도 LDAP이나 Active Directory 언급은 어디에도 없습니다. Portainer의 Business Edition은 반대로 "Active Directory, LDAP, OIDC 호환 ID 공급자"와 통합됩니다. 조직이 앞단에 OIDC 계층 없이 디렉터리로 인증한다면, 이것은 우회책이 아니라 완전한 막다른 길입니다.

컨테이너 내부의 범용 파일 브라우저가 없습니다. Arcane의 컨테이너 뷰는 구성, 마운트, 로그, Compose 소스를 보여 주지만 컨테이너 자체 파일 시스템 브라우저는 없습니다. 다만 이제 Docker 볼륨 안의 파일을 탐색하고 편집할 수 있는 Volume Workspace가 있어, 남은 공백은 예전의 "파일 브라우저 없음"이라는 설명보다 좁습니다.

이 정정 사항들은 분명히 밝혀 둘 가치가 있습니다. "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에서 3노드를 넘었고, 라이선스 이야기 없이 git으로 추적하는 Compose와 범위가 지정된 다중 사용자 접근을 원한다면 Arcane으로 전환하세요. 3노드 이하라면 그대로 있으세요. 호스트 수를 세는 것이 어떤 기능 목록보다 빠르게 대부분의 답을 줍니다.

Arcane이 분명한 정답인 세 가지 프로필:

• Portainer의 3노드 상한을 넘었고 범위 지정 접근이 필요한 운영자. 3노드를 넘으면 이 기능들은 Portainer에서는 유료이고 Arcane에서는 무료이며, 역할도 한 환경에서는 Deployer, 나머지에서는 Viewer를 줄 수 있을 만큼 세밀합니다.
• Compose 파일을 단일 진실 원천으로 삼고 싶은 운영자. 전환의 동기가 스택 정의가 저장소가 아닌 데이터베이스에 있다는 점이라면, 그것은 취향이 아니라 구조적 적합성입니다. 마이그레이션 주말은 대부분 이미 운영 중인 것을 적어 내려가는 데 쓰이는데, 어차피 빚진 작업입니다.
• NAT 뒤의 호스트를 포함해 여러 호스트를 통합하려는 운영자. 엣지 모드 에이전트는 원격 쪽에 인바운드 포트가 필요 없고, Swarm 클러스터는 매니저 노드에서 관리되며, 원격 환경에는 비용이 들지 않습니다.

그렇지 않은 두 가지 프로필:

• 3노드 이하인 모든 사람. 그 규모에서는 Business Edition이 전체 기능으로 무료이므로, 전환은 이미 가진 기능을 얻기 위해 다운타임과 주말을 쓰는 일이 됩니다. Portainer 대안으로서 Arcane은 유능하지만, 그것이 옮길 이유가 되지는 않습니다.
• LDAP이 필요하거나 스택을 내릴 수 없는 모든 사람. 디렉터리 인증은 제공되지 않고, 마이그레이션에는 여전히 계획된 전환이 필요합니다. 둘 다 영리한 우회책이 없습니다.

이 평가에는 조건이 하나 붙습니다. GitOps 재배포가 전환의 구체적인 이유라면 v2.10.0 이상을 사용하세요. v2.8.0과 v2.9.0에서 보고된 디스크 고갈 버그는 거기서 수정되었습니다.

읽기

VPS에 Docker 설치 방법: 컨테이너화를 위한 VPS 사용 종합 가이드🗂️

자주 묻는 질문

Arcane은 무료인가요?

네. Arcane은 BSD-3-Clause 라이선스의 무료 소프트웨어로, 유료 등급도, 엔터프라이즈 에디션도, 노드 수에 따른 기능 제한도 없습니다. 역할 기반 접근 제어, OIDC 싱글 사인온, 취약점 스캔, 원격 환경, GitOps 재배포가 모두 포함됩니다. 유일한 비용은 실행할 머신뿐입니다.

Arcane에는 RAM이 얼마나 필요한가요?

프로젝트는 최소 사양을 공개하지 않습니다. Arcane 설치 문서에는 RAM이나 CPU 하한이 없고, 지원 하드웨어는 x86 서버부터 Raspberry Pi급 보드까지 이릅니다. 자신의 마이그레이션을 기록한 한 운영자 는 관리 컨테이너가 "약 150MB RAM(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 등급에만 있습니다.