Migrate to 2.0
Prepare an Arcane 1.x installation for Arcane 2.0 and upgrade it.
Arcane 2.0 is a breaking release. It replaces the per-user admin flag with role-based access control (RBAC), gives API keys their own permissions, removes several old settings and integrations, and runs as a non-root user. Work through the steps below before you change the image tag on a 1.x installation.
Breaking changes at a glance
- RBAC replaces the legacy user
adminflag. - OIDC admin claims are removed. OIDC group mappings replace them.
- API keys have explicit permission grants.
- Apprise support is removed from the UI, API, CLI, and database.
- Deprecated scheduled prune settings are removed.
gitopsSyncIntervalis removed. Each GitOps sync has its own interval.- Non-URL custom icon values are resolved through the selected icon catalog.
- Legacy remote bootstrap-token pairing is removed.
- Plaintext Edge mTLS CA key migration is removed.
- Official images run as a hardened non-root user by default.
- Some API and CLI features changed or were removed:
- user role create/update payloads
- dashboard action-items endpoint
arcane alerts- public API-key-backed event creation
- cookie-authenticated cross-origin writes
1. Back up your data
Back up everything you’d need to restore Arcane 1.x:
- the Arcane database
- the full
/app/datafolder or named volume - your Compose file and any environment files it loads
- your projects directory
- any Edge mTLS assets (the certificates Edge agents use to authenticate to the Manager), if you use remote environments
If you use SQLite with the default arcane-data volume, stop Arcane before copying the volume so the database doesn’t change during the backup.
2. Plan roles and permissions
During the upgrade, Arcane assigns roles from the old admin flag:
- Legacy admins become global Admins.
- Other users become global Viewers.
After the upgrade, check that at least one global Admin exists and assign any environment-scoped roles you need. If Arcane finds no global Admin at startup, it logs RBAC global admin guard failed and keeps running, so don’t rely on the log alone. The UI and API won’t let you remove the last global Admin assignment.
See Roles for the role catalog.
3. Replace OIDC admin claims
Remove OIDC_ADMIN_CLAIM and OIDC_ADMIN_VALUE (and the oidcAdminClaim and oidcAdminValue settings). Instead, set OIDC_GROUPS_CLAIM to the claim that carries your groups, and map the old admin value to the role_admin role with OIDC_ROLE_MAPPINGS. For example, a 1.x setup with OIDC_ADMIN_CLAIM: groups and OIDC_ADMIN_VALUE: arcane-admins becomes:
services:
arcane:
environment:
OIDC_SCOPES: openid email profile groups
OIDC_GROUPS_CLAIM: groups
OIDC_ROLE_MAPPINGS: >-
[
{"claimValue":"arcane-admins","roleId":"role_admin"}
]4. Review API keys and automation
- Existing API keys are backfilled with a snapshot of their owner’s permissions at upgrade time. Later changes to the owner’s roles don’t update the key.
- Recreate or edit CI/CD keys so they only have the permissions they need.
- API keys created through the API or CLI must include explicit permission grants.
- Update scripts that use removed user role payloads, dashboard action-items,
arcane alerts, public event creation, or Apprise commands. - Scripts that read user roles from
GET /usersmust useroleAssignmentsandisGlobalAdmin; the flatrolesarray is gone. - Use same-origin or trusted-origin browser calls, or Bearer/API-key auth, for state-changing API requests.
API key create and update payloads look like this:
{
"name": "production deploy bot",
"permissions": [
{ "permission": "projects:list", "environmentId": "env-prod" },
{ "permission": "projects:read", "environmentId": "env-prod" },
{ "permission": "projects:deploy", "environmentId": "env-prod" }
]
}Use environment-scoped grants for automation that only touches one Docker environment. Omit environmentId only for permissions that should apply everywhere.
For CI/CD, consider short-lived credentials from Federated Credentials instead of long-lived API keys.
5. Remove deleted settings and integrations
- Move Apprise notifications to a supported provider.
- Stop relying on the removed scheduled prune settings:
dockerPruneMode,scheduledPruneContainers,scheduledPruneImages,scheduledPruneVolumes,scheduledPruneNetworks, andscheduledPruneBuildCache. - Stop relying on the removed OIDC setting
authOidcConfig. - Review the interval on each GitOps sync, since the global
gitopsSyncIntervalsetting is gone.
6. Check custom icons
Absolute http:// and https:// icon URLs keep working. Any other icon value is treated as an icon catalog slug.
In Compose metadata or container labels, use:
x-arcane.icon-lightandx-arcane.icon-darkcom.getarcaneapp.arcane.icon-lightandcom.getarcaneapp.arcane.icon-dark
See Compose Labels.
7. Update remote environments
- Re-pair remote agents that still use bootstrap-token pairing.
- If you use Edge mTLS, upgrade to a current 1.x release first so the generated CA private keys are already encrypted.
8. Update the image and runtime settings
- Change the image to
ghcr.io/getarcaneapp/manager:v2. - Set
APP_URLto the exact URL your browser uses to reach Arcane (scheme, host, and port). Arcane 2.0 blocks cookie-authenticated cross-origin writes, so a missing or mismatchedAPP_URLcauses403 Cross-origin request blockederrors in the UI. Behind a reverse proxy, also configure trusted proxies. - Remove
JWT_SECRET. Arcane signs session tokens with an ML-DSA-87 key that it generates and stores itself, and logs a warning at startup ifJWT_SECRETis still set. - Stop relying on the Arcane container writing files as root. Check that Arcane can write to
/app/data, your projects directory,/builds, and/backups. - Set
PUIDandPGIDonly if bind-mounted host files need a specific host owner. - If you use a Docker socket proxy, keep
DOCKER_HOSTset and make sure the proxy allows the Docker API calls Arcane needs. See Socket Proxy.
For a Compose install, the result usually looks like this:
services:
arcane:
image: ghcr.io/getarcaneapp/manager:v2
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- arcane-data:/app/data
- /opt/docker:/opt/docker
environment:
APP_URL: http://localhost:3552
ENCRYPTION_KEY: your-existing-encryption-key
PROJECTS_DIRECTORY: /opt/docker
PUID: '1000'
PGID: '1000'Keep your existing projects mount. Installation explains how Arcane maps the projects folder between the container and the host.
9. Upgrade
Stop Arcane:
docker compose downTake the backups from step 1 if you haven’t already.
Change the image in your Compose file to
ghcr.io/getarcaneapp/manager:v2.Start Arcane:
docker compose up -dWatch the logs while the database migration runs:
docker compose logs -f arcaneOpen http://localhost:3552 and check that:
- users can sign in
- the UI saves changes without “Cross-origin request blocked” errors (
APP_URLis correct) - at least one user is a global Admin
- non-admin users have the right roles
- OIDC group mappings work, if you use them
- API keys and scripts have the permissions they need
- projects and GitOps sync intervals load correctly
- Activity Center records long-running actions
- notifications use supported providers
- remote environments connect
- Arcane can write to the mounted data, projects, builds, and backup paths
Roll back
Stop Arcane, restore the database and /app/data backup from before the upgrade, then start your previous 1.x image tag. Don’t start a 1.x container against a database that 2.0 has already migrated. To go back between 2.x releases, see Downgrading.