About Quay IO

Quay.io is a hosted container registry service that stores, builds, and distributes container images and other artifacts. This guide describes how to manage organizations, teams, repositories, and robot accounts in Quay.io.

Quay.io overview

Quay.io is a hosted registry service for storing, building, and distributing container images and other artifacts. It provides access controls, automated vulnerability scanning, and CI/CD integration for managing your container workflows.

Quay.io offers both free and paid tiers to cater to various user needs, and is primarily hosted in the United States (us-east-1 region of Amazon Web Services) with CDN edge servers scattered throughout the world.

Quay.io is flexible, easy to use, and allows users to upload and manage container images. Developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization. Additionally, users can set up access controls and manage team collaboration, enabling seamless sharing of container images among designated team members.

Quay.io addresses container security concerns through its integrated image scanner, Clair. The service automatically scans container images for known vulnerabilities and security issues, providing developers with valuable insights into potential risks and suggesting remediation steps.

Quay.io excels in automation and supports integration with popular Continuous Integration/Continuous Deployment (CI/CD) tools and platforms, enabling seamless automation of the container build and deployment processes. As a result, developers can streamline their workflows, significantly reducing manual intervention and improving overall development efficiency.

Quay.io caters to the needs of both large and small-scale deployments. The platform can handle significant container image traffic and offers efficient replication and distribution mechanisms to deliver container images to various geographical locations.

With Quay.io, developers can discover a collection of pre-built, public container images shared by other users, making it easier to find useful tools, applications, and services for their projects.

Additional resources

Clair

Quay.io support

Quay.io provides technical support for managing container images and for platform availability. You can use Red Hat support resources to resolve functional issues and service incidents.

The Red Hat Knowledgebase contains valuable content to maximize the potential of Red Hat’s products and technologies. Users can find articles, product documentation, and videos that outline best practices for installing, configuring, and utilizing Red Hat products. It also serves as a hub for solutions to known issues, providing concise root cause descriptions and remedial steps.

For incidents related to service disruptions or performance issues not listed on the Quay.io status page, which includes availability and functionality concerns, paying customers can raise a technical support ticket using the Red Hat Customer Portal. A service incident is defined as an unplanned interruption of service or reduction in service quality, affecting multiple users of the platform.

Additional resources

Quay.io user interface overview

The Quay.io user interface provides access to repositories, organizations, and account settings. You can use the UI to manage images, teams, and related registry features.

The following topics cover the layout, navigation, and key features of the Quay.io UI:

Exploring applications and repositories
Using the Quay.io tutorial
Pricing and Quay.io plans
Signing in and using Quay.io features

Quay.io landing page

The Quay.io landing page is the entry point to the hosted container registry. You can use it to explore content, review pricing, sign in, and check maintenance status.

The landing page of Quay.io includes links to the following resources:

Explore. On this page, you can search the Quay.io database for various applications and repositories.
Tutorial. On this page, you can take a step-by-step walkthrough that shows you how to use Quay.io.
Pricing. On this page, you can learn about the various pricing tiers offered for Quay.io. There are also various FAQs addressed on this page.
Sign in. By clicking this link, you are re-directed to sign into your Quay.io repository.

Quay.io header .

The landing page also includes information about scheduled maintenance. During scheduled maintenance, Quay.io is operational in read-only mode, and pulls function as normal. Pushes and builds are non-operational during scheduled maintenance. You can subscribe to updates regarding Quay.io maintenance by navigating to the Quay.io Status page and clicking Subscribe To Updates.

The landing page also includes links to the following resources:

Documentation. This page provides documentation for using Quay.io.
Terms. This page provides legal information about Red Hat Online Services.
Privacy. This page provides information about Red Hat’s Privacy Statement.
Security. This page provides information about Quay.io security, including SSL/TLS, encryption, passwords, access controls, firewalls, and data resilience.
About. This page includes information about packages and projects used and a brief history of the product.
Contact. This page includes information about support and contacting the Red Hat Support Team.
All Systems Operational. This page includes information the status of Quay.io and a brief history of maintenance.
Cookies. By clicking this link, a popup box appears that allows you to set your cookie preferences.

Quay.io footer .

You can also find information about trying Project Quay on premise or trying Project Quay on the cloud, which redirects you to the Pricing page. Each option offers a free trial.

Additional resources

Creating a Quay.io account

New Quay.io users need both a Red Hat account and a Quay.io username. You use the Quay.io account for image storage and the Red Hat account for UI and catalog access.

New users of Quay.io are required to both register for a Red Hat account and create a Quay.io username. These accounts are correlated, with two distinct differences:

The Quay.io account can be used to push and pull container images or Open Container Initiative images to Quay.io to store images.
The Red Hat account provides users access to the Quay.io user interface. For paying customers, this account can also be used to access images from the Red Hat Ecosystem Catalog, which can be pushed to their Quay.io repository.

Users must first register for a Red Hat account, and then create a Quay.io account. Users need both accounts to properly use all features of Quay.io.

Additional resources

Red Hat Ecosystem Catalog

Registering for a Red Hat Account

To use Quay.io, you can register for a Red Hat account on the Red Hat Customer Portal. You create login credentials and provide the required contact information.

Use the following procedure to register for a Red Hat account for Quay.io.

Procedure

Navigate to the Red Hat Customer Portal.
In navigation pane, click Log In.
When navigated to the log in page, click Register for a Red Hat Account.
Enter a Red Hat login ID.
Enter a password.
Enter the following personal information:
- First name
- Last name
- Email address
- Phone number
Enter the following contact information that is relative to your country or region. For example:
- Country/region
- Address
- Postal code
- City
- County
Select and agree to Red Hat’s terms and conditions.
Click Create my account.
Navigate to Quay.io and log in.

Additional resources

Red Hat Customer Portal

Creating a Quay.io user account

To start using Quay.io, you can create a user account after you register with Red Hat. You confirm a unique username that becomes your registry namespace.

Use the following procedure to create a Quay.io user account.

Prerequisites

You have created a Red Hat account.

Procedure

If required, resolve the captcha by clicking I am not a robot and confirming. You are redirected to a Confirm Username page.
On the Confirm Username page, enter a username. By default, a username is generated. If the same username already exists, a number is added at the end to make it unique. This username is be used as a namespace in the Quay Container Registry.
After deciding on a username, click Confirm Username. You are redirected to the Quay.io Repositories page, which serves as a dedicated hub where users can access and manage their repositories with ease. From this page, users can efficiently organize, navigate, and interact with their container images and related resources.

Quay.io Single Sign On support

To link legacy Quay.io credentials with Red Hat Single Sign-On, you can attach your account from the Recovery page. Most accounts are already linked.

Red Hat Single Sign On (SSO) can be used with Quay.io. Use the following procedure to set up Red Hat SSO with Quay.io. For most users, these accounts are already linked. However, for some legacy Quay.io users, this procedure might be required.

Prerequisites

You have created a Quay.io account.

Procedure

Navigate to the Quay.io Recovery page.
Enter your username and password, then click Sign in to Quay Container Registry.
In the navigation pane, click your username → Account Settings.
In the navigation pane, click External Logins and Applications.
Click Attach to Red Hat.
If you are already signed into Red Hat SSO, your account is automatically linked. Otherwise, you are prompted to sign into Red Hat SSO by entering your Red Hat login or email, and the password. Alternatively, you might need to create a new account first.

After signing into Red Hat SSO, you can choose to authenticate against Quay.io using your Red Hat account from the login page.

Additional resources

Exploring Quay.io

The Quay.io Explore page helps you discover container images, applications, and repositories from the community. You can search shared content across the registry.

The Quay.io Explore page is a valuable hub that allows users to delve into a vast collection of container images, applications, and repositories shared by the Quay.io community. With its intuitive and user-friendly design, the Explore page offers a powerful search function, enabling users to effortlessly discover containerized applications and resources.

Additional resources

Quay.io Explore page

Trying Quay.io (deprecated)

The Quay.io tutorial walks through basic registry tasks such as login, builds, and permissions. This tutorial is deprecated and scheduled for removal when the v2 UI is generally available.

Note	The Project Quay tutorial is currently deprecated and will be removed when the v2 UI goes generally available (GA).

The Quay.io Tutorial page offers users and introduction to the Quay.io container registry service. By clicking Continue Tutorial users learn how to perform the following features on Quay.io:

Logging into Quay Container Registry from the Docker CLI
Starting a container
Creating images from a container
Pushing a repository to Quay Container Registry
Viewing a repository
Setting up build triggers
Changing a repository’s permissions

Additional resources

Quay.io Tutorial page

Information about Quay.io pricing

To choose a Quay.io plan, you can review tiers and benefits on the Pricing page. You can subscribe through Stripe with a valid credit card.

In addition to a free tier, Quay.io also offers several paid plans that have enhanced benefits.

The Quay.io Pricing page offers information about Quay.io plans and the associated prices of each plan. The cost of each tier can be found on the Pricing page. All Quay.io plans include the following benefits:

Continuous integration
Public repositories
Robot accounts
Teams
SSL/TLS encryption
Logging and auditing
Invoice history

Quay.io subscriptions are handled by the Stripe payment processing platform. A valid credit card is required to sign up for Quay.io.

To sign up for Quay.io, use the following procedure.

Procedure

Navigate to the Quay.io Pricing page.
Decide on a plan, for example, Small, and click Buy Now. You are redirected to the Create New Organization page. Enter the following information:
- Organization Name
- Organization Email
- Optional. You can select a different plan if you want a plan larger, than, for example, Small.
Resolve that captcha, and select Create Organization.
You are redirected to Stripe. Enter the following information:
- Card information, including MM/YY and the CVC
- Name on card
- Country or region
- ZIP (if applicable)
- Check the box if you want your information to be saved.
- Phone Number
Click Subscribe after all boxes have been filled.

Additional resources

Project Quay tenancy model

The Project Quay tenancy model defines how users, organizations, and repositories relate. You can use this model to organize access and ownership in the registry.

Tenancy model

The tenancy model describes users, organizations, teams, and robot accounts in Project Quay. You can use these entities to control repository access and collaboration.

Tenancy model

Organizations provide a way of sharing repositories under a common namespace that does not belong to a single user. Instead, these repositories belong to several users in a shared setting, such as a company.
Teams provide a way for an Organization to delegate permissions. Permissions can be set at the global level (for example, across all repositories), or on specific repositories. They can also be set for specific sets, or groups, of users.
Users can log in to a registry through the web UI or a by using a client like Podman and using their respective login commands, for example, $ podman login. Each user automatically gets a user namespace, for example, <quay-server.example.com>/<user>/<username>, or quay.io/<username> if you are using Quay.io.
Robot accounts provide automated access to repositories for non-human users like pipeline tools. Robot accounts are similar to OpenShift Container Platform Service Accounts. Permissions can be granted to a robot account in a repository by adding that account like you would another user or team.

Logging into Quay

A Quay.io user account authenticates access to repositories and related features. You can sign in through Quay.io or through the Red Hat Hybrid Cloud Console.

A user account for Quay.io represents an individual with authenticated access to the platform’s features and functionalities. Through this account, you gain the capability to create and manage repositories, upload and retrieve container images, and control access permissions for these resources. This account is pivotal for organizing and overseeing your container image management within Quay.io.

Note	Not all features on Quay.io require that users be logged in. For example, you can anonymously pull an image from Quay.io without being logged in, so long as the image you are pulling comes from a public repository.

Users have two options for logging into Quay.io:

By logging in through Quay.io.

This option provides users with the legacy UI, as well as an option to use the beta UI environment, which adheres to PatternFly UI principles.
By logging in through the Red Hat Hybrid Cloud Console.

This option uses Red Hat SSO for authentication, and is a public managed service offering by Red Hat. This option always requires users to login. Like other managed services, Quay on the Red Hat Hybrid Cloud Console enhances the user experience by adhering to PatternFly UI principles.

Differences between using Quay.io directly and Quay on the Red Hat Hybrid Cloud Console are negligible, including for users on the free tier. Whether you are using Quay.io directly, on the Hybrid Cloud Console, features that require login, such as pushing to a repository, use your Quay.io username specifications.

Additional resources

Logging into Quay.io

To sign in to Quay.io, you can use the Quay.io UI with your Red Hat credentials. On first login, you confirm the generated username.

Prerequisites

You have created a Red Hat account and a Quay.io account. For more information, see "Creating a Quay.io account".

Procedure

Navigate to Quay.io.
In the navigation pane, select Sign In and log in using your Red Hat credentials.
If it is your first time logging in, you must confirm the automatically-generated username. Click Confirm Username to log in.

You are redirected to the Quay.io repository landing page.

Logging into Quay through the Hybrid Cloud Console

To sign in to Quay on the Red Hat Hybrid Cloud Console, you can use your Red Hat account. You are redirected to the Quay repository landing page after authentication.

Prerequisites

You have created a Red Hat account and a Quay.io account. For more information, see "Creating a Quay.io account".

Procedure

Navigate to Quay on the Red Hat Hybrid Cloud Console and log in using your Red Hat account. You are redirected to the Quay repository landing page:

Additional resources

Quay on the Red Hat Hybrid Cloud Console

Organizations overview

Organizations in Quay group users, repositories, and teams under a shared namespace for centralized access control. Administrators can assign roles and permissions to teams and users within an organization.

Other useful information about organizations includes the following:

You cannot have an organization embedded within another organization. To subdivide an organization, you use teams.

Organizations cannot contain users directly. You must first add a team, and then add one or more users to each team.

Note

Individual users can be added to specific repositories inside of an organization. Consequently, those users are not members of any team on the Repository Settings page. The Collaborators View on the Teams and Memberships page shows users who have direct access to specific repositories within the organization without needing to be part of that organization specifically.

Teams can be set up in organizations as just members who use the repositories and associated images, or as administrators with special privileges for managing the Organization.

Users can create their own organization to share repositories of container images. This can be done through the Quay.io UI.

Creating an organization by using the UI

To create an organization in Quay, you can use the UI. You set an organization name and then manage repositories and teams under that namespace.

Use the following procedure to create a new organization by using the UI.

Procedure

Log in to your Project Quay registry.
Click Organization in the navigation pane.
Click Create Organization.
Enter an Organization Name, for example, testorg.
Enter an Organization Email.
Click Create.

Now, your example organization should populate under the Organizations page.

Organization settings

To manage organization settings in Quay, you can use the v2 UI. You can update organization details and related configuration options.

With Quay, some basic organization settings can be adjusted by using the UI. This includes adjusting general settings, such as the e-mail address associated with the organization, and time machine settings, which allows administrators to adjust when a tag is garbage collected after it is permanently deleted.

Use the following procedure to alter your organization settings by using the v2 UI.

Procedure

On the v2 UI, click Organizations.
Click the name of the organization that you will create the robot account for, for example, test-org.
Click the Settings tab.
Optional. Enter the email address associated with the organization.
Optional. Set the allotted time for the Time Machine feature to one of the following:
- A few seconds
- A day
- 7 days
- 14 days
- A month
Click Save.

Project Quay repository overview

A repository provides a central location for storing a related set of container images that share a namespace in Quay. You can group repositories under namespaces for individual users, teams, or organizations.

For example, you might have a namespace for your personal projects, one for your company, or one for a specific team within your organization.

With a paid plan, Quay.io provides users with access controls for their repositories. Users can make a repository public, meaning that anyone can pull, or download, the images from it, or users can make it private, restricting access to authorized users or teams.

Note	The free tier of Quay.io does not allow for private repositories. You must upgrade to a paid tier of Quay.io to create a private repository. For more information, see "Information about Quay.io pricing".

You can create a repository in Quay.io by pushing an image with the relevant podman command, or by using the Quay.io UI. You can also use the UI to delete a repository.

If you push an image through the command-line interface (CLI) without first creating a repository on the UI, the created repository is set to Private, regardless of the plan you have.

Note	Create a repository on the Quay.io UI before you push an image. Quay.io checks the plan status and does not allow creation of a private repository if a plan is not active.

Creating a repository by using the UI

To create an image repository in Quay, you can use the UI. You select a namespace and set a repository name and visibility.

Use the following procedure to create a repository using the Quay UI.

Procedure

Click Repositories on the navigation pane.
Click Create Repository.

Select a namespace, for example, quayadmin, and then enter a Repository name, for example, testrepo.

Important

Do not use the following words in your repository name: * build * trigger * tag * notification

When these words are used for repository names, users are unable access the repository, and are unable to permanently delete the repository. Attempting to delete these repositories returns the following error: Failed to delete repository <repository_name>, HTTP404 - Not Found.

Click Create.

Now, your example repository should populate under the Repositories page.
Optional. Click Settings → Repository visibility → Make private to set the repository to private.

Creating a repository by using Podman

To create a repository in Project Quay, you can push an image with Podman. The push creates the repository if it does not already exist.

If you push an image through the command-line interface (CLI) without first creating a repository on the UI, the created repository is set to Private.

This applies regardless of the plan you have.

Note	It is recommended that you create a repository on the Quay.io UI before pushing an image. Quay.io checks the plan status and does not allow creation of a private repository if a plan is not active.

Prerequisites

You have download and installed the podman CLI.
You have logged into your registry.
You have pulled an image, for example, busybox.

Procedure

Pull a sample page from an example registry. For example:

$ podman pull busybox

Example output

Trying to pull docker.io/library/busybox...
Getting image source signatures
Copying blob 4c892f00285e done
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures
22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

Tag the image on your local system with the new repository and image name. For example:
```
$ podman tag docker.io/library/busybox quay.io/quayadmin/busybox:test
```

Push the image to the registry. Following this step, you can use your browser to see the tagged image in your repository.

$ podman push --tls-verify=false quay.io/quayadmin/busybox:test

Example output

Getting image source signatures
Copying blob 6b245f040973 done
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures

Deleting a repository by using the UI

To delete an image repository in Quay, you can use the UI. You remove the repository and its tags from the selected namespace.

Prerequisites

You have created a repository.

Procedure

On the Repositories page of the v2 UI, check the box of the repository that you want to delete, for example, quayadmin/busybox.
Click the Actions drop-down menu.
Click Delete.
Type confirm in the box, and then click Delete.

After deletion, you are returned to the Repositories page.

User settings

The Quay.io User Settings page lets you manage account preferences such as email, password, notifications, and billing. You can also adjust time machine settings or delete your account.

The User Settings page provides users a way to set their email address, password, account type, set up desktop notifications, select an avatar, delete an account, adjust the time machine setting, and view billing information.

Navigating to the User Settings page

To open the User Settings page in Quay.io, you can use the account menu in the header. You select Account Settings to open the page.

Procedure

On Quay.io, click your username in the header.
Select Account Settings. You are redirected to the User Settings page.

Adjusting user settings

To update your Quay.io account preferences, you can use the User Settings page. You can change email, password, account type, notifications, time machine, or delete the account.

Procedure

To change your email address, select the current email address for Email Address. In the pop-up window, enter a new email address, then, click Change Email. A verification email will be sent before the change is applied.
To change your password, click Change password. Enter the new password in both boxes, then click Change Password.
Change the account type by clicking Individual Account, or the option next to Account Type. In some cases, you might have to leave an organization prior to changing the account type.
Adjust your desktop notifications by clicking the option next to Desktop Notifications. Users can either enable, or disable, this feature.
You can delete an account by clicking Begin deletion. You cannot delete an account if you have an active plan, or if you are a member of an organization where you are the only administrator. You must confirm deletion by entering the namespace.

Important

Deleting an account is not reversible and will delete all of the account’s data including repositories, created build triggers, and notifications.
You can set the time machine feature by clicking the drop-box next to Time Machine. This feature dictates the amount of time after a tag is deleted that the tag is accessible in time machine before being garbage collected. After selecting a time, click Save Expiration Time.

Billing information

The Billing information section on the Quay.io User Settings page shows your current plan, invoices, and receipt options. You can review plan details and manage how receipts are sent.

The following information is available:

Current Plan. This section denotes the current plan Quay.io plan that you are signed up for. It also shows the amount of private repositories you have.
Invoices. If you are on a paid plan, you can click View Invoices to view a list of invoices.
Receipts. If you are on a paid plan, you can select whether to have receipts for payment emailed to you, another user, or to opt out of receipts altogether.

Project Quay Robot Account overview

A robot account provides automated, credential-based access to repositories in your registry, similar to OpenShift Container Platform service accounts. You can use robot accounts to grant container clients push and pull permissions without sharing personal credentials.

Setting up a Robot Account results in the following:

Credentials are generated for the Robot Account.
Repositories and images that the Robot Account can push and pull images from are identified.
Generated credentials can be copied and pasted to use with different container clients, such as Docker, Podman, Kubernetes, Mesos, and so on, to access each defined repository.

Each Robot Account is limited to a single user namespace or Organization. For example, the Robot Account could provide access to all repositories for the user quayadmin. However, it cannot provide access to repositories that are not in the user’s list of repositories.

Robot Accounts can be created using the Project Quay UI, or through the CLI using the Project Quay API. After creation, Project Quay administrators can leverage more advanced features with Robot Accounts, such as keyless authentication.

Creating a robot account by using the UI

To automate access to your repositories, you can create a robot account by using the Project Quay v2 UI. Robot accounts generate credentials that container clients can use to push and pull images without a personal login.

Procedure

On the v2 UI, click Organizations.
Click the name of the organization that you create the robot account for, for example, test-org.
Click the Robot accounts tab → Create robot account.
In the Provide a name for your robot account box, enter a name, for example, robot1. The name of your Robot Account becomes a combination of your username plus the name of the robot, for example, quayadmin+robot1
Optional. The following options are available if desired:
1. Add the robot account to a team.
2. Add the robot account to a repository.
3. Adjust the robot account’s permissions.
On the Review and finish page, review the information you have provided, then click Review and finish. The following alert appears: Successfully created robot account with robot name: <organization_name> + <robot_name>.

Alternatively, if you tried to create a robot account with the same name as another robot account, you might receive the following error message: Error creating robot account.
Optional. You can click Expand or Collapse to reveal descriptive information about the robot account.
Optional. You can change permissions of the robot account by clicking the kebab menu → Set repository permissions. The following message appears: Successfully updated repository permission.
Optional. You can click the name of your robot account to obtain the following information:
- Robot Account: Select this obtain the robot account token. You can regenerate the token by clicking Regenerate token now.
- Kubernetes Secret: Select this to download credentials in the form of a Kubernetes pull secret YAML file.
- Podman: Select this to copy a full podman login command line that includes the credentials.
- Docker Configuration: Select this to copy a full docker login command line that includes the credentials.

Bulk managing robot account repository access

To grant a robot account access to several repositories at once, you can set its permissions in bulk by using the Project Quay v2 UI.

Prerequisites

You have created a robot account.
You have created multiple repositories under a single organization.

Procedure

On the Project Quay v2 UI landing page, click Organizations in the navigation pane.
On the Organizations page, select the name of the organization that has multiple repositories. The number of repositories under a single organization can be found under the Repo Count column.
On your organization’s page, click Robot accounts.
For the robot account that you want to add to multiple repositories, click the kebab icon → Set repository permissions.
On the Set repository permissions page, check the boxes of the repositories that you want to add the robot account to. For example:
Set the permissions for the robot account, for example, None, Read, Write, Admin.
Click save. An alert that says Success alert: Successfully updated repository permission appears on the Set repository permissions page, confirming the changes.
Return to the Organizations → Robot accounts page. Now, the Repositories column of your robot account shows the number of repositories that the robot account has been added to.

Disabling robot accounts

To prevent users from creating new robot accounts, you can disable robot account creation in your Project Quay configuration file. This setting also blocks robot accounts required for repository mirroring, so review your mirroring setup first.

Important

Robot accounts are mandatory for repository mirroring. Setting the ROBOTS_DISALLOW configuration field to True breaks mirroring configurations. Users mirroring repositories should not set ROBOTS_DISALLOW to True in their config.yaml file. This is a known issue in Project Quay.

Prerequisites

You have created multiple robot accounts.

Procedure

Update your config.yaml field to add the ROBOTS_DISALLOW variable, for example:
```
ROBOTS_DISALLOW: true
```
Restart your Project Quay deployment.

Verification

Navigate to your Project Quay repository.
Click the name of a repository.
In the navigation pane, click Robot Accounts.
Click Create Robot Account.
Enter a name for the robot account, for example, <organization-name/username>+<robot-name>.
Click Create robot account to confirm creation. The following message appears: Cannot create robot account. Robot accounts have been disabled. Please contact your administrator.

On the command-line interface (CLI), attempt to log in as one of the robot accounts by entering the following command:

$ podman login -u="<organization-name/username>+<robot-name>" -p="KETJ6VN0WT8YLLNXUJJ4454ZI6TZJ98NV41OE02PC2IQXVXRFQ1EJ36V12345678" <quay-server.example.com>

The following error message is returned:

Error: logging into "<quay-server.example.com>": invalid username/password

You can pass in the log-level=debug flag to confirm that robot accounts have been deactivated:

$ podman login -u="<organization-name/username>+<robot-name>" -p="KETJ6VN0WT8YLLNXUJJ4454ZI6TZJ98NV41OE02PC2IQXVXRFQ1EJ36V12345678" --log-level=debug <quay-server.example.com>

...
DEBU[0000] error logging into "quay-server.example.com": unable to retrieve auth token: invalid username/password: unauthorized: Robot accounts have been disabled. Please contact your administrator.

Deleting a robot account by using the UI

To remove a robot account that you no longer need, you can delete it by using the Project Quay UI.

Procedure

Log into your Project Quay registry:
Click the name of the Organization that has the robot account.
Click Robot accounts.
Check the box of the robot account to be deleted.
Click the kebab menu.
Click Delete.
Type confirm into the textbox, then click Delete.

Keyless authentication with robot accounts

With keyless authentication in Project Quay, you can exchange an OIDC token for a short-lived robot account token that expires after one hour.

In previous versions of Project Quay, robot account tokens were valid for the lifetime of the token unless deleted or regenerated. Tokens that do not expire have security implications for users who do not want to store long-term passwords or manage the deletion or regeneration of authentication tokens.

Keyless authentication reduces the risk of robot token exposure by removing exchanged tokens after one hour.

Configuring keyless authentication with robot accounts is a multi-step procedure that requires setting a robot federation, generating an OAuth2 token from your OIDC provider, and exchanging the OAuth2 token for a robot account access token.

Generating an OAuth2 token with Red Hat Single Sign-On

To exchange an external OIDC token for a Project Quay robot account token, you can first generate an OAuth2 token by using Red Hat Single Sign-On.

Procedure

On the Red Hat Single Sign-On UI:
1. Click Clients and then the name of the application or service that can request authentication of a user.
2. On the Settings page of your client, ensure that the following options are set or enabled:
  - Client ID
  - Valid redirect URI
  - Client authentication
  - Authorization
  - Standard flow
  - Direct access grants
    
    Note
    
    Settings can differ depending on your setup.
3. On the Credentials page, store the Client Secret for future use.
4. On the Users page, click Add user and enter a username, for example, service-account-quaydev. Then, click Create.
5. Click the name of the user, for example service-account-quaydev on the Users page.
6. Click the Credentials tab → Set password → and provide a password for the user. If warranted, you can make this password temporary by selecting the Temporary option.
7. Click the Realm settings tab → OpenID Endpoint Configuration. Store the /protocol/openid-connect/token endpoint. For example:
  http://localhost:8080/realms/master/protocol/openid-connect/token

On a web browser, navigate to the following URL:

http://<keycloak_url>/realms/<realm_name>/protocol/openid-connect/auth?response_type=code&client_id=<client_id>

When prompted, log in with the service-account-quaydev user and the temporary password you set. Complete the login by providing the required information and setting a permanent password if necessary.

You are redirected to the URI address provided for your client. For example:

https://localhost:3000/cb?session_state=5c9bce22-6b85-4654-b716-e9bbb3e755bc&iss=http%3A%2F%2Flocalhost%3A8080%2Frealms%2Fmaster&code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43

Take note of the code provided in the address. For example:

code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43

Note	This is a temporary code that can only be used one time. If necessary, you can refresh the page or revisit the URL to obtain another code.

On your terminal, use the following curl -X POST command to generate a temporary OAuth2 access token:

$ curl -X POST "http://localhost:8080/realms/master/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=quaydev" \
-d "client_secret=g8gPsBLxVrLo2PjmZkYBdKvcB9C7fmBz" \
-d "grant_type=authorization_code" \
-d "code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43"

where:

http://localhost:8080/realms/master/protocol/openid-connect/token

Specifies the protocol/openid-connect/token endpoint found on the Realm settings page of the Red Hat Single Sign-On UI.

quaydev

Specifies the Client ID used for this procedure.

g8gPsBLxVrLo2PjmZkYBdKvcB9C7fmBz

Specifies the Client Secret for the Client ID.

ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43

Specifies the code returned from the redirect URI.

Example output

{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJTVmExVHZ6eDd2cHVmc1dkZmc1SHdua1ZDcVlOM01DN1N5T016R0QwVGhVIn0...",
"expires_in":60,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJiNTBlZTVkMS05OTc1LTQwMzUtYjNkNy1lMWQ5ZTJmMjg0MTEifQ.oBDx6B3pUkXQO8m-M3hYE7v-w25ak6y70CQd5J8f5EuldhvTwpWrC1K7yOglvs09dQxtq8ont12rKIoCIi4WXw","token_type":"Bearer","not-before-policy":0,"session_state":"5c9bce22-6b85-4654-b716-e9bbb3e755bc","scope":"profile email"}

Store the access_token from the previous step so that you can exchange it for a Project Quay robot account token in the following procedure.

Setting up a robot account federation by using the Project Quay v2 UI

To configure robot account federation in Project Quay, you can map an OIDC issuer and subject to a robot account in the v2 UI.

This procedure uses Red Hat Single Sign-On, which is based on the Keycloak project. The steps, and the information used to configure a robot account federation, vary depending on your OIDC provider.

Prerequisites

You have created an organization. The following example uses fed_test.
You have created a robot account. The following example uses fest_test+robot1.
You have configured OIDC for your Project Quay deployment. The following example uses Red Hat Single Sign-On.

Procedure

On the Red Hat Single Sign-On main page:

Select the appropriate realm that is authenticated for use with Project Quay. Store the issuer URL, for example, https://keycloak-auth-realm.quayadmin.org/realms/quayrealm.
Click Users → the name of the user to be linked with the robot account for authentication. You must use the same user account that you used when generating the OAuth2 access token.

On the Details page, store the ID of the user, for example, 449e14f8-9eb5-4d59-a63e-b7a77c75f770.

Note

The information collected in this step varies depending on your OIDC provider. For example, with Red Hat Single Sign-On, the ID of a user is used as the Subject to configure the robot account federation in a subsequent step. For a different OIDC provider, like Microsoft Entra ID, this information is stored as the Subject.

On your Project Quay registry:
1. Navigate to Organizations and click the name of your organization, for example, fed_test.
2. Click Robot Accounts.
3. Click the menu kebab → Set robot federation.
4. Click the + symbol.
5. In the popup window, include the following information:
  - Issuer URL: https://keycloak-auth-realm.quayadmin.org/realms/quayrealm. For Red Hat Single Sign-On, this is the URL of your Red Hat Single Sign-On realm. This might vary depending on your OIDC provider.
  - Subject: 449e14f8-9eb5-4d59-a63e-b7a77c75f770. For Red Hat Single Sign-On, the Subject is the ID of your Red Hat Single Sign-On user. This varies depending on your OIDC provider. For example, if you are using Microsoft Entra ID, the Subject is the Subject of your Entra ID user.
6. Click Save.
  
  Note
  
  The Project Quay v2 UI federation modal accepts Issuer URL and Subject only.

Additional resources

Configuring federation audiences

Configuring federation audiences

To manage robot federation entries in Project Quay, you can use the robot federation API to set the issuer and subject that map an OIDC identity to a robot account.

Each robot federation entry maps an external OIDC identity (issuer and subject) to a Project Quay robot account. Starting in Project Quay 3.18, robot federation supports an optional audiences array on each entry for token audience validation during federated robot token exchange (GET /oauth2/federation/robot/token).

Important

In Project Quay 3.18, create and update requests persist issuer and subject only. The optional audiences field is not stored from API requests, and the Project Quay v2 UI federation modal does not provide an audiences field. Until API support is available, federated robot token exchange skips audience validation and logs a deprecation warning when audiences is not stored for the matching federation entry. A later release requires audiences for federated robot authentication.

When audiences is present in stored federation configuration, configure it to match the aud claim values your OIDC provider issues—for example, a custom API audience such as api://quay-api for Microsoft Entra ID v2.0 tokens, or your OIDC client ID for standard flows. For Microsoft Entra ID v2.0, use an application-specific audience rather than the Microsoft Graph audience.

Prerequisites

You have created an organization and robot account.
You have configured OIDC for your Project Quay deployment.
You have the issuer URL and subject identifier from your OIDC provider.

Procedure

Create or update the robot federation configuration by using POST /api/v1/organization/{orgname}/robots/{robot_shortname}/federation. Include issuer and subject in each federation entry. For example:

$ curl -X POST "https://<quay-server.example.com>/api/v1/organization/fed_test/robots/robot1/federation" \
  -H "Authorization: Bearer <your_access_token>" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
      "subject": "<user-object-id>"
    }
  ]'

After you configure federation, exchange an external OIDC access token for a Project Quay robot token.

Additional resources

Exchanging an OAuth2 access token for a Project Quay robot account token
createOrgRobotFederation

Exchanging an OAuth2 access token for a Project Quay robot account token

To authenticate with a federated robot account in Project Quay, you can exchange an OAuth2 access token for a short-lived robot token by using a Python script.

Note	The following example uses a Python script to exchange the OAuth2 access token for a Project Quay robot account token.

Prerequisites

You have the python3 CLI tool installed.

Procedure

Save the following Python script in a .py file, for example, robot_fed_token_auth.py:
```
import requests
import os

TOKEN=os.environ.get('TOKEN')
robot_user = "fed-test+robot1"

def get_quay_robot_token(fed_token):
    URL = "https://<quay-server.example.com>/oauth2/federation/robot/token"
    response = requests.get(URL, auth=(robot_user,fed_token))
    print(response)
    print(response.text)

if __name__ == "__main__":
    get_quay_robot_token(TOKEN)
```
where:

response = requests.get(URL, auth=(robot_user,fed_token))

Specifies the request that retrieves the robot token. If your Project Quay deployment is using custom SSL/TLS certificates, the response must be response = requests.get(URL,auth=(robot_user,fed_token),verify=False), which includes the verify=False flag.

Export the OAuth2 access token as TOKEN. For example:

$ export TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJTVmExVHZ6eDd2cHVmc1dkZmc1SHdua1ZDcVlOM01DN1N5T016R0QwVGhVIn0...

Run the robot_fed_token_auth.py script by entering the following command:
```
$ python3 robot_fed_token_auth.py
```
Example output
```
<Response [200]>
{"token": "string..."}
```
Important

This token expires after one hour. After one hour, you must generate a new token.

Export the robot account access token as QUAY_TOKEN. For example:

$ export QUAY_TOKEN=291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJlbWFpbF92ZXJpZ

Pushing and pulling images

To verify federated robot account access in Project Quay, you can log in with the robot token and pull images that the robot is allowed to access.

Prerequisites

You have exported the OAuth2 access token into a new robot account access token.

Procedure

Log in to your Project Quay registry by using the fed_test+robot1 robot account and the QUAY_TOKEN access token. For example:
```
$ podman login <quay-server.example.com> -u fed_test+robot1 -p $QUAY_TOKEN
```

Pull an image from a Project Quay repository for which the robot account has the proper permissions. For example:

$ podman pull <quay-server.example.com>/<repository_name>/<image_name>

Example output

Getting image source signatures
Copying blob 900e6061671b done
Copying config 8135583d97 done
Writing manifest to image destination
Storing signatures
8135583d97feb82398909c9c97607159e6db2c4ca2c885c0b8f590ee0f9fe90d
0.57user 0.11system 0:00.99elapsed 68%CPU (0avgtext+0avgdata 78716maxresident)k
800inputs+15424outputs (18major+6528minor)pagefaults 0swaps

Attempt to pull an image from a Project Quay repository for which the robot account does not have the proper permissions. For example:

$ podman pull <quay-server.example.com>/<different_repository_name>/<image_name>

Example output

Error: initializing source docker://quay-server.example.com/example_repository/busybox:latest: reading manifest in quay-server.example.com/example_repository/busybox: unauthorized: access to the requested resource is not authorized

After one hour, the credentials for this robot account expire. Afterwards, you must generate a new access token for this robot account.

Access management for Project Quay

Access management in Project Quay controls who can use repositories through users, teams, and robot accounts. You can set roles and permissions for collaborative registry workflows.

As a Quay user, you can create your own repositories and make them accessible to other users that are part of your instance. Alternatively, you can create an organization and associate a set of repositories directly to that organization, referred to as an organization repository.

Organization repositories differ from basic repositories in that the organization is intended to set up shared repositories through groups of users. In Quay, groups of users can be either Teams, or sets of users with the same permissions, or individual users. You can also allow access to user repositories and organization repositories by creating credentials associated with Robot Accounts. Robot Accounts make it easy for a variety of container clients, such as Docker or Podman, to access your repositories without requiring that the client have a user account.

Project Quay teams overview

A team in Quay is a group of users that share permissions, which simplifies access control and collaboration across organizations and repositories. You can assign a team specific permissions so that its members have appropriate access based on their roles.

Creating a team by using the UI

To create a team in Project Quay, you can use the UI. You add a team under an organization and then assign members and roles.

When you create a team for your organization you can select the team name, choose which repositories to make available to the team, and decide the level of access to the team.

Use the following procedure to create a team for your organization repository.

Prerequisites

You have created an organization.

Procedure

On the Project Quay v2 UI, click the name of an organization.
On your organization’s page, click Teams and membership.
Click the Create new team box.
In the Create team popup window, provide a name for your new team.
Optional. Provide a description for your new team.
Click Proceed. A new popup window appears.
Optional. Add this team to a repository, and set the permissions to one of the following:
- None. Team members have no permission to the repository.
- Read. Team members can view and pull from the repository.
- Write. Team members can read (pull) from and write (push) to the repository.
- Admin. Full access to pull from, and push to, the repository, plus the ability to do administrative tasks associated with the repository.
Optional. Add a team member or robot account. To add a team member, enter the name of their Project Quay account.
Review and finish the information, then click Review and Finish. The new team appears under the Teams and membership page.

Managing a team by using the UI

After you create a team in Quay, you can manage members, repository permissions, and team details in the UI. You can also delete a team that you no longer need.

Adding users to a team by using the UI

To add users to a team in Quay, you can use the UI. You invite members so they inherit the team’s repository permissions.

With administrative privileges to an Organization, you can add users and robot accounts to a team. When you add a user, Quay sends an email to that user. The user remains pending until they accept the invitation.

Use the following procedure to add users or robot accounts to a team.

Procedure

On the Project Quay landing page, click the name of your Organization.
In the navigation pane, click Teams and Membership.
Select the menu kebab of the team that you want to add users or robot accounts to. Then, click Manage team members.
Click Add new member.

In the textbox, enter information for one of the following:

A username from an account on the registry.
The email address for a user account on the registry.

The name of a robot account. The name must be in the form of <organization_name>+<robot_name>.

Note

Robot Accounts are immediately added to the team. For user accounts, an invitation to join is mailed to the user. Until the user accepts that invitation, the user remains in the INVITED TO JOIN state. After the user accepts the email invitation to join the team, they move from the INVITED TO JOIN list to the MEMBERS list for the Organization.

Click Add member.

Setting a team role by using the UI

To assign a role to a team within a Quay organization, you can use the UI. Team roles determine a member’s permissions, such as administrative or contributor access.

Prerequisites

You have created a team.

Procedure

On the Project Quay landing page, click the name of your Organization.
In the navigation pane, click Teams and Membership.
Select the TEAM ROLE drop-down menu, as shown in the following figure:
For the selected team, choose one of the following roles:
- Admin. Full administrative access to the organization, including the ability to create teams, add members, and set permissions.
- Member. Inherits all permissions set for the team.
- Creator. All member permissions, plus the ability to create new repositories.

Managing team members and repository permissions

To manage team members and set repository permissions for a team, you can use the Quay UI. You can add or remove members, and adjust access levels for each repository.

Procedure

On the Teams and membership page of your organization, you can also manage team members and set repository permissions.
- Click the kebab menu, and select one of the following options:
- Manage Team Members. On this page, you can view all members, team members, robot accounts, or users who have been invited. You can also add a new team member by clicking Add new member.
- Set repository permissions. On this page, you can set the repository permissions to one of the following:
  - None. Team members have no permission to the repository.
  - Read. Team members can view and pull from the repository.
  - Write. Team members can read (pull) from and write (push) to the repository.
  - Admin. Full access to pull from, and push to, the repository, plus the ability to do administrative tasks associated with the repository.
- Delete. This popup window allows you to delete the team by clicking Delete.

Viewing additional information about a team

To review team details in Quay, you can use the Teams and membership page. You can switch among team, members, and collaborators views.

Use the following procedure to view general information about the team.

Procedure

On the Teams and membership page of your organization, you can click the one of the following options to reveal more information about teams, members, and collaborators:
- Team View. This menu shows all team names, the number of members, the number of repositories, and the role for each team.
- Members View. This menu shows all usernames of team members, the teams that they are part of, the repository permissions of the user.
- Collaborators View. This menu shows repository collaborators. Collaborators are users that do not belong to any team in the organization, but who have direct permissions on one or more repositories belonging to the organization.

Managing a team by using the Project Quay API

You can manage teams in Project Quay by using the API. You can view permissions, add or remove members, and delete organization teams.

The following modules show you how to manage a team by using the Project Quay API.

Setting the role of a team within an organization by using the API

To view or change a team’s role within an Project Quay organization, you can use the API. You can set the role to admin, member, or creator.

Prerequisites

You have Created an OAuth access token.

Procedure

Enter the following GET /api/v1/organization/{orgname}/team/{teamname}/permissions command to return a list of repository permissions for the organization’s team. Note that your team must have been added to a repository for this command to return information.
```
$ curl -X GET \
  -H "Authorization: Bearer <your_access_token>" \
  "<quay-server.example.com>/api/v1/organization/<organization_name>/team/<team_name>/permissions"
```
Example output
```
{"permissions": [{"repository": {"name": "api-repo", "is_public": true}, "role": "admin"}]}
```

You can create or update a team within an organization to have a specified role of admin, member, or creator using the PUT /api/v1/organization/{orgname}/team/{teamname} command. For example:

$ curl -X PUT \
  -H "Authorization: Bearer <your_access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "role": "<role>"
  }' \
  "<quay-server.example.com>/api/v1/organization/<organization_name>/team/<team_name>"

Example output

{"name": "testteam", "description": "", "can_view": true, "role": "creator", "avatar": {"name": "testteam", "hash": "827f8c5762148d7e85402495b126e0a18b9b168170416ed04b49aae551099dc8", "color": "#ff7f0e", "kind": "team"}, "new_team": false}

Creating and managing default permissions by using the UI

To grant access automatically when users create repositories in Project Quay, you can configure default permissions in the UI. Default permissions apply to a selected user, robot, or team in addition to the repository creator.

Procedure

Click the name of an organization.
Click Default permissions.
Click Create default permissions. A toggle drawer appears.
Select either Anyone or Specific user to create a default permission when a repository is created.
1. If selecting Anyone, the following information must be provided:
  - Applied to. Search, invite, or add a user/robot/team.
  - Permission. Set the permission to one of Read, Write, or Admin.
2. If selecting Specific user, the following information must be provided:
  - Repository creator. Provide either a user or robot account.
  - Applied to. Provide a username, robot account, or team name.
  - Permission. Set the permission to one of Read, Write, or Admin.
Click Create default permission. A confirmation box appears, returning the following alert: Successfully created default permission for creator.

Adjusting access settings for a repository by using the UI

To change access for a user or robot account on a repository, you can use the Quay UI. You can set Read, Write, or Admin permissions.

Prerequisites

You have created a user account or robot account.

Procedure

Log into Quay.
On the v2 UI, click Repositories.
Click the name of a repository, for example, quayadmin/busybox.
Click the Settings tab.
Optional. Click User and robot permissions. You can adjust the settings for a user or robot account by clicking the dropdown menu option under Permissions. You can change the settings to Read, Write, or Admin.
- Read. The User or Robot Account can view and pull from the repository.
- Write. The User or Robot Account can read (pull) from and write (push) to the repository.
- Admin. The User or Robot account has access to pull from, and push to, the repository, plus the ability to do administrative tasks associated with the repository.

Image tags overview

An image tag identifies a specific version or variant of a container image in Project Quay. You can use tags to manage versioning, rollbacks, environment-specific builds, and CI/CD workflows for your images.

Container images are typically composed of multiple layers that represent different parts of the image. Image tags have the following benefits:

Versioning and Releases: Image tags allow you to denote different versions or releases of an application or software. For example, you might have an image tagged as v1.0 to represent the initial release and v1.1 for an updated version. This helps in maintaining a clear record of image versions.
Rollbacks and Testing: If you encounter issues with a new image version, you can easily revert to a previous version by specifying its tag. This is helpful during debugging and testing phases.
Development Environments: Image tags are beneficial when working with different environments. You might use a dev tag for a development version, qa for quality assurance testing, and prod for production, each with their respective features and configurations.
Continuous Integration/Continuous Deployment (CI/CD): CI/CD pipelines often utilize image tags to automate the deployment process. New code changes can trigger the creation of a new image with a specific tag, enabling seamless updates.
Feature Branches: When multiple developers are working on different features or bug fixes, they can create distinct image tags for their changes. This helps in isolating and testing individual features.
Customization: You can use image tags to customize images with different configurations, dependencies, or optimizations, while keeping track of each variant.
Security and Patching: When security vulnerabilities are discovered, you can create patched versions of images with updated tags, ensuring that your systems are using the latest secure versions.
Dockerfile Changes: If you modify the Dockerfile or build process, you can use image tags to differentiate between images built from the previous and updated Dockerfiles.

Overall, image tags provide a structured way to manage and organize container images, enabling efficient development, deployment, and maintenance workflows.

Viewing image tag information by using the UI

To review details about an image tag, such as its digest, size, and vulnerabilities, you can open the tag’s Details page in the Project Quay v2 UI. You can also view the tag’s security report and package list from the same page.

Prerequisites

You have pushed an image tag to a repository.

Procedure

On the v2 UI, click Repositories.
Click the name of a repository.
Click the name of a tag. You are taken to the Details page of that tag. The page reveals the following information:
- Name
- Repository
- Digest
- Vulnerabilities
- Creation
- Modified
- Size
- Labels
- How to fetch the image tag
Click Security Report to view the tag’s vulnerabilities. You can expand an advisory column to open up CVE data.
Click Packages to view the tag’s packages.
Click the name of the repository to return to the Tags page.

Adding a new image tag to an image by using the UI

To create an alias for an existing image, you can add a new tag to it from the Repositories page of the Project Quay v2 UI. The new tag points to the same image and appears immediately in the repository’s tag list.

Procedure

On the Project Quay v2 UI dashboard, click Repositories in the navigation pane.
Click the name of a repository that has image tags.
Click the menu kebab, then click Add new tag.
Enter a name for the tag, then, click Create tag.

The new tag is now listed on the Repository Tags page.

Adding and managing labels by using the UI

You can add key-value labels to an image tag in the Project Quay v2 UI to record metadata such as a release date or build source. Administrators can add, edit, or remove labels for any tag in a repository.

Procedure

On the v2 UI dashboard, click Repositories in the navigation pane.
Click the name of a repository that has image tags.
Click the menu kebab for an image and select Edit labels.
In the Edit labels window, click Add new label.
Enter a label for the image tag using the key=value format, for example, com.example.release-date=2023-11-14.

Note

The following error is returned when failing to use the key=value format: Invalid label format, must be key value separated by =.
Click the whitespace of the box to add the label.
Optional. Add a second label.
Click Save labels to save the label to the image tag. The following notification is returned: Created labels successfully.
Optional. Click the same image tag’s menu kebab → Edit labels → X on the label to remove it; alternatively, you can edit the text. Click Save labels. The label is now removed or edited.

Setting tag expirations

You can set image tags in Project Quay to expire at a chosen date and time. Expired tags are deleted from the repository according to your time machine retention settings.

This feature includes the following characteristics:

When an image tag expires, it is deleted from the repository. If it is the last tag for a specific image, the image is also set to be deleted.
Expiration is set on a per-tag basis. It is not set for a repository as a whole.
After a tag is expired or deleted, it is not immediately removed from the registry. This is contingent upon the allotted time designed in the time machine feature, which defines when the tag is permanently deleted, or garbage collected. By default, this value is set at 14 days, however the administrator can adjust this time to one of multiple options. Up until the point that garbage collection occurs, tags changes can be reverted.

Tag expiration can be set up in one of three ways:

By setting the quay.expires-after= label in the Dockerfile when the image is created. This sets a time to expire from when the image is built. This label only works for image manifests.
By setting the quay.expires-after= annotation label in the Dockerfile when the image is created. --annotation can be passed in for both image manifests and image indexes.
By selecting an expiration date on the Quay.io UI. For example:

Setting tag expirations can help automate the cleanup of older or unused tags, helping to reduce storage space.

Setting tag expiration from a repository

To set a tag expiration date in Project Quay, you can use the repository Tags page. You can change expiration for one tag or for multiple tags at once.

Procedure

On the Project Quay v2 UI dashboard, click Repositories in the navigation pane.
Click the name of a repository that has image tags.
Click the menu kebab for an image and select Change expiration.
Optional. Alternatively, you can bulk add expiration dates by clicking the box of multiple tags, and then select Actions → Set expiration.
In the Change Tags Expiration window, set an expiration date, specifying the day of the week, month, day of the month, and year. For example, Wednesday, November 15, 2023. Alternatively, you can click the calendar button and manually select the date.
Set the time, for example, 2:30 PM.
Click Change Expiration to confirm the date and time. The following notification is returned: Successfully set expiration for tag test to Nov 15, 2023, 2:26 PM.
On the Project Quay v2 UI Tags page, you can see when the tag is set to expire. For example:

Setting tag expiration from a Dockerfile

To expire an image tag automatically in Project Quay, you can add a quay.expires-after label in a Dockerfile. Expiration starts when you push the image to the registry.

You can add a label, for example, quay.expires-after=20h to an image tag by using the docker label command to cause the tag to automatically expire after the time that is indicated. The following values for hours, days, or weeks are accepted:

1h
2d
3w

Expiration begins from the time that the image is pushed to the registry.

Procedure

Enter the following docker label command to add a label to the desired image tag. The label should be in the format quay.expires-after=20h to indicate that the tag should expire after 20 hours. Replace 20h with the desired expiration time. For example:
```
$ docker label quay.expires-after=20h quay-server.example.com/quayadmin/<image>:<tag>
```

Setting tag expiration using annotations

To expire an image tag automatically in Project Quay, you can push an image with a quay.expires-after annotation. You can apply the annotation to manifests and indexes.

You can add an annotation, for example, quay.expires-after=20h, by using the --annotation flag when you push an image. The following values for hours, days, or weeks are accepted:

1h
2d
3w

Expiration begins from the time that the image is pushed to the registry.

Note	Using the `--annotation` flag is simplest using the `oras` CLI tool.

Prerequisites

You have downloaded the oras CLI.

Procedure

Enter the following oras push --annotation command to add an annotation to the desired image tag. The annotation should be in the format quay.expires-after=<value> to indicate that the tag should expire the set time. For example:

$ oras push --annotation quay.expires-after=<value> \
  <quay-server.example.com>/<organization>/<repository>:<tag> \
  <file_path>:<media_type>

Example output

✓ Uploaded  hello.txt                                                                                                       12/12  B 100.00%  321ms
  └─ sha256:74b9e308133afb3bceae961097cb2aa481483869d695ce1414cd2bc7f046027c
✓ Uploaded  application/vnd.oci.empty.v1+json                                                                                 2/2  B 100.00%  328ms
  └─ sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
✓ Uploaded  application/vnd.oci.image.manifest.v1+json                                                                    620/620  B 100.00%     0s
  └─ sha256:c370e931b5eca44fd753bd92e6991ed3be70008e8df15078083359409111f8c3
Pushed [registry] quay-server.example.com/fortestuser/busybox:test2
ArtifactType: application/vnd.unknown.artifact.v1

Confirm that the expiration date has been applied by checking the Project Quay UI, or by entering the following command:

$ curl -X GET \
  -H "Authorization: Bearer <bearer_token>" \
  -H "Accept: application/json" \
  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/tag/?specificTag=<tag>" \

Example output

{"tags": [{"name": "test2", "reversion": false, "start_ts": 1743706344, "end_ts": 1743778344, "manifest_digest": "sha256:c370e931b5eca44fd753bd92e6991ed3be70008e8df15078083359409111f8c3", "is_manifest_list": false, "size": 12, "last_modified": "Thu, 03 Apr 2025 18:52:24 -0000", "expiration": "Fri, 04 Apr 2025 14:52:24 -0000"}, {"name": "test2", "reversion": false, "start_ts": 1742493776, "end_ts": 1743706344, "manifest_digest": "sha256:d80aa3d7f5f5388cfae543b990d3cd3d47ff51c48ef29ff66102427bf7bc0a88", "is_manifest_list": false, "size": 2266046, "last_modified": "Thu, 20 Mar 2025 18:02:56 -0000", "expiration": "Thu, 03 Apr 2025 18:52:24 -0000"}], "page": 1, "has_additional": false}

Removing tag expiration using annotations

To clear a tag expiration annotation in Project Quay, you can push the image again with quay.expires-after set to never. The latest manifest no longer carries an expiration time.

With the oras CLI tool, you can unset previously established expiration times.

Prerequisites

You have downloaded the oras CLI.
You have pushed an image with the quay.expires-after=<value> annotation.

Procedure

Enter the following oras push --annotation command to remove an annotation to the desired image tag. The annotation should be in the format quay.expires-after=never. For example:

$ oras push --annotation quay.expires-after=never \
  <quay-server.example.com>/<organization>/<repository>:<tag> \
  <file_path>:<media_type>

Example output

✓ Uploaded  hello.txt                                                                                                       12/12  B 100.00%  321ms
  └─ sha256:74b9e308133afb3bceae961097cb2aa481483869d695ce1414cd2bc7f046027c
✓ Uploaded  application/vnd.oci.empty.v1+json                                                                                 2/2  B 100.00%  328ms
  └─ sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
✓ Uploaded  application/vnd.oci.image.manifest.v1+json                                                                    620/620  B 100.00%     0s
  └─ sha256:c370e931b5eca44fd753bd92e6991ed3be70008e8df15078083359409111f8c3
Pushed [registry] quay-server.example.com/fortestuser/busybox:test2
ArtifactType: application/vnd.unknown.artifact.v1

The latest manifest will no longer have an expiration time. Confirm that the expiration date has been removed by checking the Project Quay UI, or by entering the following command:

{"tags": [{"name": "test2", "reversion": false, "start_ts": 1743708135, "manifest_digest": "sha256:19e3a3501b4125cce9cb6bb26ac9207c325259bef94dc66490b999f93c4c83a9", "is_manifest_list": false, "size": 12, "last_modified": "Thu, 03 Apr 2025 19:22:15 -0000"}, {"name": "test2", "reversion": false, "start_ts": 1743706344, "end_ts": 1743708135}]}

Note that no expiration time is listed.

Additional resources

Installation

Fetching an image by tag or digest

To fetch an image from Project Quay, you can pull by tag or by digest. Digests provide an immutable reference to a specific image manifest.

Procedure

Navigate to the Tags page of a repository.
Under Manifest, click the Fetch Tag icon.
When the popup box appears, users are presented with the following options:
- Podman Pull (by tag)
- Docker Pull (by tag)
- Podman Pull (by digest)
- Docker Pull (by digest)
  
  Selecting any one of the four options returns a command for the respective client that allows users to pull the image.
Click Copy Command to copy the command, which can be used on the command-line interface (CLI). For example:
```
$ podman pull quay.io/quayadmin/busybox:test2
```

Viewing Project Quay tag history by using the UI

To review changes made to an image over time, you can open its Tag History page in the Project Quay v2 UI. You can search by tag name, filter by date range, and see when each tag was modified.

Procedure

On the Project Quay v2 UI dashboard, click Repositories in the navigation pane.
Click the name of a repository that has image tags.
Click Tag History. On this page, you can perform the following actions:
- Search by tag name
- Select a date range
- View tag changes
- View tag modification dates and the time at which they were changed

Deleting an image tag

To remove a specific version of a container image from a repository, you can delete its tag from the Project Quay v2 UI. Depending on your time machine retention settings, you might be able to revert a deleted tag later.

Procedure

On the Repositories page of the v2 UI, click the name of the image you want to delete, for example, quay/admin/busybox.
Click the More Actions drop-down menu.
Click Delete.

Note

If desired, you could click Make Public or Make Private.
Type confirm in the box, and then click Delete.
After deletion, you are returned to the Repositories page.

Note

Deleting an image tag can be reverted based on the amount of time allotted assigned to the time machine feature. For more information, see "Reverting tag changes".

Reverting tag changes by using the UI

To revert tag changes in Project Quay, you can use the UI within the time machine window. You restore a previous tag state before permanent deletion.

Procedure

On the Repositories page of the v2 UI, click the name of the image you want to revert.
Click the Tag History tab.
Find the point in the timeline at which image tags were changed or removed. Next, click the option under Revert to restore a tag to its image.

Viewing and exporting logs

Activity logs in Project Quay record repository and namespace events for operations and security review. You can view usage patterns and export logs for longer-term retention.

Usage logs might reveal the following information:

Resource Planning: Usage logs can provide data on the number of image pulls, pushes, and overall traffic to your registry.
User Activity: Logs can help you track user activity, showing which users are accessing and interacting with images in the registry. This can be useful for auditing, understanding user behavior, and managing access controls.
Usage Patterns: By studying usage patterns, you can gain insights into which images are popular, which versions are frequently used, and which images are rarely accessed. This information can help prioritize image maintenance and cleanup efforts.
Security Auditing: Usage logs enable you to track who is accessing images and when. This is crucial for security auditing, compliance, and investigating any unauthorized or suspicious activity.
Image Lifecycle Management: Logs can reveal which images are being pulled, pushed, and deleted. This information is essential for managing image lifecycles, including deprecating old images and ensuring that only authorized images are used.
Compliance and Regulatory Requirements: Many industries have compliance requirements that mandate tracking and auditing of access to sensitive resources. Usage logs can help you demonstrate compliance with such regulations.
Identifying Abnormal Behavior: Unusual or abnormal patterns in usage logs can indicate potential security breaches or malicious activity. Monitoring these logs can help you detect and respond to security incidents more effectively.
Trend Analysis: Over time, usage logs can provide trends and insights into how your registry is being used. This can help you make informed decisions about resource allocation, access controls, and image management strategies.

There are multiple ways of accessing log files:

Viewing logs through the web UI.
Exporting logs so that they can be saved externally.
Accessing log entries using the API.

To access logs, you must have administrative privileges for the selected repository or namespace.

Note	A maximum of 100 log results are available at a time via the API. To gather more results that that, you must use the log exporter feature described in this chapter.

Viewing usage logs

To review how your registry is being used, you can view usage logs for an organization, repository, or namespace in the Project Quay v2 UI. You can filter by date range and export the logs for later use.

Procedure

Log in to your Project Quay registry.
Navigate to an Organization, repository, or namespace for which you are an administrator of.
Click Logs.
Optional. Set the date range for viewing log entries by adding dates to the From and To boxes.
Optional. Export the logs by clicking Export. You must enter an email address or a valid callback URL that uses the HTTP or HTTPS scheme. This process can take an hour depending on how many logs there are.

Exporting repository logs by using the UI

To export repository logs from Project Quay, you can use the Export Logs feature in the UI. You receive the exported data by email or callback URL, and it expires after a set time.

This feature has the following benefits and constraints:

You can choose a range of dates for the logs you want to gather from a repository.
You can request that the logs be sent to you by an email attachment or directed to a callback URL.
To export logs, you must be an administrator of the repository or namespace.
30 days worth of logs are retained for all users.
Export logs only gathers log data that was previously produced. It does not stream logging data.
When logs are gathered and made available to you, you should immediately copy that data if you want to save it. By default, the data expires after one hour.

Use the following procedure to export logs.

Procedure

Select a repository for which you have administrator privileges.
Click the Logs tab.
Optional. If you want to specify specific dates, enter the range in the From and to boxes.
Click the Export Logs button. An Export Usage Logs pop-up appears, as shown
Enter an email address or callback URL to receive the exported log. For the callback URL, you can use a URL to a specified domain, for example, <webhook.site>.
Select Confirm to start the process for gather the selected log entries. Depending on the amount of logging data being gathered, this can take anywhere from a few minutes to several hours to complete.
When the log export is completed, the one of following two events happens:
- An email is received, alerting you to the available of your requested exported log entries.
- A successful status of your log export request from the webhook URL is returned. Additionally, a link to the exported data is made available for you to delete to download the logs.

Clair security scanner

Clair is a vulnerability scanner for container images in Project Quay. You can use it to analyze image layers and report security issues from upstream CVE databases.

Clair v4 (Clair) leverages static code analyses for parsing image content and reporting vulnerabilities affecting the content. Quay.io includes Clair, enables it automatically, and the Project Quay development team manages it.

For Quay.io users, images are automatically indexed after they are pushed to your repository. Reports are then fetched from Clair, which matches images against its CVE database to report security information. This process happens automatically on Quay.io, and manual rescans are not required.

About Clair

Clair scans container images for vulnerabilities in Project Quay. It enriches findings with National Vulnerability Database (NVD) data, including CVSS severity scores that you can use to prioritize remediation.

The NVD is a United States government repository of security-related information, including known vulnerabilities and security issues in various software components and systems. NVD scores provide the following benefits:

Data synchronization. Clair can periodically synchronize its vulnerability database with the NVD. This ensures that it has the latest vulnerability data.
Matching and enrichment. Clair compares the metadata and identifiers of vulnerabilities it discovers in container images with the data from the NVD. This process involves matching the unique identifiers, such as Common Vulnerabilities and Exposures (CVE) IDs, to the entries in the NVD. When a match is found, Clair can enrich its vulnerability information with additional details from NVD, such as severity scores, descriptions, and references.
Severity scores. The NVD assigns severity scores to vulnerabilities, such as the Common Vulnerability Scoring System (CVSS) score, to indicate the potential impact and risk associated with each vulnerability. By incorporating NVD severity scores, Clair can provide more context on the seriousness of the vulnerabilities it detects.

If Clair finds vulnerabilities from NVD, a detailed and standardized assessment of the severity and potential impact of vulnerabilities detected within container images is reported to users on the UI. CVSS enrichment data provides the following benefits:

Vulnerability prioritization. By using CVSS scores, you can prioritize vulnerabilities based on their severity and address the most critical issues first.
Assess risk. CVSS scores can help you understand the potential risk a vulnerability poses to your containerized applications.
Communicate severity. CVSS scores provide a standardized way to communicate the severity of vulnerabilities across teams and organizations.
Inform remediation strategies. CVSS enrichment data can guide Quay.io users in developing appropriate remediation strategies.
Compliance and reporting. Integrating CVSS data into reports generated by Clair can help organizations demonstrate their commitment to addressing security vulnerabilities and complying with industry standards and regulations.

Viewing Clair security scans by using the UI

Additional resources

To review the results of a Clair security scan, you can open the Security Scanner page for a tag in the Project Quay UI. You can inspect detected CVEs and check available remediation options.

Procedure

Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan.
To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view.
Click a relevant link under See Child Manifests, for example, 1 Unknown to be redirected to the Security Scanner page.
The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available.

Note

Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user.

Clair severity mapping

Clair maps severity strings from multiple security databases to a common set of values. You can use the mapped severities to assess vulnerabilities consistently.

Clair severity strings

Clair alerts users with the following severity strings:

Unknown
Negligible
Low
Medium
High
Critical

These severity strings are similar to the strings found within the relevant security database.

The Alpine SecDB database does not provide severity information. All vulnerability severities are Unknown.

Alpine Severity	Clair Severity
*	Unknown

Alpine Severity

Clair Severity

Unknown

The AWS UpdateInfo database provides severity information.

AWS Severity	Clair Severity
low	Low
medium	Medium
important	High
critical	Critical

AWS Severity

Clair Severity

low

Low

medium

Medium

important

High

critical

Critical

The Debian Oval database provides severity information.

Debian Severity	Clair Severity
*	Unknown
Unimportant	Low
Low	Medium
Medium	High
High	Critical

Debian Severity

Clair Severity

Unknown

Unimportant

Low

Medium

High

Critical

The Oracle Oval database provides severity information.

Oracle Severity	Clair Severity
N/A	Unknown
LOW	Low
MODERATE	Medium
IMPORTANT	High
CRITICAL	Critical

Oracle Severity

Clair Severity

N/A

Unknown

LOW

Low

MODERATE

Medium

IMPORTANT

High

CRITICAL

Critical

The RHEL Oval database provides severity information.

RHEL Severity	Clair Severity
None	Unknown
Low	Low
Moderate	Medium
Important	High
Critical	Critical

RHEL Severity

Clair Severity

None

Unknown

Low

Moderate

Medium

Important

High

Critical

The SUSE Oval database provides severity information.

Severity	Clair Severity
None	Unknown
Low	Low
Moderate	Medium
Important	High
Critical	Critical

Severity

Clair Severity

None

Unknown

Low

Moderate

Medium

Important

High

Critical

The Ubuntu Oval database provides severity information.

Severity	Clair Severity
Untriaged	Unknown
Negligible	Negligible
Low	Low
Medium	Medium
High	High
Critical	Critical

Severity

Clair Severity

Untriaged

Unknown

Negligible

Low

Medium

High

Critical

The following table shows how CVSSv3 base scores map to Clair severities:

Base Score	Clair Severity
0.0	Negligible
0.1-3.9	Low
4.0-6.9	Medium
7.0-8.9	High
9.0-10.0	Critical

The following table shows how CVSSv2 base scores map to Clair severities:

Base Score	Clair Severity
0.0-3.9	Low
4.0-6.9	Medium
7.0-10	High

Building container images

The Project Quay builds feature supports building Docker and Podman container images from Dockerfiles. You can create containerized applications by defining build contexts and using base images from public repositories.

Note	Because blueprints rely on images from other public repositories, they might be subject to rate limiting. Consequently, your build could fail.

Quay.io supports the ability to build Docker and Podman container images. This functionality is valuable for developers and organizations who rely on container and container orchestration.

On Quay.io, this feature works the same across both free, and paid, tier plans.

Note	Quay.io limits the number of simultaneous builds that a single user can submit at one time.

Build contexts

When building an image with Docker or Podman, a directory is specified to become the build context. This is true for both manual Builds and Build triggers, because the Build that is created by Quay.io is not different than running docker build or podman build on your local machine.

Quay.io Build contexts are always specified in the subdirectory from the Build setup, and fallback to the root of the Build source if a directory is not specified.

When a build is triggered, Quay.io Build workers clone the Git repository to the worker machine, and then enter the Build context before conducting a Build.

For Builds based on .tar archives, Build workers extract the archive and enter the Build context. For example:

Extracted Build archive

example
├── .git
├── Dockerfile
├── file
└── subdir
    └── Dockerfile

Imagine that the Extracted Build archive is the directory structure got a Github repository called example. If no subdirectory is specified in the Build trigger setup, or when manually starting the Build, the Build operates in the example directory.

If a subdirectory is specified in the Build trigger setup, for example, subdir, only the Dockerfile within it is visible to the Build. This means that you cannot use the ADD command in the Dockerfile to add file, because it is outside of the Build context.

Unlike Docker Hub, the Dockerfile is part of the Build context on Quay.io. As a result, it must not appear in the .dockerignore file.

Tag naming for build triggers

Tag naming for build triggers in Project Quay lets you create custom tags using templates that include commit information such as SHA, branch name, author, and date. You can use these templates to automatically tag your built images with meaningful identifiers based on the Git commit that triggered the build.

One option is to include any string of characters assigned as a tag for each built image. Alternatively, you can use the following tag templates on the Configure Tagging section of the build trigger to tag images with information from each commit:

Configure Tagging

${commit}: Full SHA of the issued commit
${parsed_ref.branch}: Branch information (if available)
${parsed_ref.tag}: Tag information (if available)
${parsed_ref.remote}: The remote name
${commit_info.date}: Date when the commit was issued
${commit_info.author.username}: Username of the author of the commit
${commit_info.short_sha}: First 7 characters of the commit SHA
${committer.properties.username}: Username of the committer

This list is not complete, but does contain the most useful options for tagging purposes. You can find the complete tag template schema in the Project Quay source repository.

Additional resources

Skipping a source control-triggered build

You can skip source control-triggered builds in Project Quay by adding [skip build] or [build skip] to your commit message. This prevents the build system from automatically building images for commits that do not require new builds.

Starting a new build

Starting a build creates a container image from a Dockerfile in Project Quay. You can start builds manually by uploading a Dockerfile or automatically by using build triggers.

Prerequisites

You have navigated to the Builds page of your repository.

Procedure

On the Builds page, click Start New Build.
When prompted, click Upload Dockerfile to upload a Dockerfile or an archive that contains a Dockerfile at the root directory.
Click Start Build.
Note

Currently, users cannot specify the Docker build context when manually starting a build.

Currently, BitBucket is unsupported on the Project Quay v2 UI.
You are redirected to the build, which can be viewed in real-time. Wait for the Dockerfile build to be completed and pushed.
Optional. you can click Download Logs to download the logs, or Copy Logs to copy the logs.
Click the back button to return to the Repository Builds page, where you can view the build history.

Build triggers

Build triggers in Project Quay start container image builds automatically when you push changes to a connected Git repository. You can use GitHub, GitLab, or custom Git triggers to integrate source control events into your build workflow.

Creating a build trigger

To automate container image builds from your Git repositories, you can create a custom Git build trigger in Project Quay. Build triggers automatically build and push images when you push code to your Git repository.

Quay.io cannot automatically detect the proper Robot Account to use with the trigger. This must be done manually during the creation process.

The following steps can be replicated to create a build trigger using Github, Gitlab, or Bitbucket, however, you must configure the credentials for these services in your config.yaml file.

Note	If you want to use Github to create a build trigger, you must configure Github to be used with Project Quay by creating an OAuth application. For more information, see "Creating an OAuth application Github".

Procedure

Log in to your Project Quay registry.
In the navigation pane, click Repositories.
Click Create Repository.
Click the Builds tab.
On the Builds page, click Create Build Trigger.
Select the desired platform, for example, Github, Bitbucket, Gitlab, or use a custom Git repository. For this example, click Custom Git Repository Push.
Enter a custom Git repository name, for example, git@github.com:<username>/<repo>.git. Then, click Next.
When prompted, configure the tagging options by selecting one of, or both of, the following options:
- Tag manifest with the branch or tag name. When selecting this option, the built manifest the name of the branch or tag for the git commit are tagged.
- Add latest tag if on default branch. When selecting this option, the built manifest with latest if the build occurred on the default branch for the repository are tagged.
  
  Optionally, you can add a custom tagging template. There are multiple tag templates that you can enter here, including using short SHA IDs, timestamps, author names, committer, and branch names from the commit as tags. For more information, see "Tag naming for build triggers".
  
  After you have configured tagging, click Next.
When prompted, select the location of the Dockerfile to be built when the trigger is invoked. If the Dockerfile is located at the root of the git repository and named Dockerfile, enter /Dockerfile as the Dockerfile path. Then, click Next.
When prompted, select the context for the Docker build. If the Dockerfile is located at the root of the Git repository, enter / as the build context directory. Then, click Next.
Optional. Choose an optional robot account. This allows you to pull a private base image during the build process. If you know that a private base image is not used, you can skip this step.
Click Next. Check for any verification warnings. If necessary, fix the issues before clicking Finish.
You are alerted that the trigger has been successfully activated. Note that using this trigger requires the following actions:
- You must give the following public key read access to the git repository.
- You must set your repository to POST to the following URL to trigger a build.
  
  Save the SSH Public Key, then click Return to <organization_name>/<repository_name>. You are redirected to the Builds page of your repository.
On the Builds page, you now have a build trigger. For example:

After you have created a custom Git trigger, additional steps are required. Continue on to "Setting up a custom Git trigger".

If you are setting up a build trigger for Github, Gitlab, or Bitbucket, continue on to "Manually triggering a build".

Manually triggering a build

Manual build triggering in Project Quay lets you start builds on demand without waiting for automatic triggers from source control. You can manually trigger builds from the Builds page by selecting a build trigger and specifying a commit ID.

Procedure

On the Builds page, Start new build.
When prompted, select Invoke Build Trigger.
Click Run Trigger Now to manually start the process.
Enter a commit ID from which to initiate the build, for example, 1c002dd.

After the build starts, you can see the build ID on the Repository Builds page.

Setting up a custom Git trigger

To complete the setup of your custom Git build trigger in Project Quay, you must provide read access to the SSH public key and configure a webhook endpoint. These steps enable your Git repository to automatically trigger builds when you push code.

These steps are only required if you are using a custom Git trigger.

Notifications overview

Notifications in Project Quay alert you about repository events such as pushes, builds, and image expiry. You can configure delivery methods for users, teams, or organizations.

Note	By default, vulnerability notifications are disabled on Quay.io and cannot be enabled.

Notification actions

Notification actions in Project Quay define how event alerts are delivered. You can send notices by email, webhook, Flowdock, HipChat, or Slack.

Notifications are added to the Events and Notifications section of the Repository Settings page. They are also added to the Notifications window, which can be found by clicking the bell icon in the navigation pane of Quay.io.

Quay.io notifications can be setup to be sent to a User, Team, or the entire organization.

Notifications can be delivered by one of the following methods.

E-mail notifications

E-mails are sent to specified addresses that describe the specified event. E-mail addresses must be verified on a per-repository basis.

Webhook POST notifications

An HTTP POST call is made to the specified URL with the event’s data. For more information about event data, see "Repository events description".

When the URL is HTTPS, the call has an SSL client certificate set from Quay.io. Verification of this certificate proves that the call originated from Quay.io. Responses with the status code in the 2xx range are considered successful. Responses with any other status code are considered failures and result in a retry of the webhook notification.

Flowdock notifications

Posts a message to Flowdock.

Hipchat notifications

Posts a message to HipChat.

Slack notifications

Posts a message to Slack.

Creating notifications by using the UI

To alert users to repository events such as pushes or build failures, you can create a notification from the Settings page in the Project Quay v2 UI. You select an event trigger and a delivery method, such as email or Slack.

Prerequisites

You have created a repository.
You have administrative privileges for the repository.

Procedure

Navigate to a repository on Quay.io.
In the navigation pane, click Settings.
In the Events and Notifications category, click Create Notification to add a new notification for a repository event. The Create notification popup box appears.
On the Create repository popup box, click the When this event occurs box to select an event. You can select a notification for the following types of events:
- Push to Repository
- Image build failed
- Image build queued
- Image build started
- Image build success
- Image build cancelled
- Image expiry trigger
After you have selected the event type, select the notification method. The following methods are supported:
- Quay Notification
- E-mail Notification
- Webhook POST
- Flowdock Team Notification
- HipChat Room Notification
- Slack Notification
  
  Depending on the method that you choose, you must include additional information. For example, if you select E-mail, you are required to include an e-mail address and an optional notification title.
After selecting an event and notification method, click Create Notification.

Creating an image expiration notification

To create an image expiration notification in Project Quay, you can use the v2 UI or the API. You set how many days before expiry to send the alert.

Triggers can work in conjunction with the auto-pruning feature. You can also create this notification by using the createRepoNotification API endpoint.

Prerequisites

FEATURE_GARBAGE_COLLECTION: true is set in your config.yaml file.
Optional. FEATURE_AUTO_PRUNE: true is set in your config.yaml file.

Procedure

On the Project Quay v2 UI, click Repositories.
Select the name of a repository.
Click Settings → Events and notifications.
Click Create notification. The Create notification popup box appears.
Click the Select event… box, then click Image expiry trigger.
In the When the image is due to expiry in days box, enter the number of days before the image’s expiration when you want to receive an alert. For example, use 1 for 1 day.
In the Select method… box, click one of the following:
- E-mail
- Webhook POST
- Flowdock Team Notification
- HipChat Room Notification
- Slack Notification
Depending on which method you chose, include the necessary data. For example, if you chose Webhook POST, include the Webhook URL.
Optional. Provide a POST JSON body template.
Optional. Provide a Title for your notification.
Click Submit. You are returned to the Events and notifications page, and the notification now appears.
Optional. You can set the NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES variable in your config.yaml file. with this field set, if there are any expiring images notifications will be sent automatically. By default, this is set to 300, or 5 hours, however it can be adjusted as warranted.
```
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300
```
where:

NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES

Specifies that by default, this field is set to 300, or 5 hours.

Verification

Click the menu kebab → Test Notification. The following message is returned:

Test Notification Queued
A test version of this notification has been queued and should appear shortly

Depending on which method you chose, check your e-mail, webhook address, Slack channel, and so on. The information sent should look similar to the following example:

{
  "repository": "sample_org/busybox",
  "namespace": "sample_org",
  "name": "busybox",
  "docker_url": "quay-server.example.com/sample_org/busybox",
  "homepage": "http://quay-server.example.com/repository/sample_org/busybox",
  "tags": [
    "latest",
    "v1"
  ],
  "expiring_in": "1 days"
}

Creating notifications by using the API

To create repository notifications in Project Quay, you can use the API. You define the event type, delivery method, and related configuration.

Prerequisites

You have created a repository.
You have administrative privileges for the repository.
You have Created an OAuth access token.

Procedure

Enter the following POST /api/v1/repository/{repository}/notification command to create a notification on your repository:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  -H "Content-Type: application/json" \
  --data '{
    "event": "<event>",
    "method": "<method>",
    "config": {
      "<config_key>": "<config_value>"
    },
    "eventConfig": {
      "<eventConfig_key>": "<eventConfig_value>"
    }
  }' \
  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/

This command does not return output in the CLI. Instead, you can enter the following GET /api/v1/repository/{repository}/notification/{uuid} command to obtain information about the repository notification:

{"uuid": "240662ea-597b-499d-98bb-2b57e73408d6", "title": null, "event": "repo_push", "method": "quay_notification", "config": {"target": {"name": "quayadmin", "kind": "user", "is_robot": false, "avatar": {"name": "quayadmin", "hash": "b28d563a6dc76b4431fc7b0524bbff6b810387dac86d9303874871839859c7cc", "color": "#17becf", "kind": "user"}}}, "event_config": {}, "number_of_failures": 0}

You can test your repository notification by entering the following POST /api/v1/repository/{repository}/notification/{uuid}/test command:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>/test

Example output

{}

You can reset repository notification failures to 0 by entering the following POST /api/v1/repository/{repository}/notification/{uuid} command:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>

Enter the following DELETE /api/v1/repository/{repository}/notification/{uuid} command to delete a repository notification:

$ curl -X DELETE \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/<uuid>

This command does not return output in the CLI. Instead, you can enter the following GET /api/v1/repository/{repository}/notification/ command to retrieve a list of all notifications:

$ curl -X GET  -H "Authorization: Bearer <bearer_token>"   -H "Accept: application/json"  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification

Example output

{"notifications": []}

Repository events description

Repository events in Project Quay describe the triggers that can generate notifications. You can use these event types when you configure alerts.

Repository Push

A successful push of one or more images was made to the repository:

{
  "name": "repository",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "homepage": "https://quay.io/repository/dgangaia/repository",
  "updated_tags": [
    "latest"
  ]
}

Dockerfile Build Queued

The following example is a response from a Dockerfile Build that has been queued into the Build system.

Note	Responses can differ based on the use of optional attributes.

{
  "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "repo": "test",
  "trigger_metadata": {
    "default_branch": "master",
    "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
    "ref": "refs/heads/master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                             //Optional
      "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
      "date": "2019-03-06T12:48:24+11:00",
      "message": "adding 5",
      "author": {                                                                //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                    //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"    //Optional
      },
      "committer": {
        "username": "web-flow",
        "url": "https://github.com/web-flow",
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
      }
    }
  },
  "is_manual": false,
  "manual_user": null,
  "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2"
}

Dockerfile Build started

The following example is a response from a Dockerfile Build that has been queued into the Build system.

Note	Responses can differ based on the use of optional attributes.

{
  "build_id": "a8cc247a-a662-4fee-8dcb-7d7e822b71ba",
  "trigger_kind": "github",                                                     //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                         //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "50bc599",
  "trigger_metadata": {                                                         //Optional
    "commit": "50bc5996d4587fd4b2d8edc4af652d4cec293c42",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                            //Optional
      "url": "https://github.com/dgangaia/test/commit/50bc5996d4587fd4b2d8edc4af652d4cec293c42",
      "date": "2019-03-06T14:10:14+11:00",
      "message": "test build",
      "committer": {                                                            //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                   //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"   //Optional
      },
      "author": {                                                               //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                   //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"   //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/a8cc247a-a662-4fee-8dcb-7d7e822b71ba"
}

Dockerfile Build successfully completed

The following example is a response from a Dockerfile Build that has been successfully completed by the Build system.

Note	This event occurs simultaneously with a Repository Push event for the built image or images.

{
  "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "b7f7d2b",
  "image_id": "sha256:0339f178f26ae24930e9ad32751d6839015109eabdf1c25b3b0f2abf8934f6cb",
  "trigger_metadata": {
    "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                              //Optional
      "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
      "date": "2019-03-06T12:48:24+11:00",
      "message": "adding 5",
      "committer": {                                                              //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                     //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"                                                        //Optional
      },
      "author": {                                                                 //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                     //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"     //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2",
  "manifest_digests": [
    "quay.io/dgangaia/test@sha256:2a7af5265344cc3704d5d47c4604b1efcbd227a7a6a6ff73d6e4e08a27fd7d99",
    "quay.io/dgangaia/test@sha256:569e7db1a867069835e8e97d50c96eccafde65f08ea3e0d5debaf16e2545d9d1"
  ]
}

Dockerfile Build failed

The following example is a response from a Dockerfile Build that has failed.

{
  "build_id": "5346a21d-3434-4764-85be-5be1296f293c",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "docker_url": "quay.io/dgangaia/test",
  "error_message": "Could not find or parse Dockerfile: unknown instruction: GIT",
  "namespace": "dgangaia",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "6ae9a86",
  "trigger_metadata": {                                                           //Optional
    "commit": "6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                              //Optional
      "url": "https://github.com/dgangaia/test/commit/6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
      "date": "2019-03-06T14:18:16+11:00",
      "message": "failed build test",
      "committer": {                                                              //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                     //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"     //Optional
      },
      "author": {                                                                 //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                     //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"     //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/5346a21d-3434-4764-85be-5be1296f293c"
}

Dockerfile Build cancelled

The following example is a response from a Dockerfile Build that has been cancelled.

{
  "build_id": "cbd534c5-f1c0-4816-b4e3-55446b851e70",
  "trigger_kind": "github",
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "cbce83c",
  "trigger_metadata": {
    "commit": "cbce83c04bfb59734fc42a83aab738704ba7ec41",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {
      "url": "https://github.com/dgangaia/test/commit/cbce83c04bfb59734fc42a83aab738704ba7ec41",
      "date": "2019-03-06T14:27:53+11:00",
      "message": "testing cancel build",
      "committer": {
        "username": "web-flow",
        "url": "https://github.com/web-flow",
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
      },
      "author": {
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/cbd534c5-f1c0-4816-b4e3-55446b851e70"
}

Open Container Initiative support

Project Quay supports Open Container Initiative image and distribution formats beyond Docker manifests. You can store Helm charts and other OCI media types in the registry.

In addition to container images, a variety of artifacts have emerged that support not just individual applications, but also the Kubernetes platform as a whole. These range from Open Policy Agent (OPA) policies for security and governance to Helm charts and Operators that aid in application deployment.

Quay.io is a private container registry that not only stores container images, but also supports an entire ecosystem of tooling to aid in the management of containers. Quay.io strives to be as compatible as possible with the OCI 1.1 Image and Distribution specifications, and supports common media types like Helm charts (as long as they pushed with a version of Helm that supports OCI) and a variety of arbitrary media types within the manifest or layer components of container images. Support for OCI media types differs from previous iterations of Quay.io, when the registry was more strict about accepted media types. Because Quay.io now works with a wider array of media types, including those that were previously outside the scope of its support, it is now more versatile accommodating not only standard container image formats but also emerging or unconventional types.

In addition to its expanded support for novel media types, Quay.io ensures compatibility with Docker images, including V2_2 and V2_1 formats. This compatibility with Docker V2_2 and V2_1 images demonstrates Quay.io’s commitment to providing a seamless experience for Docker users. Moreover, Quay.io continues to extend its support for Docker V1 pulls, catering to users who might still rely on this earlier version of Docker images.

Support for OCI artifacts are enabled by default. The following examples show you how to use some media types, which can be used as examples for using other OCI media types.

Additional resources

Helm and OCI prerequisites

Before you use Helm charts with Project Quay, you can install a supported Helm client and trust registry certificates. OCI chart support requires a compatible Helm version.

Helm simplifies how applications are packaged and deployed. Helm uses a packaging format called Charts which contain the Kubernetes resources representing an application. Quay.io supports Helm charts so long as they are a version supported by OCI.

You can download the most recent version of Helm from the Helm releases page.

Additional resources

Helm releases

Using Helm charts

To use Helm charts with Project Quay, you can push and pull OCI chart artifacts in the registry. You manage charts like other supported OCI media types.

Use the following example to download and push an etherpad chart from the Red Hat Community of Practice (CoP) repository.

Prerequisites

You have logged into Quay.io.

Procedure

Add a chart repository by entering the following command:

$ helm repo add redhat-cop https://redhat-cop.github.io/helm-charts

Enter the following command to update the information of available charts locally from the chart repository:
```
$ helm repo update
```
Enter the following command to pull a chart from a repository:
```
$ helm pull redhat-cop/etherpad --version=0.0.4 --untar
```

Enter the following command to package the chart into a chart archive:

$ helm package ./etherpad

Example output

Successfully packaged chart and saved it to: /home/user/linux-amd64/etherpad-0.0.4.tgz

Push the chart to your repository using the helm push command:

helm push etherpad-0.0.4.tgz oci://quay.io/<organization_name>/helm

Example output:

Pushed: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4
Digest: sha256:a6667ff2a0e2bd7aa4813db9ac854b5124ff1c458d170b70c2d2375325f2451b

Ensure that the push worked by deleting the local copy, and then pulling the chart from the repository:

$ rm -rf etherpad-0.0.4.tgz

$ helm pull oci://quay.io/<organization_name>/helm/etherpad --version 0.0.4

Example output:

Pulled: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4
Digest: sha256:4f627399685880daf30cf77b6026dc129034d68c7676c7e07020b70cf7130902

Cosign OCI support

Cosign signs and verifies container images with public and private keys. You can install Cosign and use it with images stored in Project Quay.

Cosign is a tool that can be used to sign and verify container images. It uses the ECDSA-P256 signature algorithm and Red Hat’s Simple Signing payload format to create public keys that are stored in PKIX files. Private keys are stored as encrypted PEM files.

Cosign currently supports the following:

Hardware and KMS Signing
Bring-your-own PKI
OIDC PKI
Built-in binary transparency and timestamping service

Use the following procedure to directly install Cosign.

Prerequisites

You have installed Go version 1.16 or later.

Procedure

Enter the following go command to directly install Cosign:

$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0

Example output

go: downloading github.com/sigstore/cosign v1.0.0
go: downloading github.com/peterbourgon/ff/v3 v3.1.0

Generate a key-value pair for Cosign by entering the following command:

$ cosign generate-key-pair

Example output

Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

Sign the key-value pair by entering the following command:
```
$ cosign sign -key cosign.key quay.io/user1/busybox:test
```
Example output
```
Enter password for private key:
Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig
```
If you experience an UNAUTHORIZED: access to the requested resource is not authorized error when signing, which occurs because Cosign relies on ~./docker/config.json for authorization, you might need to execute the following command:
```
$ podman login --authfile ~/.docker/config.json quay.io
```
Example output
```
Username:
Password:
Login Succeeded!
```

Enter the following command to see the updated authorization configuration:

$ cat ~/.docker/config.json
{
	"auths": {
		"quay-server.example.com": {
			"auth": "cXVheWFkbWluOnBhc3N3b3Jk"
		}
	}

Installing and using Cosign

To sign and verify images in Project Quay with Cosign, you can install the tool and authenticate to the registry. You generate keys, sign tags, and verify signatures.

Prerequisites

You have installed Go version 1.16 or later.
You have set FEATURE_GENERAL_OCI_SUPPORT to True in your config.yaml file.

Procedure

Enter the following go command to directly install Cosign:

$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0

Example output

go: downloading github.com/sigstore/cosign v1.0.0
go: downloading github.com/peterbourgon/ff/v3 v3.1.0

Generate a key-value pair for Cosign by entering the following command:

$ cosign generate-key-pair

Example output

Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

Sign the key-value pair by entering the following command:
```
$ cosign sign -key cosign.key quay.io/user1/busybox:test
```
Example output
```
Enter password for private key:
Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig
```
If you experience an UNAUTHORIZED: access to the requested resource is not authorized error when signing, which occurs because Cosign relies on ~./docker/config.json for authorization, you might need to execute the following command:
```
$ podman login --authfile ~/.docker/config.json quay.io
```
Example output
```
Username:
Password:
Login Succeeded!
```

Enter the following command to see the updated authorization configuration:

$ cat ~/.docker/config.json
{
	"auths": {
		"quay-server.example.com": {
			"auth": "cXVheWFkbWluOnBhc3N3b3Jk"
		}
	}