Docker image names after Nexus or Artifactory

A Docker image name starts with the registry that serves it, and Nexus and Artifactory build that start in different ways. Nexus gives a repository its own port or subdomain, or, from version 3.83.0, a path. Artifactory takes the repository from a subdomain, from the path or from a port. On CloudRepo the name has one shape for every repository: the host of your organization, the literal repositories/ segment, the repository, then the image and tag, as Connect Docker shows.

This page maps each form to that name and shows how to find every reference to rename. It changes names. It does not copy images: to copy them, see Migrate from Sonatype Nexus Repository or Migrate from JFrog Artifactory.

Nexus connector ports, subdomains and paths

Sonatype documents four ways to address a Docker repository on Nexus: port connectors, subdomain routing, path-based routing and reverse proxy redirects. The first three are rows here, and each shows a name as you write it now and the same image on CloudRepo:

Form	Name in Nexus	Name on CloudRepo
Connector port (legacy)	nexus.example:18079/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
Subdomain connector (Nexus Repository Pro)	docker.nexus.example/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
Path-based routing (3.83.0 and later)	nexus.example/docker-hosted/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0

In the first two rows the repository is not in the name. Nexus finds it from the port, or from the subdomain name, that you set in that repository’s configuration: see Sonatype’s port connectors and subdomain connector pages. On CloudRepo the repository is in the name, so before you rename, write down each port or subdomain you use, the Nexus repository it serves and the CloudRepo repository you moved that repository’s images to (your-repo above). In the third row the repository is already in the name, as the segment after the host.

If a reverse proxy in front of Nexus maps a host or a port to a repository, your image names carry the proxy’s host or port, and the mapping is in the proxy’s configuration (Sonatype). Read it there to learn which repository each name reaches, then treat the name as one of the rows above.

A name that reached a Nexus group repository maps to the CloudRepo repository you choose to answer it: a hosted repository, or a group repository, which is addressed exactly like a hosted one.

Artifactory subdomains, repository paths and ports

JFrog lists the URL formats of a Docker repository by hosting framework and method. Each row shows a name as you write it now, in JFrog’s own examples, and the same image on CloudRepo:

Form	Name in Artifactory	Name on CloudRepo
Subdomain	docker-local.myartifactory.com/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
Repository path	myartifactory.com/docker-local/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
Port	myartifactory.com:8876/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
Repository path, no reverse proxy	10.1.16.114:8082/docker-local/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
JFrog SaaS, repository path	acme.jfrog.io/docker-local/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0
JFrog SaaS, repository key in the subdomain	acme-docker-local.jfrog.io/my-app:1.0.0	your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0

In the repository-path rows the repository key is the segment after the host, and in the subdomain rows it is part of the host name. In a port row it is not in the name at all: the port is bound to a repository in your reverse proxy’s configuration, as JFrog’s own port example binds docker-virtual to port 5001. In the fourth row, which JFrog shows for Artifactory without a reverse proxy, the port belongs to the host and goes with it. JFrog also lists custom-domain (CNAME) forms of the two SaaS names, acme.com/docker-local and docker-local.acme.com; they change like the rows they stand for.

A name that reached an Artifactory virtual repository maps to the CloudRepo repository you choose to answer it: a hosted repository, or a group repository, which is addressed exactly like a hosted one.

What cloudrepo-migrate keeps

If you move a hosted Docker repository from Nexus 3 with cloudrepo-migrate nexus3, version 0.6.0 or later, each manifest is uploaded as Nexus serves it, so it keeps its digest, and is read back from CloudRepo by digest. The digest of each image does not change; only its name does. For an Artifactory repository, Migrate from JFrog Artifactory says which Docker repositories the tool moves.

Find every reference

A name to rename is a string in a file, and it is also in places no file search reaches. Start from the host names your registries answer to: the Nexus or Artifactory host, each subdomain, and any host name a reverse proxy gives them. The first command lists every line that Git tracks and that names one of them, so run it in each repository you have. The four after it narrow the list to one place each, so you can review them in turn.

Terminal

OLD_HOSTS='nexus\.example|myartifactory\.com|jfrog\.io'
git grep -n -i -E "$OLD_HOSTS"

Write your own host names in OLD_HOSTS: a backslash before each dot, and a | between names. Keep this terminal open for the commands below, which read OLD_HOSTS. Names match without regard to case.

Dockerfile FROM

Lists the FROM lines that name an old host, in every file whose name contains Dockerfile. A base image that a build argument sets is found by the first command, on the ARG line or the CI line that sets it.

Terminal

git grep -n -i -E "^[[:space:]]*FROM[[:space:]].*($OLD_HOSTS)" -- '*Dockerfile*'

Docker Compose image

Lists the image: lines of every Compose file that name an old host.

Terminal

git grep -n -i -E "^[[:space:]]*image:.*($OLD_HOSTS)" -- '*compose*.yml' '*compose*.yaml'

Kubernetes image

Lists the image: lines of the other YAML files that name an old host, in containers and in init containers. A Helm chart’s templates take the image from values, so look in the values next.

Terminal

git grep -n -i -E "^[[:space:]]*(-[[:space:]]+)?image:.*($OLD_HOSTS)" -- '*.yaml' '*.yml' ':!*compose*' ':!*values*'

Helm values

Lists every line of a values file that names an old host, whatever key it sits under.

Terminal

git grep -n -i -E "$OLD_HOSTS" -- '*values*.yaml' '*values*.yml'

Beyond the files

A search finds only what it is pointed at, so the list is as complete as OLD_HOSTS and the repositories you ran it in. Check these places by hand:

• Image pull secrets. A pod pulls with a secret made for the old host. Make one for CloudRepo and point imagePullSecrets at it, as Pull CloudRepo images in Kubernetes shows.
• Settings that live in a tool and not in a file: the variables and pipeline settings of your CI system, and any rule that lets images come only from named registries.
• Running workloads, whose image names are in the cluster and not in a repository.

Then log in and pull

A repository has to exist on CloudRepo for each your-repo you chose: see Creating a repository. Then log in once with a repository token and pull by the new name. Connect Docker shows the login, the push and the pull, and Pull Docker images shows the login in CI.