Ulasan Arcane Docker: Sudah Siap Menggantikan Portainer?

Arcane merilis kontrol akses berbasis peran secara penuh pada 7 Juni 2026, dalam rilis v2.0.0. Arcane juga memindai image Anda untuk kerentanan yang sudah dikenal sesuai jadwal yang Anda tentukan. Keduanya belum ada ketika Brandon Lee menerbitkan tulisan kesan pertamanya tentang Arcane pada 29 Desember 2025, lebih dari lima bulan sebelum rilis RBAC.

Jarak itulah bagian yang canggung dari setiap ulasan Arcane Docker saat ini. Alat ini sudah berada di v2.10.2, dirilis 5 September 2026, kurang dari dua minggu setelah v2.9.0. Rilis v2.10.0 memperbaiki kebocoran klon GitOps yang dibahas di bawah dan menambahkan alur eksperimental Convert to Compose untuk kontainer yang sedang berjalan. Daftar fitur yang ditulis beberapa hari lebih awal saja sudah menggambarkan produk yang berbeda.

TL;DR

Arcane di v2.10.2 adalah pengganti Portainer yang layak untuk operator yang tepat. Ia menyediakan RBAC penuh, single sign-on OIDC, pemindaian kerentanan Trivy, dan redeploy GitOps tanpa biaya dan tanpa batas jumlah node. Portainer menyimpan hierarki peran itu di Business Edition untuk lebih dari tiga node. 4 dari 5. Yang menahannya adalah usia yang masih muda, bukan kemampuan.

• Beralihlah begitu Anda melewati node ketiga Portainer dan membutuhkan peran yang membatasi siapa boleh menyentuh apa. Anda mendapatkan enam peran bawaan, peran kustom, penetapan per lingkungan, dan pemetaan group claim OIDC, tanpa bayar dan tanpa meteran.
• Pemindaian kerentanan sudah termasuk. Arcane menjalankan Trivy, pemindai image open source, sesuai jadwal cron dan menyimpan hasilnya per image.
• Portainer Business Edition gratis hingga tiga node, tanpa pembatasan fitur. Di bawah garis itu Anda sudah punya RBAC dan SSO, jadi argumen akses gratis Arcane jauh lebih lemah.
• Masih belum ada impor langsung stack Portainer. v2.10.0 dapat secara eksperimental mengubah kontainer yang sedang berjalan menjadi proyek Compose, yang memangkas sebagian kerja manual, tetapi Anda tetap harus meninjau YAML yang dihasilkan dan merencanakan cutover karena nama dan port yang dipublikasikan bisa bertabrakan selama kontainer asli masih berjalan. Cadangkan volume terlebih dahulu.
• Amankan ENCRYPTION_KEY sebelum produksi, dan atur APP_URL dengan benar. ENCRYPTION_KEY masih memiliki nilai default pengembangan, dan login passkey tidak akan berfungsi sampai APP_URL mengarah ke hostname HTTPS yang benar-benar dibuka pengguna. JWT_SECRET sudah tidak digunakan lagi, menurut dokumentasi instalasi saat ini.
• Bug GitOps yang menghabiskan disk, yang dilaporkan pada v2.8.0 dan v2.9.0, sudah diperbaiki di v2.10.0. Perbaikannya membersihkan direktori sementara klon Git yang tertinggal alih-alih membiarkannya menumpuk di host manager.
• LDAP masih belum ada. Integrasi identitas hanya lewat OIDC.

Bagaimana penilaian ini dibuat: ini adalah ulasan berbasis bukti, bukan uji langsung. Tanpa sponsor, tanpa bayaran, tanpa produk yang disediakan, tanpa kontak dengan pengelola. Setiap klaim kemampuan diperiksa terhadap dokumentasi dan catatan rilis Arcane terkini, dan setiap klaim keandalan ditelusuri ke isu bertanggal di pelacak publik proyek atau ke operator bernama yang menulis tentang deployment mereka sendiri. Tidak ada di sini yang menjalankan Arcane untuk menulis ulasan ini, jadi ketika hal itu membatasi pembacaan (bagaimana rasanya antarmuka, bagaimana ia bertahan di bawah beban berkelanjutan), tulisan ini mengatakannya alih-alih menebak.

Apa yang Diberikan Arcane Secara Gratis yang Tidak Diberikan Portainer?

Satu hal, terutama: kontrol akses berbasis peran secara penuh. Portainer CE memberi Anda manajemen pengguna dasar; hierarki perannya ada di Business Edition. Arcane menyediakannya gratis untuk berapa pun jumlah node, bersama pemindaian Trivy, redeploy GitOps, dukungan Swarm, login passkey, agen jarak jauh, dan cadangan S3 yang ditambahkan di v2.9.0.

RBAC adalah bagian yang layak dicermati, karena "punya RBAC" bisa berarti hal-hal yang sangat berbeda. Dokumentasi kontrol akses Arcane menjelaskan enam peran bawaan yang tidak dapat diubah: Admin, Editor, No-Shell Editor, Deployer, Monitor, dan Viewer. Anda dapat mengkloning salah satunya menjadi peran kustom dan mencentang izin satu per satu, yang mengikuti bentuk <resource>:<action> seperti containers:start. Penetapan bersifat global atau per lingkungan, dan seorang pengguna dapat memegang beberapa sekaligus. Dokumentasinya memberi contoh secara langsung: Editor di prod, Viewer di staging.

Bagian yang penting untuk penerapan SSO adalah penetapan peran dapat digerakkan oleh penyedia identitas itu sendiri: "Pada setiap login Arcane membaca group claim pengguna dan menyinkronkan ulang penetapan yang bersumber dari OIDC," dan pengguna dalam beberapa grup yang dipetakan mendapatkan gabungannya. Itulah model izin yang tidak pernah dimiliki Portainer CE.

Pemindaian kerentanan adalah bagian kedua. Dokumentasi pemindaian Arcane menyatakan bahwa "pemindaian bersifat opt-in, berjalan sesuai jadwal cron, dan hasilnya disimpan per image," dengan hasil yang ditampilkan di UI. Defaultnya harian pada tengah malam, trivyIgnoreUnfixed mempersempit hasil ke kerentanan yang sudah punya perbaikan, dan Trivy dikirim dalam image alat dengan versi terkunci, jadi pembaruan pemindai bukan urusan Anda.

Sekarang penyeimbangnya, dan ini besar. Halaman CE versus BE milik Portainer sendiri menyatakan Business Edition "gratis selamanya hingga 3 node. Tanpa masa percobaan. Tanpa kartu kredit. Tanpa pembatasan fitur." Itu adalah paket BE lengkap: RBAC dengan hierarki perannya sendiri, OIDC, log audit dengan ekspor Syslog, GitOps lanjutan. Ketentuan Take 3 menerbitkan lisensi satu tahun yang diperbarui setiap tahun tanpa biaya selama Anda tetap di tiga node atau kurang.

Jadi hitungan tingkat gratis baru mulai menguntungkan Arcane di node keempat. Di bawah itu, tembok bayar tidak ada. Arcane tetap menawarkan sesuatu di satu atau dua node: tanpa kunci lisensi, tanpa perpanjangan yang harus diingat, proyek yang bisa Anda fork. Tapi itu bukan argumen yang sama dengan "RBAC itu berbayar."

Arcane adalah satu dari empat alat yang serius bersaing memperebutkan posisi Portainer, dan yang lain terbagi menurut garis yang berbeda.

BACA

Alternatif Portainer: panduan berbasis kebutuhan untuk Dockge, Arcane, Dockhand, dan Komodo

Seberapa Andal Arcane Saat Ini?

Lebih baik daripada yang terlihat di v2.9.0, tetapi masih muda. Catatan bug Arcane terbaca seperti proyek aktif yang memperbaiki hal-hal, dan bug GitOps parah yang menghabiskan disk, dilaporkan pada v2.8.0 dan v2.9.0, diperbaiki di v2.10.0 pada 31 Agustus 2026.

Seorang operator melaporkan pada 26 Agustus 2026 bahwa sinkronisasi GitOps membocorkan direktori klon: "gitops-<N> direktori klon menumpuk sekitar 1.000 per hari (~9 GB/hari) dan tidak pernah dibersihkan, sampai akhirnya memenuhi disk." Enam hari seperti itu menghasilkan sekitar 6.467 direktori dan 40 GB. Begitu disk penuh, manager tidak lagi bisa menulis ke basis data SQLite-nya dan masuk ke loop restart, mencapai hitungan restart 389 dan ikut menjatuhkan koneksi agen edge serta panggilan API. Isu tersebut kini sudah ditutup, dan v2.10.0 menyertakan perbaikan pembersihan untuk direktori sementara klon Git yang tertinggal.

Jika Anda masih di v2.8.0 atau v2.9.0: tingkatkan sebelum mengandalkan sinkronisasi GitOps yang sering. Perbaikan kebocoran klon hadir di v2.10.0.

Catatan yang lebih lama lebih menggembirakan. Sebuah hang pasca-pembaruan antara 2.0 dan 2.0.1 sudah diselesaikan. Bug di mana "Update Projects" mengenai setiap kontainer di host alih-alih hanya milik proyek yang dipilih ditutup lewat PR perbaikan #2289 yang sudah digabungkan. Polling image yang diam-diam tidak berjalan di v1.13.2 diperbaiki di v1.14.0. Tiga bug, tiga perbaikan.

Jumlah mentah isu yang masih terbuka tidak banyak bicara dengan sendirinya untuk proyek yang merilis secepat ini. Proyek yang tidak pernah dilaporkan siapa pun tidak lantas lebih andal.

Pembacaan saya tetap bahwa ini masalah usia, bukan masalah kemampuan. Rilis yang cepat adalah alasan celah RBAC dan pemindaian bisa tertutup, dan juga alasan v2.10.0 harus memperbaiki cacat GitOps yang parah kurang dari seminggu setelah v2.9.0. Kode baru adalah tempat risikonya, dan mengadopsinya adalah sebuah pilihan.

Berapa Sebenarnya Biaya Berpindah dari Portainer?

Kira-kira sebuah jendela downtime dan sedikit pembersihan manual. Arcane masih belum punya impor langsung stack Portainer, tetapi v2.10.0 menambahkan aksi eksperimental Convert to Compose untuk kontainer yang sedang berjalan. Aksi ini menghasilkan file Compose sementara kontainer asli tetap berjalan, yang menghilangkan sebagian kerja rekonstruksi YAML. Anda tetap harus meninjau bind mount, jaringan, nilai lingkungan, dan cutover itu sendiri; nama dan port yang dipublikasikan bisa bertabrakan sampai kontainer asli dihentikan, jadi ini bukan tombol migrasi tanpa downtime.

Sebelum v2.10.0, forum proyek itu sendiri mencerminkan jalur yang sepenuhnya manual. Seorang operator dengan lebih dari 80 kontainer di lima server bertanya apakah migrasi langsung dimungkinkan tanpa lebih dulu mematikan layanan yang menghadap web. Jawaban dari seseorang yang sudah melakukannya: "Anda tidak punya pilihan selain menghapus kontainer yang ada (dan karenanya stack Portainer) lalu membuatnya ulang dari nol di Arcane." Urutannya: matikan dengan bersih, cadangkan, hapus, salin datanya, buat ulang, dan deploy ulang.

Praktisnya: cadangan volume sebelum menyentuh apa pun, dan jendela pemeliharaan yang ukurannya ditentukan oleh berapa banyak stack yang Anda jalankan sekaligus berapa banyak data yang harus dipindahkan. Membuat ulang kontainer biasanya bagian yang cepat; menyalin volume besar dan menghidupkan kembali layanan yang saling bergantung dalam urutan yang benar bisa memperpanjang jendela itu. Satu catatan istilah saat Anda merencanakan: yang disebut stack oleh Portainer, disebut proyek oleh Arcane.

Biaya waktunya terasa bahkan di skala homelab. Moises Aguirre, yang menulis pada 28 Februari 2026 tentang memindahkan homelab keluar dari Portainer, menyebutnya "satu akhir pekan penuh kerja (dan menghadapi iblis-iblis saya sendiri)," dan iblis itu adalah kekacauannya sendiri: ia harus mengaudit setiap kontainer yang ia jalankan dan menulis YAML untuk layanan yang sebelumnya "cuma diklik sampai jadi." Itu pengalamannya, bukan aturan, tetapi polanya berlaku umum.

Satu hal yang perlu ditangkap sebelum Anda memindahkan file Compose. Catatan rilis v2.7.0 mempersempit resolusi variabel ke empat sumber: variabel global Anda di .env.global, file .env milik proyek itu sendiri, nilai default yang ditulis di dalam file compose, serta zona waktu dan locale dari lingkungan Arcane. Efek yang dinyatakan adalah proyek yang dideploy lewat Arcane meresolusi variabelnya dengan cara yang sama seperti docker compose up di direktori proyek. Itu perilaku yang lebih benar. Itu juga berarti apa pun yang diam-diam mewarisi nilai dari lingkungan kontainer manager sekarang akan diresolusi ke sesuatu yang lain, atau ke kosong, dan melakukannya tanpa mengeluh.

Tidak ada satu pun dari ini yang merupakan cacat produk. Ini biaya satu kali, cukup terprediksi untuk direncanakan, dan itulah hal utama yang Anda inginkan dari sebuah migrasi.

Bangun di VPS Linux dengan akses root, NVMe, dan tenaga AMD EPYC.

Lihat Paket Linux

Apa yang Harus Anda Amankan Sebelum Produksi?

Satu kunci enkripsi, URL publik, dan TLS. Arcane membuat akun admin default saat pertama kali dijalankan dan memaksa penggantian kata sandi saat login pertama, yang merupakan default yang masuk akal. Dua pengaturan harus benar sebelum produksi. Yang pertama adalah ENCRYPTION_KEY; yang kedua adalah APP_URL.

Referensi variabel lingkungan masih mencantumkan ENCRYPTION_KEY dengan nilai default arcane-dev-key-32-characters!!!, sementara dokumentasi instalasi meminta Anda menyediakan nilai unik 32 byte. Ubah sebelum produksi. Satu hal lagi berubah: dokumentasi instalasi kini menyatakan JWT_SECRET sudah tidak digunakan. Arcane menghasilkan sendiri kunci penandatanganan sesinya; membiarkan JWT_SECRET tetap terkonfigurasi hanya menghasilkan peringatan saat startup, jadi hapus dari lingkungan. Dokumentasi instalasi menetapkan bahwa ENCRYPTION_KEY "harus sepanjang 32 byte (mentah, base64, atau hex)."

Kebersihan versi juga masuk daftar itu. Arcane menerbitkan beberapa advisori keamanan pada 2026; satu advisori berkeparahan tinggi, diterbitkan 29 Juli 2026, mencantumkan rilis sebelum v2.5.0 sebagai terdampak dan membiarkan izin users:update yang didelegasikan mereset kata sandi administrator. Advisori itu menyebut v2.6.0 sebagai rilis yang sudah ditambal, jadi v2.10.0 tidak terdampak, tetapi ini alasan konkret untuk tidak membiarkan deployment produksi bertahan di tag lama.

APP_URL secara default bernilai http://localhost:3552, dan yang ini punya konsekuensi fungsional di luar kebersihan. Login passkey dan MFA passkey keduanya berjalan di atas WebAuthn, dan dokumentasi passkey Arcane menyatakan dengan tegas: "Browser hanya mengekspos API WebAuthn dalam konteks aman, jadi passkey membutuhkan HTTPS (atau localhost)." ID relying party diturunkan dari APP_URL, passkey terikat ke hostname itu, dan jika APP_URL tidak memuat hostname, layanan passkey tidak akan diinisialisasi. Di HTTP biasa, Arcane menyembunyikan kontrol passkey sepenuhnya. Deploy di IP polos dengan port, dan fitur autentikasi andalan v2 itu tidak ada. Dokumentasinya menyatakan dengan jelas: "Atur APP_URL ke URL yang benar-benar dibuka pengguna Anda, lewat HTTPS, sebelum siapa pun mendaftarkan passkey."

Agen jarak jauh menentukan apa yang harus Anda buka. Dokumentasi lingkungan Arcane menyatakan bahwa dalam mode langsung "Manager terhubung ke Agent pada TCP 3553," jadi port itu harus dapat dijangkau secara masuk di host jarak jauh. Dalam mode edge "Agent terhubung keluar ke Manager" dan sama sekali tidak membutuhkan port masuk.

Di luar itu saya lebih memilih menunjuk daripada berpura-pura. Arcane menerbitkan panduan penyiapan socket proxy yang premisnya adalah bahwa mount socket langsung "memberi Arcane akses penuh ke Docker," dan proxy mempersempitnya ke panggilan API yang dibutuhkan. Paparan yang sama yang membuat socket Docker layak diisolasi di mana pun, dan layak dilakukan di sini. Saya membaca dokumen-dokumen ini seperti seorang deployer membacanya, bukan mengaudit skema tokennya.

Apa yang Masih Belum Bisa Dilakukan Arcane?

Dua celah masih bertahan terhadap dokumentasi Arcane saat ini: tidak ada LDAP dan tidak ada peramban umum untuk sistem file milik kontainer itu sendiri. Beberapa celah lain yang ada sebelum v2 sudah tertutup sejak itu.

LDAP tidak ada. Dokumentasi single sign-on Arcane membahas OIDC dan hanya OIDC, dan baik dokumentasi itu maupun halaman kontrol akses tidak menyebut LDAP atau Active Directory di mana pun. Business Edition Portainer, sebaliknya, terintegrasi dengan "Active Directory, LDAP, dan penyedia identitas yang kompatibel dengan OIDC." Jika organisasi Anda mengautentikasi ke direktori tanpa lapisan OIDC di depannya, ini penghenti keras, bukan sesuatu yang bisa diakali.

Tidak ada peramban file umum di dalam kontainer. Tampilan kontainer Arcane memperlihatkan konfigurasi, mount, log, dan sumber Compose, tetapi bukan peramban untuk sistem file milik kontainer itu sendiri. Kini ada Volume Workspace yang dapat menjelajah dan mengedit file di dalam volume Docker, jadi celah yang tersisa lebih sempit daripada deskripsi lama "tanpa peramban file."

Koreksi ini layak dinyatakan secara terbuka, karena deskripsi Arcane sebagai "tanpa RBAC, tanpa pemindaian kerentanan" sudah tidak berlaku. RBAC hadir bersama v2.0.0 pada 7 Juni 2026, dan pemindaian Trivy terdokumentasi dan berjalan sesuai jadwal. Pencatatan aktivitas juga sudah bergerak: dokumentasi aktivitas Arcane menjelaskan Activity Center yang mencakup pull, build, aksi siklus hidup, pemindaian, dan prune, bersama log peristiwa yang memuat keparahan, jenis, stempel waktu, dan pengguna yang memicu setiap aksi bila Arcane dapat mengatribusikannya. Apakah ia mengekspor ke Syslog seperti tingkat Business Portainer, dokumentasinya tidak memberi kepastian.

Yang tidak bisa diperbaiki oleh kecepatan rilis adalah usia. Repositori Arcane dibuat pada April 2025. Portainer punya bertahun-tahun jawaban Stack Overflow, panduan pihak ketiga, dan integrasi yang terakumulasi di belakangnya, dan ketika Anda menemukan sesuatu yang aneh pada pukul 11 malam, perbedaan itulah yang Anda rasakan.

Siapa yang Sebaiknya Beralih ke Arcane, dan Siapa yang Tidak?

Beralihlah ke Arcane jika Anda sudah melewati tiga node di Portainer dan menginginkan akses multi-pengguna yang terbatas cakupannya dengan Compose yang dilacak git, tanpa perbincangan lisensi. Tetaplah di tempat jika Anda berada di tiga node atau kurang. Menghitung host menyelesaikan sebagian besar pertanyaan ini lebih cepat daripada daftar fitur mana pun.

Tiga profil di mana Arcane adalah ya yang jelas:

• Operator yang melewati batas tiga node Portainer dan membutuhkan akses terbatas cakupannya. Di atas tiga node, kemampuan itu berbayar di Portainer dan gratis di Arcane, dan perannya cukup rinci untuk memberi seseorang Deployer di satu lingkungan dan Viewer di semua lingkungan lain.
• Operator yang menginginkan file Compose sebagai sumber kebenaran. Jika yang mendorong perpindahan adalah definisi stack yang hidup di basis data alih-alih di repo, itu kecocokan struktural, bukan preferensi. Akhir pekan migrasi sebagian besar dihabiskan untuk menuliskan apa yang sudah Anda jalankan, pekerjaan yang memang sudah Anda tunggak.
• Operator yang mengonsolidasikan banyak host, termasuk yang berada di balik NAT. Agen mode edge tidak membutuhkan port masuk di sisi jarak jauh, klaster Swarm dikelola dari node manager, dan lingkungan jarak jauh tidak berbiaya apa pun.

Dua profil di mana Arcane bukan pilihan:

• Siapa pun dengan tiga node atau kurang. Business Edition gratis pada ukuran itu dengan set fitur lengkap, jadi beralih berarti menghabiskan jendela downtime dan satu akhir pekan untuk memperoleh kemampuan yang sudah Anda miliki. Sebagai alternatif Portainer, Arcane memang mampu; itu tetap bukan alasan untuk pindah.
• Siapa pun yang membutuhkan LDAP, atau yang tidak bisa mematikan stack. Autentikasi direktori tidak tersedia dan migrasinya masih membutuhkan cutover terencana. Keduanya tidak punya jalan pintas yang cerdik.

Satu syarat menyertai putusan itu. Jika redeploy GitOps adalah alasan spesifik Anda pindah, gunakan v2.10.0 atau yang lebih baru. Bug yang menghabiskan disk, yang dilaporkan pada v2.8.0 dan v2.9.0, sudah diperbaiki di sana.

BACA

Cara Mendapatkan Docker di VPS: Panduan Komprehensif untuk Menggunakan VPS untuk Containerization🗂️

Pertanyaan yang Sering Diajukan