# Docker image names after Nexus or Artifactory

> How a Nexus connector port or subdomain, or an Artifactory subdomain, path or port, becomes a CloudRepo image name, and how to find every reference.

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](/docs/formats/docker.html#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](/docs/migrate/from-nexus.html) or [Migrate from JFrog Artifactory](/docs/migrate/from-jfrog.html).

## 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](https://help.sonatype.com/en/docker-registry.html). 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](https://help.sonatype.com/en/docker-registry.html) and [subdomain connector](https://help.sonatype.com/en/docker-subdomain-connector.html) 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](https://help.sonatype.com/en/docker-repository-reverse-proxy-strategies.html)). 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](/docs/formats/docker.html#group-docker-repositories), which is addressed exactly like a hosted one.

## Artifactory subdomains, repository paths and ports

JFrog lists the [URL formats of a Docker repository](https://docs.jfrog.com/artifactory/docs/additional-docker-information) 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](/docs/formats/docker.html#group-docker-repositories), 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`](/docs/migrate/from-nexus-3.html#docker-images), 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](/docs/migrate/from-artifactory.html) 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**

```bash
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**

```bash
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**

```bash
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**

```bash
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**

```bash
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](/docs/consume/docker.html#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](/docs/manage/repositories.html#creating-a-repository). Then log in once with a repository token and pull by the new name. [Connect Docker](/docs/formats/docker.html#connect-docker) shows the login, the push and the pull, and [Pull Docker images](/docs/consume/docker.html) shows the login in CI.

---

The page: https://www.cloudrepo.io/docs/migrate/docker-image-names.html