JFrog’s API Key page says “It is not recommended to use API Key- this feature has reached End of Life” (API Key page, read 2026-10-23). If a CI job of yours signs in to Artifactory with a key, this article is for you. It changes that credential once, for every job, onto CloudRepo.
Every JFrog fact below is a quote from a JFrog page, linked, with the date we read it. Where JFrog’s two pages read differently, we print both and decide nothing between them.
Gone, or switched off by an admin?
JFrog’s API Key page says “As notified in Artifactory 7.47.10, API key has reached End of Life at the end of Q4, 2024” (API Key page, read 2026-10-23). The same page says “As of Artifactory version 7.98.x, Artifactory no longer supports creating new API Keys” (API Key page, read 2026-10-23). JFrog’s deprecations page lists “Creation of new API keys” under “Artifactory 7.98” and says “Creation of new API keys has now been disabled” (JFrog Platform Deprecations, read 2026-10-23).
For Cloud customers, the API Key page says “Starting from Artifactory version 7.107.1, you are able to use a checkbox to control the API Usage Deprecation through the JFrog platform WebUI” and “This checkbox will be deselected by default” (API Key page, read 2026-10-23). To block key use there, it says to “select the Disable API Key Usage checkbox under Security > General” (API Key page, read 2026-10-23). For self-hosted servers it says “As of Artifactory version 7.84.x, self-hosted customers can control the creation and usage of API Keys in their environments” (API Key page, read 2026-10-23).
The deprecations page reads differently: “The usage of API Keys will be disabled at the end of Q4 2024” (JFrog Platform Deprecations, read 2026-10-23). Check your own server’s setting before you rely on either page.
On how keys are held, the API Key page says “since API Keys are not created with an expiry date, and, by default, never expire” (API Key page, read 2026-10-23). It also says “A single user can have a single active API Key at any moment, which means a single key needs to be shared with multiple clients” and “If it is revoked, it is revoked for all clients” (API Key page, read 2026-10-23).
JFrog’s deprecations page says “Configure identity tokens instead, which replace API keys and offer enhanced security” (JFrog Platform Deprecations, read 2026-10-23). The API Key page says “The recommended API authentication method is using reference tokens and identity tokens” (API Key page, read 2026-10-23). Either way, moving off a key means a new credential for each job that holds one.
To find what still uses keys, the API Key page says “Artifactory version 7.63.5 and later includes the ability to collect the information of the users that access the system with an API key” (API Key page, read 2026-10-23). For a self-hosted server it says “Artifactory version 7.47.10 includes the ability to collect information regarding how your users are logging in to the system” (API Key page, read 2026-10-23).
Re-key once, with one repository token per job
A repository token is the credential your build tools send to CloudRepo. The page shows how to authenticate Maven, Gradle, npm, pip, twine and docker login with one. Every repository token:
- reaches only the repositories you tick when you create it;
- is Read only (download) or Read + write (download, publish and delete);
- expires when you choose: 90, 180 or 365 days after you create it, on any date up to 31 December 9999, or never (the default is 90 days);
- can be revoked on its own, without changing your password or your other tokens.
The choice of repositories is permanent: to reach different repositories later, create a new token. So create the CloudRepo repositories a job needs first, then give each job its own token, scoped to the repositories it reads or publishes. For a token a CI job holds, choose a date and rotate the token before it, and keep the token in the CI system’s secret store.
Change what the job runs
A job that publishes through the JFrog CLI or an Artifactory build plugin keeps working after your move to CloudRepo once each of those steps is a plain command. Move your CI off the JFrog CLI and Nexus staging shows, for each tool, the step you have now, read from the vendor’s own documentation and linked beside it, and the plain command that replaces it.
Move the files once
Re-keying the jobs does not copy a file. cloudrepo-migrate artifactory copies an Artifactory server’s local Maven repositories into CloudRepo. What this section says about it is the README’s for version 0.7.0, the version on pypi.org (read 2026-10-23).
Create each target repository in CloudRepo first, with the same name as the Artifactory repository or mapped with --repo SOURCE=TARGET, and a repository token that can write them. Use an Artifactory access token with read access to the local repositories you move. The README says to prefer an access token to a legacy key in ARTIFACTORY_API_KEY.
pipx install cloudrepo-migrate
# Paste each token when asked; neither is shown on screen or typed on a command lineread -rs -p "Artifactory access token: " ARTIFACTORY_ACCESS_TOKEN && echoexport ARTIFACTORY_ACCESS_TOKENread -rs -p "CloudRepo repository token: " CLOUDREPO_TOKEN && echoexport CLOUDREPO_TOKEN
# A dry run lists what would move and uploads nothingcloudrepo-migrate artifactory \ --artifactory-url https://artifactory.example.com/artifactory \ --org your-org \ --repo libs-release \ --dry-runThe tool reads both tokens from your environment: set them in your shell, never on the command line. A dry run lists what would move, uploads nothing, and checks the token and targets when CLOUDREPO_TOKEN is set. Then do the real run, the same command without --dry-run:
cloudrepo-migrate artifactory \ --artifactory-url https://artifactory.example.com/artifactory \ --org your-org \ --repo libs-release \ --report-json report.jsonName each Maven repository with --repo: that is the move this article claims. Without --dry-run, cloudrepo-migrate artifactory moves an Artifactory server’s local Maven repositories: every file of each, POMs, maven-metadata.xml and checksum files included.
Before upload, each file’s bytes are compared with the checksum Artifactory recorded for it, and a file that differs is not uploaded. After upload, each file is read back from CloudRepo and its sha1 and sha256 are compared with the source’s bytes. Any mismatch fails the run and names the file. Artifactory is only read, never written.
It skips, with a reason, proxy and remote repositories (create a CloudRepo proxy instead), virtual and federated repositories, and files the server generates itself. An Artifactory repository’s root archetype-catalog.xml is not moved either (this version moves no archetype catalog), and the report names it on that repository’s line. To resume after a failure, run the same command again: a file CloudRepo already holds with the same bytes is counted as already present and not uploaded again.
For Artifactory, the README says npm is tested against a stand-in for Artifactory’s npm API, not yet against a real Artifactory server. This article claims one Artifactory move, local Maven repositories, and no other. The manual steps for the files it does not move are in the Migrate from JFrog Artifactory guide, and the Artifactory migration guide has the steps and every option.
Do it once
If you are going to change what every job holds, change it once: one repository token for each job, scoped to the repositories it needs, with an expiry you choose; the publish steps on plain commands; and the files with a command you can dry-run first. See the plans: each self-serve plan starts with a 14-day free trial.
Every JFrog page this article quotes was read on 2026-10-23. Vendors change their pages, so check each one before you decide.