Arcane Docker review: is het klaar om Portainer te vervangen?

Arcane leverde op 7 juni 2026 volledige rolgebaseerde toegangscontrole uit, in release v2.0.0. Het scant je images ook op bekende kwetsbaarheden, volgens een schema dat je zelf instelt. Geen van beide was waar toen Brandon Lee op 29 december 2025 zijn eerste indrukken van Arcane publiceerde, ruim vijf maanden vóór de RBAC-release.

Die kloof is op dit moment het lastige deel van elke Arcane Docker review. De tool zit al op v2.10.2, uitgebracht op 5 september 2026, minder dan twee weken na v2.9.0. Release v2.10.0 verhielp het hieronder besproken GitOps-clone-lek en voegde een experimentele Convert to Compose-workflow toe voor draaiende containers. Een functielijst die zelfs een paar dagen eerder is geschreven, beschrijft een ander product.

TL;DR

Arcane op v2.10.2 is een werkbare vervanger van Portainer voor de juiste beheerder. Het levert volledige RBAC, OIDC single sign-on, Trivy-kwetsbaarheidsscans en GitOps-herdeployment zonder kosten en zonder node-plafond. Portainer houdt die rolhiërarchie boven drie nodes in de Business Edition. 4 van de 5. Wat het tegenhoudt is de korte staat van dienst, niet het kunnen.

• Stap over zodra je voorbij de derde node van Portainer bent en rollen nodig hebt die afbakenen wie wat mag aanraken. Je krijgt zes ingebouwde rollen, eigen rollen, toewijzing per omgeving en OIDC-groepsclaim-mapping, onbetaald en ongemeten.
• Kwetsbaarheidsscans zitten erin. Arcane draait Trivy, een open-source imagescanner, volgens een cron-schema en bewaart de resultaten per image.
• Portainer Business Edition is gratis tot en met drie nodes, zonder functiebeperkingen. Onder die grens heb je RBAC en SSO al, dus het gratis-toegang-argument van Arcane is daar veel zwakker.
• Er is nog steeds geen directe import van Portainer-stacks. v2.10.0 kan draaiende containers experimenteel omzetten naar Compose-projecten, wat wat handwerk scheelt, maar je moet de gegenereerde YAML nog steeds nakijken en een overschakeling plannen, omdat namen en gepubliceerde poorten kunnen botsen zolang de originelen draaien. Maak eerst back-ups van je volumes.
• Beveilig ENCRYPTION_KEY vóór productie, en stel APP_URL correct in. ENCRYPTION_KEY heeft nog een ontwikkelstandaardwaarde, en inloggen met passkeys werkt pas als APP_URL naar de HTTPS-hostnaam wijst die gebruikers daadwerkelijk bezoeken. JWT_SECRET wordt niet meer gebruikt, volgens de huidige installatiedocumentatie.
• De GitOps-bug met vollopende schijf die tegen v2.8.0 en v2.9.0 is gemeld, is opgelost in v2.10.0. De fix ruimt achtergebleven tijdelijke Git-clone-mappen op in plaats van ze op de manager-host te laten ophopen.
• LDAP ontbreekt nog steeds. Identiteitsintegratie is uitsluitend OIDC.

Hoe deze beoordeling tot stand kwam: dit is een review op basis van bewijs, geen praktijktest. Geen sponsoring, geen betaling, geen geleverd product, geen contact met de maintainer. Elke bewering over functionaliteit is getoetst aan de huidige documentatie en release notes van Arcane, en elke bewering over betrouwbaarheid is terug te voeren op een gedateerde issue in de publieke tracker van het project of op een met naam genoemde beheerder die over zijn eigen deployment schrijft. Niemand hier heeft Arcane gedraaid om dit te schrijven, dus waar dat de lezing beperkt (hoe de interface aanvoelt, hoe hij zich houdt onder aanhoudende belasting) zegt het stuk dat in plaats van te gokken.

Wat geeft Arcane gratis dat Portainer niet geeft?

Eén ding vooral: volledige rolgebaseerde toegangscontrole. Portainer CE geeft je basaal gebruikersbeheer; de rolhiërarchie zit in de Business Edition. Arcane levert die gratis bij elk aantal nodes, naast Trivy-scans, GitOps-herdeployment, Swarm-ondersteuning, inloggen met passkeys, externe agents en de S3-back-ups die in v2.9.0 zijn toegevoegd.

De RBAC is het deel dat je goed moet bekijken, want "heeft RBAC" dekt heel verschillende dingen. De toegangscontroledocumentatie van Arcane beschrijft zes onveranderlijke ingebouwde rollen: Admin, Editor, No-Shell Editor, Deployer, Monitor en Viewer. Je kunt elk ervan klonen naar een eigen rol en individuele rechten aanvinken, die de <resource>:<action> vorm volgen zoals containers:start. Toewijzingen zijn globaal of per omgeving, en een gebruiker kan er meerdere tegelijk hebben. De documentatie geeft het voorbeeld direct: Editor op prod, Viewer op staging.

Wat telt voor een SSO-uitrol is dat de roltoewijzing vanuit de identiteitsprovider zelf kan worden aangestuurd: "Bij elke login leest Arcane de groepsclaim van de gebruiker en synchroniseert zijn uit OIDC afkomstige toewijzingen opnieuw", en een gebruiker in meerdere gemapte groepen krijgt de vereniging daarvan. Dat is het rechtenmodel dat Portainer CE nooit had.

Kwetsbaarheidsscans zijn het tweede onderdeel. De scandocumentatie van Arcane stelt dat "scans opt-in zijn, volgens een cron-schema draaien en dat de resultaten per image worden opgeslagen", waarbij de resultaten in de UI worden getoond. Standaard draaien ze dagelijks om middernacht, trivyIgnoreUnfixed beperkt de resultaten tot kwetsbaarheden met een bekende fix, en Trivy wordt meegeleverd in een tools-image met vastgezette versie, dus scanner-updates zijn niet jouw zorg.

Nu het tegenwicht, en dat is fors. Portainers eigen pagina over CE versus BE zegt dat de Business Edition "voor altijd gratis is tot en met 3 nodes. Geen proefperiode. Geen creditcard. Geen functiebeperkingen." Dat is de volledige BE-set: RBAC met eigen rolhiërarchie, OIDC, auditlogs met Syslog-export, geavanceerde GitOps. De Take 3-voorwaarden geven een licentie van één jaar die jaarlijks kosteloos wordt verlengd zolang je op drie nodes of minder blijft.

De rekensom van de gratis laag valt dus pas vanaf node vier in het voordeel van Arcane uit. Daaronder is er geen betaalmuur. Arcane biedt bij één of twee nodes nog wel iets: geen licentiesleutel, geen verlenging om te onthouden, een project dat je kunt forken. Maar dat is niet hetzelfde argument als "RBAC kost geld".

Arcane is een van de vier tools die serieus meedingen naar de plek van Portainer, en de andere splitsen zich langs andere lijnen.

LEES

Portainer-alternatieven: een use-case-gids voor Dockge, Arcane, Dockhand en Komodo

Hoe betrouwbaar is Arcane op dit moment?

Beter dan het er bij v2.9.0 uitzag, maar nog jong. De bug-historie van Arcane leest als die van een actief project dat dingen oplost, en de ernstige GitOps-bug met vollopende schijf, gemeld tegen v2.8.0 en v2.9.0, is op 31 augustus 2026 opgelost in v2.10.0.

Een beheerder meldde op 26 augustus 2026 dat GitOps-synchronisatie een clone-map laat lekken: "gitops-<N> clone-mappen hopen zich op met ongeveer 1.000 per dag (~9 GB/dag) en worden nooit opgeruimd, tot de schijf vol is." Zes dagen daarvan kwamen neer op ongeveer 6.467 mappen en 40 GB. Toen de schijf vol was, kon de manager niet meer naar zijn SQLite-database schrijven en belandde hij in een herstartlus, met een herstartteller van 389, waarbij ook edge-agent-verbindingen en API-aanroepen uitvielen. De issue is inmiddels gesloten, en v2.10.0 bevat de fix die achtergebleven tijdelijke Git-clone-mappen opruimt.

Zit je nog op v2.8.0 of v2.9.0: upgrade voordat je op frequente GitOps-synchronisatie vertrouwt. De fix voor het clone-lek zit in v2.10.0.

De oudere historie is bemoedigender. Een hang na de update tussen 2.0 en 2.0.1 werd opgelost. Een bug waarbij "Update Projects" elke container raakte op de host in plaats van die van het geselecteerde project, werd gesloten met de gemergede fix-PR #2289. Image-polling die stilletjes niet afging in v1.13.2 werd opgelost in v1.14.0. Drie bugs, drie fixes.

Het ruwe aantal open issues zegt op zichzelf heel weinig bij een project dat in dit tempo uitbrengt. Projecten waar niemand issues tegen indient, zijn daardoor niet betrouwbaarder.

Mijn lezing blijft dat dit een probleem van staat van dienst is, niet van kunnen. Snel uitbrengen is de reden dat de RBAC- en scan-gaten überhaupt zijn gedicht, en ook de reden dat v2.10.0 minder dan een week na v2.9.0 een ernstig GitOps-defect moest oplossen. Nieuwe code is waar het risico zit, en die overnemen is een keuze.

Wat kost overstappen van Portainer eigenlijk?

Een downtime-venster en wat handmatig opruimwerk, grofweg. Arcane heeft nog steeds geen directe import van Portainer-stacks, maar v2.10.0 voegt een experimentele Convert to Compose-actie toe voor draaiende containers. Die genereert een Compose-bestand terwijl de originelen blijven draaien, wat een deel van het YAML-reconstructiewerk wegneemt. Je moet bind mounts, netwerken, omgevingswaarden en de overschakeling zelf nog steeds nakijken; namen en gepubliceerde poorten kunnen botsen tot de originelen zijn gestopt, dus dit is geen migratieknop zonder downtime.

Vóór v2.10.0 weerspiegelde het eigen forum van het project een volledig handmatig pad. Een beheerder met meer dan 80 containers verspreid over vijf servers vroeg of een live migratie mogelijk was zonder eerst de webgerichte diensten uit te zetten. Het antwoord van iemand die het al had gedaan: "je hebt geen andere keuze dan de bestaande containers (en dus de Portainer-stacks) te verwijderen en ze in Arcane vanaf nul opnieuw aan te maken." Zijn volgorde: netjes afsluiten, back-uppen, verwijderen, de data overzetten, opnieuw aanmaken en opnieuw uitrollen.

In de praktijk: volume-back-ups voordat je iets aanraakt, en een onderhoudsvenster dat is afgestemd op zowel het aantal stacks dat je draait als de hoeveelheid data die moet verhuizen. Containers opnieuw aanmaken is meestal het snelle deel; grote volumes kopiëren en afhankelijke diensten in de juiste volgorde terugbrengen kan het venster oprekken. Een terminologienoot voor je planning: wat Portainer een stack noemt, noemt Arcane een project.

De tijdkosten voel je zelfs op homelab-schaal. Moises Aguirre, die op 28 februari 2026 schreef over het verhuizen van een homelab weg van Portainer, noemde het "een stevig weekend werk (en het onder ogen zien van mijn demonen)", en die demonen waren zijn eigen wildgroei: hij moest elke container die hij draaide doorlichten en YAML schrijven voor diensten die hij "eerder gewoon bij elkaar had geklikt". Dat is zijn ervaring en geen regel, maar het patroon is herkenbaar.

Eén ding om op te letten voordat je Compose-bestanden overzet. De release notes van v2.7.0 beperkten de variabele-resolutie tot vier bronnen: je globale variabelen in .env.global, het eigen .env -bestand van het project, standaardwaarden die in het compose-bestand zelf staan, en tijdzone en locale uit de omgeving van Arcane. Het beoogde effect is dat een via Arcane uitgerold project zijn variabelen op dezelfde manier oplost als docker compose up in de projectmap. Dat is correcter gedrag. Het betekent ook dat alles wat stilletjes een waarde erfde uit de containeromgeving van de manager zelf, nu naar iets anders wordt opgelost, of naar niets, en dat zonder te klagen.

Niets hiervan is een gebrek van het product. Het zijn eenmalige kosten, voorspelbaar genoeg om in te plannen, en dat is het belangrijkste wat je van een migratie wilt.

Bouw op een Linux VPS met root-toegang, NVMe en AMD EPYC-kracht.

Bekijk Linux-plannen

Wat moet je beveiligen vóór productie?

Eén encryptiesleutel, de publieke URL en TLS. Arcane maakt bij de eerste start een standaard adminaccount aan en dwingt bij de eerste login een wachtwoordwijziging af, een verstandige standaard. Twee instellingen moeten vóór productie kloppen. De eerste is ENCRYPTION_KEY; de tweede is APP_URL.

De referentie voor omgevingsvariabelen vermeldt nog steeds ENCRYPTION_KEY met als standaardwaarde arcane-dev-key-32-characters!!!, terwijl de installatiedocumentatie je vraagt een unieke waarde van 32 bytes op te geven. Wijzig die vóór productie. Nog iets is veranderd: de installatiedocumentatie zegt nu dat JWT_SECRET niet meer wordt gebruikt. Arcane genereert de sessie-ondertekeningssleutel zelf; als je JWT_SECRET ingesteld laat, geeft dat alleen een waarschuwing bij het opstarten, dus verwijder hem uit de omgeving. De installatiedocumentatie specificeert dat ENCRYPTION_KEY "32 bytes lang moet zijn (raw, base64 of hex)."

Versiehygiëne hoort ook op die lijst. Arcane publiceerde in 2026 meerdere beveiligingsadviezen; één advies met hoge ernst, gepubliceerd op 29 juli 2026, noemt versies vóór v2.5.0 als getroffen en liet een gedelegeerde users:update -permissie het wachtwoord van een beheerder resetten. Het noemt v2.6.0 als de gepatchte release, dus v2.10.0 is niet getroffen, maar het is een concrete reden om een productiedeployment niet op een oude tag te laten staan.

APP_URL staat standaard op http://localhost:3552, en dat heeft een functioneel gevolg dat verder gaat dan hygiëne. Inloggen met passkeys en passkey-MFA draaien allebei op WebAuthn, en de passkey-documentatie van Arcane is expliciet: "Browsers stellen de WebAuthn-API alleen beschikbaar in een beveiligde context, dus passkeys hebben HTTPS nodig (of localhost)." De relying-party-ID wordt afgeleid van APP_URL, passkeys zijn gebonden aan die hostnaam, en als APP_URL geen hostnaam bevat, initialiseert de passkey-service niet. Op kaal HTTP verbergt Arcane de passkey-bediening volledig. Rol uit op een kaal IP-adres met poort en de belangrijkste authenticatiefunctie van v2 is er gewoon niet. De documentatie zegt het duidelijk: "Stel APP_URL in op de URL die je gebruikers daadwerkelijk bezoeken, over HTTPS, voordat iemand een passkey registreert."

Externe agents bepalen wat je moet openzetten. De omgevingsdocumentatie van Arcane zegt dat in directe modus "de Manager verbinding maakt met de Agent op TCP 3553", dus die poort moet inkomend bereikbaar zijn op de externe host. In edge-modus "maakt de Agent uitgaand verbinding met de Manager" en is er helemaal geen inkomende poort nodig.

Daarbuiten wijs ik liever dan dat ik doe alsof. Arcane publiceert een handleiding voor het opzetten van een socket-proxy met als uitgangspunt dat een directe socket-mount "Arcane volledige toegang tot Docker geeft", en dat een proxy dat beperkt tot de API-aanroepen die het nodig heeft. Dezelfde blootstelling die het isoleren van de Docker-socket overal de moeite waard maakt, en ook hier. Ik lees deze documentatie zoals iemand die uitrolt haar leest, zonder het tokenschema te auditen.

Wat doet Arcane nog steeds niet?

Twee gaten houden nog stand tegenover de huidige documentatie van Arcane: geen LDAP en geen algemene browser voor het eigen bestandssysteem van een container. Verschillende andere gaten van vóór v2 zijn sindsdien gedicht.

LDAP ontbreekt. De single sign-on-documentatie van Arcane behandelt OIDC en alleen OIDC, en noch die pagina noch de toegangscontrolepagina noemt LDAP of Active Directory ergens. De Business Edition van Portainerintegreert daarentegen met "Active Directory, LDAP en OIDC-compatibele identiteitsproviders". Als je organisatie authenticeert tegen een directory zonder OIDC-laag ervoor, is dit een harde stop, geen omweg.

Geen algemene bestandsbrowser in containers. De containerweergave van Arcane toont configuratie, mounts, logs en Compose-bron, maar geen browser voor het eigen bestandssysteem van de container. Er is nu wel een Volume Workspace waarmee je bestanden in Docker-volumes kunt bekijken en bewerken, dus het resterende gat is smaller dan de oude omschrijving "geen bestandsbrowser".

Deze correcties verdienen het om expliciet te worden genoemd, want de omschrijving van Arcane als "geen RBAC, geen kwetsbaarheidsscans" gaat niet meer op. RBAC kwam met v2.0.0 op 7 juni 2026, en Trivy-scans zijn gedocumenteerd en draaien volgens schema. Ook de activiteitenregistratie is veranderd: de activiteitendocumentatie van Arcane beschrijft een Activity Center dat pulls, builds, levenscyclusacties, scans en prunes dekt, naast een eventlog met ernst, type, tijdstempel en de gebruiker die elke actie in gang zette, waar Arcane dat kan toewijzen. Of het naar Syslog exporteert zoals de Business-laag van Portainer doet, laat de documentatie in het midden.

Wat de releasesnelheid niet oplost is leeftijd. De Arcane-repository is aangemaakt in april 2025. Portainer heeft jaren aan opgebouwde Stack Overflow-antwoorden, handleidingen van derden en integraties achter zich, en als je om 23.00 uur iets vreemds tegenkomt, voel je dat verschil.

Wie zou naar Arcane moeten overstappen, en wie niet?

Stap over naar Arcane als je op Portainer voorbij drie nodes bent en afgebakende multi-user-toegang wilt met in git bijgehouden Compose, zonder licentiegesprek. Blijf zitten als je op drie nodes of minder zit. Hosts tellen beslecht het grootste deel hiervan sneller dan welke functielijst ook.

Drie profielen waarvoor Arcane een duidelijke ja is:

• Beheerders voorbij het drie-node-plafond van Portainer die afgebakende toegang nodig hebben. Boven drie nodes hebben die mogelijkheden bij Portainer een prijs en bij Arcane geen, en de rollen zijn fijnmazig genoeg om iemand Deployer op één omgeving en Viewer overal elders te geven.
• Beheerders die Compose-bestanden als bron van waarheid willen. Als de drijfveer voor de overstap is dat stackdefinities in een database leven in plaats van in een repo, dan is dat een structurele match, geen voorkeur. Het migratieweekend gaat vooral op aan het opschrijven van wat je al draait, en dat werk was je toch al verschuldigd.
• Beheerders die meerdere hosts samenbrengen, inclusief hosts achter NAT. Agents in edge-modus hebben aan de externe kant geen inkomende poort nodig, Swarm-clusters worden vanaf de manager-node beheerd, en externe omgevingen kosten niets.

Twee profielen waarvoor het dat niet is:

• Iedereen met drie nodes of minder. De Business Edition is op die schaal gratis met de volledige functieset, dus overstappen kost een downtime-venster en een weekend om mogelijkheden te krijgen die je al hebt. Als alternatief voor Portainer is Arcane capabel; dat is nog steeds geen reden om te verhuizen.
• Iedereen die LDAP nodig heeft, of de stacks niet kan uitzetten. Directory-authenticatie is niet beschikbaar en de migratie vereist nog steeds een geplande overschakeling. Geen van beide heeft een slimme omweg.

Eén voorwaarde hoort bij dat oordeel. Als GitOps-herdeployment precies de reden is waarom je overstapt, gebruik dan v2.10.0 of nieuwer. De bug met vollopende schijf die tegen v2.8.0 en v2.9.0 is gemeld, is daar opgelost.

LEES

Docker installeren op VPS: een uitgebreide gids voor het gebruik van VPS voor containerization 🗂️

Veelgestelde vragen