Chapter 6. Mirroring images with Red Hat Quay


With repository mirroring in Red Hat Quay, you can copy images from an external registry into your cluster. You sync by repository or organization name and tag, set intervals, and filter architectures.

From your Red Hat Quay cluster with mirroring enabled, you can perform the following actions:

  • Choose a repository or organization from an external registry to mirror
  • Add credentials to access the external registry
  • Identify specific container image repository or organization names and tags to sync
  • Set intervals at which a repository or organization is synced
  • Check the current state of synchronization
  • Filter the architectures that are mirrored

To use repository mirroring, complete the following actions:

  • Enable mirroring in the Red Hat Quay configuration file
  • Run a mirroring worker
  • Create mirrored repositories

You can configure mirroring by editing the Red Hat Quay configuration file or by using the Red Hat Quay API.

6.1. Mirroring compared to geo-replication

Mirroring and geo-replication solve different distribution needs in Red Hat Quay. Mirroring syncs selected repositories between separate registries; geo-replication shares one database and replicates blob storage across regions.

For example, a geo-replicated Red Hat Quay registry can use two different blob storage endpoints.

The primary use cases for geo-replication include the following:

  • Speeding up access to the binary blobs for geographically dispersed setups
  • Guaranteeing that the image content is the same across regions

Mirroring synchronizes selected repositories, or subsets of repositories, from one registry to another. The registries are distinct, with each registry having a separate database and separate image storage.

The primary use cases for mirroring include the following:

  • Independent registry deployments in different data centers or regions, where a certain subset of the overall content is supposed to be shared across the data centers and regions
  • Automatic synchronization or mirroring of selected (allowlisted) upstream repositories from external registries into a local Red Hat Quay deployment
Note

Mirroring and geo-replication can be used simultaneously.

Table 6.1. Red Hat Quay mirroring and geo-replication comparison
Feature / CapabilityGeo-replicationMirroring

What is the feature designed to do?

A shared, global registry

Distinct, different registries

What happens if replication or mirroring has not been completed yet?

The remote copy is used (slower)

No image is served

Is access to all storage backends in both regions required?

Yes (all Red Hat Quay nodes)

No (distinct storage)

Can users push images from both sites to the same repository or organization?

Yes

No

Is all registry content and configuration identical across all regions (shared database)?

Yes

No

Can users select individual namespaces or repositories to be mirrored?

No

Yes

Can users apply filters to synchronization rules?

No

Yes

Are individual / different role-based access control configurations allowed in each region

No

Yes

6.2. Using mirroring

Repository mirroring in Red Hat Quay syncs images for a repository or organization from an external registry. Filters, robot accounts, and sync intervals control what is copied and when.

The following list shows features and limitations of Red Hat Quay mirroring for a repository or organization.

Note

The word entity is used in the mirroring documentation to refer to either a repository or organization.

  • With mirroring, you can mirror an entire entity or selectively limit which images are synced. Filters can be based on a comma-separated list of tags, a range of tags, or other means of identifying tags through Unix shell-style wildcards.
  • After you set mirroring for an entity, you cannot manually add other images to that entity.
  • Because the mirrored entity is based on the entity and the tags that you set, the entity holds only the content represented by the entity and tag pair. For example, if you change the tag so that some images in the entity no longer match, those images are deleted.
  • Only the designated robot can push images to a mirrored entity, superseding any role-based access control permissions set on the entity.
  • Mirroring can be configured to roll back on failure, or to run on a best-effort basis.
  • With a mirrored entity, a user with read permissions can pull images from the entity but cannot push images to the entity.
  • Changing settings on your mirrored entity can be performed in the Red Hat Quay user interface.
  • Images are synced at set intervals, but can also be synced on demand.
  • In the current implementation of organization-level repository mirroring, Red Hat Quay does not replicate deletions from the source registry. If any of the following entities are removed or absent in the upstream source, they persist in the local Red Hat Quay mirror:

    • Source namespaces or organizations and their repositories. If the entire upstream source namespace (for example, a Harbor project or Red Hat Quay organization) is removed, all previously mirrored repositories and their content remain in the local mirror.
    • Individual repositories. Repositories previously discovered and synced continue to be tracked and served even if removed from the upstream source.
    • Image tags. Tags that existed at the time of the last sync persist in the mirror even if deleted upstream.
    • Referrers. OCI Referrers API artifacts, such as Cosign signatures and SBOMs, are not currently mirrored. When present locally, they are not cleaned up automatically.
  • The downstream mirror acts as a cumulative archive. If an upstream namespace is emptied or its repositories and tags are removed, the mirror continues to serve the last successfully synchronized versions of those objects. This might lead to higher storage consumption in the mirror than in the source.

    Note

    This behavior differs from repository-level mirroring, which automatically removes local tags that are no longer present in the source registry.

    Manual deletion by using the Red Hat Quay UI or API is required to remove these entities from the mirror. A future release can introduce a configurable option to automatically delete absent items, including organizations, repositories, tags, referrers, and manifest list children from the local mirror.

6.3. Creating a mirroring worker

To run repository mirroring in a standalone Red Hat Quay deployment, you can start a Podman container with the repomirror option.

Procedure

  • If you have not configured TLS communications by using a /root/ca.crt certificate, enter the following command to start a mirroring worker:

    $ sudo podman run -d --name mirroring-worker \
      -v $QUAY/config:/conf/stack:Z \
      registry.redhat.io/quay/quay-rhel9:v3.18.0 repomirror
  • If you have configured TLS communications by using a /root/ca.crt certificate, enter the following command to start the repository mirroring worker:

    $ sudo podman run -d --name mirroring-worker \
      -v $QUAY/config:/conf/stack:Z \
      -v /root/ca.crt:/etc/pki/ca-trust/source/anchors/ca.crt:Z \
      registry.redhat.io/quay/quay-rhel9:v3.18.0 repomirror

To enable organization mirroring in Red Hat Quay, you can set FEATURE_ORG_MIRROR to true in your config.yaml file and restart the registry.

Procedure

  1. To enable organization mirroring, set the following configuration fields in your config.yaml file:

    # ...
    FEATURE_PROXY_CACHE: true
    FEATURE_REPO_MIRROR: true
    FEATURE_ORG_MIRROR: true
    ORG_MIRROR_INTERVAL: 60
    ORG_MIRROR_BATCH_SIZE: 100
    ORG_MIRROR_MAX_SYNC_DURATION: 3600
    ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT: 600
    ORG_MIRROR_DISCOVERY_TIMEOUT: 600
    ORG_MIRROR_MAX_REPOS_PER_ORG: 5000
    ORG_MIRROR_MAX_RETRIES: 3
    SSRF_ALLOWED_HOSTS:
        - harbor.example.lab
    # ...

    where:

    FEATURE_PROXY_CACHE
    Specifies whether to enable or disable proxy caching. This field must be set to true to use the organization mirroring feature.
    FEATURE_REPO_MIRROR
    Specifies whether to enable or disable repository-level mirroring. This field must be set to true to use the organization mirroring feature.
    FEATURE_ORG_MIRROR
    Specifies whether to enable or disable organization-level mirroring.
    ORG_MIRROR_INTERVAL
    Specifies the worker processing interval in seconds.
    ORG_MIRROR_BATCH_SIZE
    Specifies the number of organization mirrors to process for each iteration.
    ORG_MIRROR_MAX_SYNC_DURATION
    Specifies the maximum sync duration in seconds.
    ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT
    Specifies the default skopeo timeout in seconds.
    ORG_MIRROR_DISCOVERY_TIMEOUT
    Specifies the discovery timeout in seconds.
    ORG_MIRROR_MAX_REPOS_PER_ORG
    Specifies the maximum repositories to discover for each organization.
    ORG_MIRROR_MAX_RETRIES
    Specifies the maximum sync retries for a failure operation.
    SSRF_ALLOWED_HOSTS
    Specifies the allowed hosts for Server-Side Request Forgery (SSRF) protection. Use this optional field to allow specific hosts to be accessed by the registry.
  2. Restart your Red Hat Quay registry.

To automatically synchronize container images between registries, you can use the Red Hat Quay UI to create a mirroring organization.

Note

Organization-level mirroring cannot be configured on an existing organization that already contains repositories. A dedicated organization must be created specifically to serve as a mirror target, with all repositories within the organization managed exclusively by the mirroring configuration.

Prerequisites

  • You have a Red Hat Quay organization with sufficient permissions.
  • You have created a robot account.
  • You have access to a source Harbor instance.

    • You have Harbor credentials, such as a username and a password or an API token.
  • You have set FEATURE_ORG_MIRROR: true in your config.yaml file.
  • You have set FEATURE_PROXY_CACHE: true in your config.yaml file.
  • You have set FEATURE_REPO_MIRROR: true in your config.yaml file.
  • For standalone Red Hat Quay deployments, you have created a mirroring worker.
  • If you are using an OAuth token to mirror from Quay to Quay, your token must have the following permissions:

    • Administer Repositories
    • View all visible repositories
    • Read/Write to any accessible repositories
    • Administer User

Procedure

  1. On the Red Hat Quay v2 UI, click Organizations in the navigation pane.
  2. Find your organization listed under the Name column and then click the name of the organization.
  3. Click Settings Organization state.
  4. Click the Mirror radio button to set the organization state to mirroring.
  5. Click Submit. Completion of this step takes you to the Mirroring tab.
  6. Under the Source Registry section, complete the following settings:

    • For Source Registry Type, select Quay or Harbor.
    • In the Source Registry URL field, enter a valid URL, for example, https://registry.example.com.
    • For Source Namespace, enter the namespace or project name on the source registry. For example, my-project.
    • Select Private or Public for Repository Visibility.
    • For Start Date, set the date in yyyy-mm-dd format and set the time.
    • Set the Sync interval. Set the integer in the box and select seconds, minutes, hours, days, or weeks from the drop-down menu.
    • Set the Skopeo Timeout value for Skopeo operations.
    • Select a Robot User from the drop-down menu.
    • Set any desired Filter Patterns.
  7. In the Credentials section, do one of the following actions:

    • If you specified Harbor for Source Registry Type, enter your username and password for the source registry.
    • If you specified Quay for Source Registry Type, enter $oauthtoken for the Username field and your OAuth token for the Password field.
  8. Optional: In Advanced Settings, complete any of the following options:

    • For Verify TLS, select the checkbox to verify certificates.
    • Set an HTTP Proxy URL.
    • Set an HTTPS Proxy URL.
    • Set a No Proxy URL.
  9. When you have configured the desired settings, click Enable Organization Mirror.

Verification

  1. On the Red Hat Quay web console, click Organizations the organization name Mirroring.
  2. Scroll to the Status section to view the status and verify the connection.

To create a mirrored organization in Red Hat Quay by using the API, you can send HTTP requests to the organization mirror endpoints with curl and an OAuth bearer token.

Note

Organization-level mirroring cannot be configured on an existing organization that already contains repositories. A dedicated organization must be created specifically to serve as a mirror target, with all repositories within the organization managed exclusively by the mirroring configuration.

Prerequisites

  • You have generated an OAuth access token.

Procedure

  1. Use the POST /api/v1/organization/{orgname}/mirror endpoint to create a new organization-level mirroring configuration:

    $ curl -X POST "https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror" \
      -H "Authorization: Bearer <access_token>" \
      -H "Accept: application/json" \
      -H "Content-Type: application/json" \
      -d '{
        "external_registry_type": "quay",
        "external_registry_url": "https://quay.io",
        "external_namespace": "<external_namespace>",
        "robot_username": "<orgname>+<robot_account>",
        "visibility": "private",
        "sync_interval": 3600,
        "sync_start_date": "2025-01-01T00:00:00Z",
        "is_enabled": true
      }'
  2. Use the GET /api/v1/organization/{orgname}/mirror endpoint to retrieve the organization-level mirroring configuration:

    $ curl -X GET \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror

    Example output

    {"is_enabled": true, "external_registry_type": "quay", "external_registry_url": "http://quay.io", "external_namespace": "test", "external_registry_username": null, "external_registry_config": {}, "repository_filters": [], "robot_username": "example+test", "visibility": "private", "sync_interval": 3600, "sync_start_date": "2025-01-01T00:00:00Z", "sync_expiration_date": null, "sync_status": "NEVER_RUN", "sync_retries_remaining": 3, "skopeo_timeout": 300, "creation_date": "2026-03-09T18:39:21.993431Z"}

  3. Use the GET /api/v1/organization/{orgname}/mirror/repositories endpoint to obtain a list of repositories that are being mirrored in the organization:

    $ curl -X GET \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      "https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/repositories?page=1&limit=100"

    Example output

    {"repositories": [], "page": 1, "limit": 100, "total": 0, "has_next": false}

  4. Use the POST /api/v1/organization/{orgname}/mirror/sync-now endpoint to trigger an immediate sync of all repositories in the organization:

    $ curl -X POST \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/sync-now

    This command does not return output in the CLI.

  5. Use the POST /api/v1/organization/{orgname}/mirror/sync-cancel endpoint to cancel a pending sync of all repositories in the organization:

    $ curl -X POST \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/sync-cancel

    This command does not return output in the CLI.

  6. Use the PUT /api/v1/organization/{orgname}/mirror endpoint to update the organization-level mirroring configuration:

    $ curl -X PUT \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      -H "Content-Type: application/json" \
      -d '{"is_enabled": true, "sync_interval": 7200}' \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror

    Example output

    " "

  7. Use the POST /api/v1/organization/{orgname}/mirror/verify endpoint to verify the connection to the external registry for the organization-level mirroring configuration:

    $ curl -X POST \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/verify

    Example output

    {"success": false, "message": "Unexpected response: 301"}

  8. Use the DELETE /api/v1/organization/{orgname}/mirror endpoint to delete the organization-level mirroring configuration:

    $ curl -X DELETE \
      -H "Authorization: Bearer <bearer_token>" \
      -H "Accept: application/json" \
      https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror

    This command does not return output in the CLI.

To enable repository mirroring in Red Hat Quay, you can set FEATURE_REPO_MIRROR to true in your config.yaml file and restart the registry.

Procedure

  1. To enable mirroring for repositories, set FEATURE_REPO_MIRROR: true in your config.yaml file:

    # ...
    FEATURE_REPO_MIRROR: true
    REPO_MIRROR_INTERVAL: 30
    REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service"
    REPO_MIRROR_TLS_VERIFY: true
    REPO_MIRROR_ROLLBACK: false
    FEATURE_SPARSE_INDEX: true
    REPO_MIRROR_MAX_MANIFEST_LIST_SIZE: 10485760
    REPO_MIRROR_MAX_MANIFEST_ENTRIES: 1000
    # ...

    where:

    FEATURE_REPO_MIRROR
    Specifies whether to enable or disable repository-level mirroring.
    REPO_MIRROR_INTERVAL
    Specifies the worker processing interval in seconds.
    REPO_MIRROR_SERVER_HOSTNAME
    Specifies the hostname of the server hosting the mirrored repository.
    REPO_MIRROR_TLS_VERIFY
    Specifies whether to verify the TLS certificate of the mirrored repository.
    REPO_MIRROR_ROLLBACK
    Specifies whether to roll back the repository if a mirroring operation fails.
    FEATURE_SPARSE_INDEX
    Specifies whether to allow sparse manifest indexes.
    REPO_MIRROR_MAX_MANIFEST_LIST_SIZE
    Specifies the maximum size of the manifest list in bytes.
    REPO_MIRROR_MAX_MANIFEST_ENTRIES
    Specifies the maximum number of manifest entries to process.
  2. Restart your Red Hat Quay registry.

To mirror a repository from an external registry into Red Hat Quay, you can create a private repository and configure mirroring settings in the UI.

When mirroring a repository from an external container registry, you must create a new private repository. Typically, the same name is used as the target repository, for example, quay-rhel9.

Prerequisites

  • You have set FEATURE_REPO_MIRROR: true in your config.yaml file.
  • For standalone Red Hat Quay deployments, you have created a mirroring worker.
  • You have created a robot account.

Procedure

  1. Navigate to the Repositories page of your registry and click the name of a repository, for example, test-mirror.
  2. Click Settings Repository state.
  3. Click Mirror.
  4. Click the Mirroring tab and enter the details for connecting to the external registry, along with the tags, scheduling, and access information.
  5. Enter the details as required in the following fields:

    • Registry Location: The external repository you want to mirror, for example, registry.redhat.io/quay/quay-rhel8.
    • Tags: Enter a comma-separated list of individual tags or tag patterns. You can use Unix shell-style wildcards.
    • Architecture Filter: Select the architectures that you want to mirror. For example, select AMD64 (x86_64) to mirror only the x86_64 architecture. By default, all architectures are mirrored.
    • Start Date: The date on which mirroring begins. By default, the current date and time are used.
    • Sync Interval: Defaults to syncing every 24 hours. You can change that based on hours or days.
    • Skopeo timeout interval: Defaults to 300 seconds (5 minutes). The maximum timeout length is 43200 seconds (12 hours).
    • Robot User: Create a new robot account or choose an existing robot account to do the mirroring.
    • Username: The username for accessing the external registry holding the repository you are mirroring.
    • Password: The password associated with the username. Note that the password cannot include characters that require an escape character (\).
  6. In the Advanced Settings section, you can optionally configure SSL/TLS and proxy with the following options:

    • Verify TLS: Select this option if you want to require HTTPS and to verify certificates when communicating with the target remote registry.
    • Accept Unsigned Images: Selecting this option allows unsigned images to be mirrored.
    • HTTP Proxy: Identify the HTTP proxy server needed to access the remote site, if a proxy server is needed.
    • HTTPS Proxy: Identify the HTTPS proxy server needed to access the remote site, if a proxy server is needed.
    • No Proxy: List of locations that do not require a proxy.
  7. After filling out all information, click Enable Mirror.

6.9. Starting a mirroring synchronization

To start a mirroring sync immediately in Red Hat Quay, you can open the Mirroring tab for your repository or organization and click Sync Now.

Procedure

  1. Navigate to the Mirroring tab of your repository or organization.
  2. Click Sync Now.

Verification

  1. Click the Logs tab to view available logs.
  2. When mirroring is complete, the images appear in the Tags tab.

6.10. Event notifications for mirroring

Red Hat Quay repository mirroring supports three event notifications: Mirror Started, Mirror Success, and Mirror Unsuccessful. You can configure them per repository in the Settings tab and deliver them by email, Slack, the UI, or webhooks.

The events can be configured inside of the Settings tab for each repository, and all existing notification methods such as email, Slack, Quay UI, and webhooks are supported.

6.11. Working with mirrored repositories

After you create a mirrored repository in Red Hat Quay, you can enable or disable mirroring, sync on demand, update credentials, and manage robot account permissions.

Select your mirrored repository from the Repositories page to do any of the following actions:

  • Enable or disable the repository: Select Mirroring in the left column, then toggle the Enabled check box to enable or disable the repository temporarily.
  • Check mirror logs: To make sure the mirrored repository is working properly, you can check the mirror logs. Select Usage Logs in the left column.
  • Sync mirror now: To immediately sync the images in your repository, select Sync Now.
  • Change credentials: To change the username and password, select DELETE from the Credentials line. Then select None and add the username and password needed to log into the external registry when prompted.
  • Cancel mirroring: To stop mirroring, which keeps the current images available but stops new ones from being synced, select CANCEL.
  • Set robot permissions: Red Hat Quay robot accounts are named tokens that hold credentials for accessing external repositories. By assigning credentials to a robot, that robot can be used across multiple mirrored repositories that need to access the same external registry.

    You can assign an existing robot to a repository by navigating to Organizations Robot accounts. On this page, you can view the following information:

    • Check which repositories are assigned to that robot.
    • Assign Read, Write, or Admin privileges to that robot from the PERMISSION field.
  • Change robot credentials: Robots can hold credentials such as Kubernetes secrets, Docker login information, and Podman login information. To change robot credentials, select the Options gear on the robot account line on the Robot Accounts window and choose View Credentials. Add the appropriate credentials for the external repository the robot needs to access.
  • Check and change general settings: Select Settings (gear icon) from the left column on the mirrored repository page. On the resulting page, you can change settings associated with the mirrored repository. In particular, you can change user and robot permissions to specify exactly which users and robots can read from or write to the repository.

6.12. Repository mirroring recommendations

For Red Hat Quay repository mirroring, you can run mirroring pods on any node and size the number of workers to how many repositories you want to sync in parallel.

Best practices for repository mirroring include the following:

  • Repository mirroring pods can run on any node. This means that you can run mirroring on nodes where Red Hat Quay is already running.
  • Repository mirroring is scheduled in the database and runs in batches. As a result, repository workers check each repository mirror configuration and read when the next sync needs to run. More mirror workers means more repositories can be mirrored at the same time. For example, running 10 mirror workers means that a user can run 10 mirroring operations in parallel. If a user only has 2 workers with 10 mirror configurations, only 2 operations can run at once.
  • The optimal number of mirroring pods depends on the following conditions:

    • The total number of repositories to be mirrored
    • The number of images and tags in the repositories and the frequency of changes
    • Parallel batching

      For example, if a user is mirroring a repository that has 100 tags, one worker completes the mirror. Users must consider how many repositories they want to mirror in parallel, and base the number of workers around that.

      Multiple tags in the same repository cannot be mirrored in parallel.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top