Proof of Concept - Deploying Project Quay

Project Quay is an enterprise-quality registry for building, securing and serving container images. The documents in this section detail how to deploy Project Quay for proof of concept, or non-production, purposes.

Important

The following proof of concept deployment method is unsupported for production purposes. This deployment type uses local storage. Local storage is not guaranteed to provide the required read-after-write consistency and data integrity guarantees during parallel access that a storage registry like Project Quay requires. Do not use this deployment type for production purposes. Use it for testing purposes only.

The primary objectives of this document includes the following:

How to deploy Project Quay for basic non-production purposes.
Asses Project Quay’s container image management, including how to push, pull, tag, and organize images.
Explore availability and scalability.
How to deploy an advanced Project Quay proof of concept deployment using SSL/TLS certificates.

Beyond the primary objectives of this document, a proof of concept deployment can be used to test various features offered by Project Quay, such as establishing superusers, setting repository quota limitations, enabling Splunk for action log storage, enabling Clair for vulnerability reporting, and more. See the "Next steps" section for a list of some of the features available after you have followed this guide.

This proof of concept deployment procedure can be followed on a single machine, either physical or virtual.

Prerequisites

Before you deploy a proof of concept Project Quay registry, ensure your host meets minimum hardware requirements and you have Red Hat Enterprise Linux (RHEL) 9 with an active subscription. You also need Podman for running containers in this guide.

Two or more virtual CPUs
4 GB or more of RAM
Approximately 30 GB of disk space on your test system, which can be broken down as follows:
- Approximately 10 GB of disk space for the Red Hat Enterprise Linux (RHEL) operating system.
- Approximately 10 GB of disk space for Docker storage for running three containers.
- Approximately 10 GB of disk space for Project Quay local storage.
  
  Note
  
  CEPH or other local storage might require more memory.
  
  See the Quay 3.x sizing guidelines for more information on sizing.
The following architectures are supported for Project Quay:
- amd64/x86_64
- s390x
- ppc64le

Additional resources

Installing Podman

To install Podman on Red Hat Enterprise Linux (RHEL) for a proof of concept Project Quay deployment, you can use yum to install the podman package or the container-tools module. Podman is required for running registry containers in this guide.

This document uses Podman for creating and deploying containers.

Important

If you do not have Podman installed on your system, the use of equivalent Docker commands might be possible, however this is not recommended. Docker is not tested with Project Quay 3.18, and will be deprecated in a future release. Podman is recommended for highly available, production quality deployments of Project Quay 3.18.

Procedure

Enter the following command to install Podman:
```
$ sudo yum install -y podman
```
Alternatively, install the container-tools module, which pulls in the full set of container software packages:
```
$ sudo yum module install -y container-tools
```

Additional resources

Building, running, and managing Linux containers on Red Hat Enterprise Linux 9

Preparing Red Hat Enterprise Linux for a Project Quay proof of concept deployment

Preparing Red Hat Enterprise Linux (RHEL) for a Project Quay proof of concept deployment includes server registration, registry authentication, firewall rules, and network addressing. You can complete these host configuration tasks before deploying the registry container.

Install and register the RHEL server

To prepare Red Hat Enterprise Linux (RHEL) for a proof of concept Project Quay deployment, you can install RHEL 9, register the system, and attach a subscription. You can then update to the latest packages before deploying components.

Procedure

Install the latest RHEL 9 server. You can do a minimal, shell-access only install, or Server plus GUI if you want a desktop.
Register and subscribe your RHEL server system as described in How to register and subscribe a RHEL system to the Red Hat Customer Portal using Red Hat Subscription-Manager

Enter the following commands to register your system and list available subscriptions. Choose an available RHEL server subscription, attach to its pool ID, and upgrade to the latest software:

# subscription-manager register --username=<user_name> --password=<password>
# subscription-manager refresh
# subscription-manager list --available
# subscription-manager attach --pool=<pool_id>
# yum update -y

Registry authentication

To pull Project Quay container images for a proof of concept deployment, you can authenticate to registry.redhat.io and log in with Podman. Images are hosted on the Red Hat container registry rather than Quay.io.

Procedure

Configure authentication to registry.redhat.io by following the Red Hat Container Registry Authentication procedure. Configuring authentication allows you to pull the Quay container.

Note

This differs from earlier versions of Project Quay, when the images were hosted on Quay.io.
Enter the following command to log in to the registry:
```
$ sudo podman login registry.redhat.io
```
You are prompted to enter your username and password.

Firewall configuration

To allow network access to your proof of concept Project Quay deployment, you can open firewall ports that match your container port mappings. The required ports depend on which services you expose on the host.

If you have a firewall running on your system, you might have to add rules that allow access to Project Quay.

Procedure

Enter firewall commands for the ports that you have mapped on your system, for example:

# firewall-cmd --permanent --add-port=80/tcp \
&& firewall-cmd --permanent --add-port=443/tcp \
&& firewall-cmd --permanent --add-port=5432/tcp \
&& firewall-cmd --permanent --add-port=5433/tcp \
&& firewall-cmd --permanent --add-port=6379/tcp \
&& firewall-cmd --reload

IP addressing and naming services for a proof of concept deployment

Container networking for a proof of concept Project Quay deployment can use naming services, host networking, or port mapping. This guide uses port mapping with a static host IP address.

You can configure the component containers in Project Quay to communicate with each other in several ways, for example:

Using a naming service. If you want your deployment to survive container restarts, which typically result in changed IP addresses, you can implement a naming service. For example, the dnsname plugin allows containers to resolve each other by name.
Using the host network. You can use the podman run command with the --net=host option and then use container ports on the host when specifying the addresses in the configuration. This option is susceptible to port conflicts when two containers want to use the same port. This method is not recommended.
Configuring port mapping. You can use port mappings to expose ports on the host and then use these ports in combination with the host IP address or host name.

This document uses port mapping and assumes a static IP address for your host system.

Table 1. Sample proof of concept port mapping
Component	Port mapping	Address
Quay	`-p 80:8080` `-p 443:8443`	http://quay-server.example.com
Postgres for Quay	`-p 5432:5432`	quay-server.example.com:5432
Redis	`-p 6379:6379`	quay-server.example.com:6379
Postgres for Clair V4	`-p 5433:5432`	quay-server.example.com:5433
Clair V4	`-p 8081:8080`	http://quay-server.example.com:8081

Additional resources

dnsname

Preparing your system to deploy Project Quay

For a proof of concept Project Quay deployment, you must configure port mapping, a database, and Redis prior to deploying the registry.

Configuring port mapping for Project Quay

To reach your proof of concept Project Quay registry by hostname, you can map container ports on the host and add a static IP and hostname to /etc/hosts.

You can use port mappings to expose ports on the host and then use these ports in combination with the host IP address or host name to navigate to the Project Quay endpoint.

Procedure

Enter the following command to obtain your static IP address for your host system:

$ ip a

Example output

---
    link/ether 6c:6a:77:eb:09:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.132/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp82s0
---

Add the IP address and a local hostname, for example, quay-server.example.com to your /etc/hosts file that you use to reach the Project Quay endpoint. You can confirm that the IP address and hostname have been added to the /etc/hosts file by entering the following command:
```
$ cat /etc/hosts
```
Example output
```
192.168.1.132 quay-server.example.com
```

Configuring the database

Project Quay requires a database for storing metadata. PostgreSQL is used throughout this document. To configure the database for your proof of concept Project Quay deployment, you can create a local PostgreSQL data directory and start a Postgres container with Podman. You must also install the pg_trgm extension required by the registry.

Procedure

In the installation folder, denoted here by the $QUAY variable, create a directory for the database data by entering the following command:
```
$ mkdir -p $QUAY/postgres-quay
```
Set the appropriate permissions by entering the following command:
```
$ setfacl -m u:26:-wx $QUAY/postgres-quay
```

Start the Postgres container, specifying the username, password, and database name and port, with the volume definition for database data:

$ sudo podman run -d --rm --name postgresql-quay \
  -e POSTGRESQL_USER=quayuser \
  -e POSTGRESQL_PASSWORD=quaypass \
  -e POSTGRESQL_DATABASE=quay \
  -e POSTGRESQL_ADMIN_PASSWORD=adminpass \
  -p 5432:5432 \
  -v $QUAY/postgres-quay:/var/lib/pgsql/data:Z \
  centos/postgresql-10-centos7@sha256:de1560cb35e5ec643e7b3a772ebaac8e3a7a2a8e8271d9e91ff023539b4dfb33

Ensure that the Postgres pg_trgm module is installed by running the following command:
```
$ sudo podman exec -it postgresql-quay /bin/bash -c 'echo "CREATE EXTENSION IF NOT EXISTS pg_trgm" | psql -d quay -U postgres'
```
Note

The pg_trgm module is required for the Quay container.

Configuring Redis

To configure Redis for your proof of concept Project Quay deployment, you can start a Redis container with Podman and expose port 6379 with a password. Project Quay uses Redis for live builder logs during image builds.

Redis is a key-value store that is used by Project Quay for live builder logs.

Procedure

Start the Redis container, specifying the port and password, by entering the following command:

$ sudo podman run -d --rm --name redis \
  -p 6379:6379 \
  -e REDIS_PASSWORD=strongpassword \
  centos/redis-32-centos7@sha256:06dbb609484330ec6be6090109f1fa16e936afcf975d1cbc5fff3e6c7cae7542

Deploying Project Quay

To deploy your proof of concept Project Quay registry, you can create a config.yaml file, prepare local storage for images, and start the registry container with Podman. You can optionally configure a superuser account during setup.

Preparing the YAML configuration file by using the CLI

To prepare your proof of concept Project Quay deployment for launch, you can create a config.yaml file with database, Redis, and storage settings and copy it to your configuration directory. You can use the CLI to build the configuration bundle that the registry container reads at startup.

Procedure

Enter the following command to create a minimal config.yaml file that is used to deploy the Project Quay container:
```
$ touch config.yaml
```

Copy and paste the following YAML configuration into the config.yaml file:

BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379
CREATE_NAMESPACE_ON_PUSH: true
DATABASE_SECRET_KEY: a8c2744b-7004-4af2-bcee-e417e7bdd235
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - LocalStorage
        - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
FEATURE_MAILING: false
SECRET_KEY: e9bd34f4-900c-436a-979e-7530e5d74ac8
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
USER_EVENTS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379

Create a directory to copy the Project Quay configuration bundle to:
```
$ mkdir $QUAY/config
```
Copy the Project Quay configuration file to the directory:
```
$ cp -v config.yaml $QUAY/config
```

Configuring a Project Quay superuser

To configure a superuser account for your proof of concept Project Quay deployment, you can add the SUPER_USERS array to config.yaml. Superusers can manage users, organizations, service keys, and global settings from the admin panel.

Procedure

Add the SUPER_USERS array to the config.yaml file:

SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
SUPER_USERS:
  - quayadmin
...

Preparing local storage for image data

To prepare local storage for your proof of concept Project Quay deployment, you can create a directory for registry images and set file system permissions for the registry user. Local storage lets the registry container persist image data on the host.

Procedure

Create a local directory that stores registry images by entering the following command:
```
$ mkdir $QUAY/storage
```
Set the directory to store registry images:
```
$ setfacl -m u:1001:-wx $QUAY/storage
```

Deploy the Project Quay registry by using the CLI

To deploy your proof of concept Project Quay registry, you can start the registry container with Podman.

Procedure

Enter the following command to start the Quay registry container, specifying the appropriate volumes for configuration data and local storage for image data:

$ sudo podman run -d --rm -p 80:8080 -p 443:8443  \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   quay.io/projectquay/quay:v3.18.0

Using Project Quay

To use your proof of concept Project Quay deployment, you can create a user account in the web UI, log in from the CLI, and push and pull container images. You can also access the superuser admin panel if you configured a superuser in config.yaml.

Procedure

Use your browser to access the user interface for the Project Quay registry at http://quay-server.example.com, assuming you have configured quay-server.example.com as your hostname in your /etc/hosts file and in your config.yaml file.
Click Create Account and add a user, for example, quayadmin with a password password.

From the command line, log in to the registry:

$ sudo podman login --tls-verify=false quay-server.example.com

Example output

Username: quayadmin
Password: password
Login Succeeded!

To test pushing and pulling images from the Project Quay registry, first pull a sample image from an external registry:

$ sudo 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

Enter the following command to see the local copy of the image:

$ sudo podman images

Example output

REPOSITORY                          TAG      IMAGE ID       CREATED         SIZE
docker.io/library/busybox           latest   22667f53682a   14 hours ago    1.45 MB

Enter the following command to tag this image, which prepares the image for pushing it to the registry:
```
$ sudo podman tag docker.io/library/busybox quay-server.example.com/quayadmin/busybox:test
```

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

$ sudo podman push --tls-verify=false quay-server.example.com/quayadmin/busybox:test

Example output

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

To test access to the image from the command line, first delete the local copy of the image:

$ sudo podman rmi quay-server.example.com/quayadmin/busybox:test

Example output

Untagged: quay-server.example.com/quayadmin/busybox:test

Pull the image from your Project Quay registry by entering the following command:

$ sudo podman pull --tls-verify=false quay-server.example.com/quayadmin/busybox:test

Example output

Trying to pull quay-server.example.com/quayadmin/busybox:test...
Getting image source signatures
Copying blob 6ef22a7134ba [--------------------------------------] 0.0b / 0.0b
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures
22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

If you added a superuser to your config.yaml file, access the Superuser Admin Panel on the Project Quay UI by clicking on the current user’s name or avatar in the navigation pane of the UI. Then, click Superuser Admin Panel.

On this page, you can manage users, your organization, service keys, view change logs, view usage logs, and create global messages for your organization.

Proof of concept deployment using SSL/TLS certificates

To secure a proof of concept Project Quay deployment with SSL/TLS, you can create certificates, configure your registry, and test secure connections. You can also add the certificate authority to system or Podman trust stores.

Using SSL/TLS

Documentation for Using SSL/TLS has been revised and moved to Securing Project Quay. This chapter will be removed in a future version of Project Quay.

Creating a Certificate Authority

To secure your Project Quay deployment with self-signed certificates, you can create a root certificate authority and generate a server certificate for your registry hostname. You can use OpenSSL to create the CA key, signing request, and certificate files.

Procedure

Generate the root CA key by entering the following command:
```
$ openssl genrsa -out rootCA.key 2048
```

Generate the root CA certificate by entering the following command:

$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Enter the information to incorporate into your certificate request, including the server hostname, for example:

Country Name (2 letter code) [XX]:IE
State or Province Name (full name) []:GALWAY
Locality Name (eg, city) [Default City]:GALWAY
Organization Name (eg, company) [Default Company Ltd]:QUAY
Organizational Unit Name (eg, section) []:DOCS
Common Name (eg, your name or your server's hostname) []:quay-server.example.com

Generate the server key by entering the following command:
```
$ openssl genrsa -out ssl.key 2048
```
Generate a signing request by entering the following command:
```
$ openssl req -new -key ssl.key -out ssl.csr
```

Enter the information to incorporate into your certificate request, including the server hostname, for example:

Country Name (2 letter code) [XX]:IE
State or Province Name (full name) []:GALWAY
Locality Name (eg, city) [Default City]:GALWAY
Organization Name (eg, company) [Default Company Ltd]:QUAY
Organizational Unit Name (eg, section) []:DOCS
Common Name (eg, your name or your server's hostname) []:quay-server.example.com
Email Address []:

Create a configuration file openssl.cnf, specifying the server hostname, for example:

Example openssl.cnf file

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = <quay-server.example.com>
IP.1 = 192.168.1.112

Use the configuration file to generate the certificate ssl.cert:

$ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf

Confirm your created certificates and files by entering the following command:

$ ls /path/to/certificates

Example output

rootCA.key ssl-bundle.cert ssl.key custom-ssl-config-bundle-secret.yaml rootCA.pem ssl.cert
openssl.cnf rootCA.srl  ssl.csr

Configuring SSL/TLS for standalone Project Quay deployments

For standalone Project Quay deployments, you configure SSL/TLS certificates by using the CLI and updating config.yaml manually. Child procedures in this section cover certificate creation, configuration, testing, and trust setup.

Configuring custom SSL/TLS certificates by using the command line interface

To enable custom SSL/TLS certificates on your Project Quay deployment, you can copy certificate files to your configuration directory and update the config.yaml file to use HTTPS. You can then restart the registry container to apply the SSL/TLS configuration.

Prerequisites

You have created a certificate authority and signed the certificate.

Procedure

Copy the certificate file and primary key file to your configuration directory, ensuring they are named ssl.cert and ssl.key respectively:
```
cp ~/ssl.cert ~/ssl.key /path/to/configuration_directory
```
Navigate to the configuration directory by entering the following command:
```
$ cd /path/to/configuration_directory
```
Edit the config.yaml file and specify that you want Project Quay to handle SSL/TLS:
Example config.yaml file
```
# ...
SERVER_HOSTNAME: <quay-server.example.com>
...
PREFERRED_URL_SCHEME: https
# ...
```
Optional: Append the contents of the rootCA.pem file to the end of the ssl.cert file by entering the following command:
```
$ cat rootCA.pem >> ssl.cert
```
Stop the Quay container by entering the following command:
```
$ sudo podman stop <quay_container_name>
```

Restart the registry by entering the following command:

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
  --name=quay \
  -v $QUAY/config:/conf/stack:Z \
  -v $QUAY/storage:/datastorage:Z \
  quay.io/projectquay/quay:v3.18.0

Testing the SSL/TLS configuration

SSL/TLS testing confirms that your Project Quay registry serves encrypted connections after you configure certificates. You can verify the setup from the CLI or a web browser before you add the certificate authority to client trust stores.

Testing the SSL/TLS configuration using the CLI

To test your SSL/TLS configuration from the CLI, you can use podman login against your Project Quay registry endpoint and review the certificate error for a self-signed authority. You can then log in with the --tls-verify=false option before configuring Podman to trust the certificate authority.

Procedure

Enter the following command to attempt to log in to the Project Quay registry with SSL/TLS enabled:

$ sudo podman login quay-server.example.com

Example output

Error: error authenticating creds for "quay-server.example.com": error pinging docker registry quay-server.example.com: Get "https://quay-server.example.com/v2/": x509: certificate signed by unknown authority

Because Podman does not trust self-signed certificates, you must use the --tls-verify=false option:
```
$ sudo podman login --tls-verify=false quay-server.example.com
```
Example output
```
Login Succeeded!
```

Testing the SSL/TLS configuration using a browser

To test your SSL/TLS configuration in a browser, you can open your Project Quay registry endpoint and review the connection warnings for a self-signed certificate. Expected browser warnings confirm that TLS is active before you trust the certificate authority on clients.

Procedure

Navigate to your Project Quay registry endpoint, for example, https://quay-server.example.com. If configured correctly, the browser warns of the potential risk:
Proceed to the log in screen. The browser notifies you that the connection is not secure. For example:

In the following section, you configure Podman to trust the root Certificate Authority.

Configuring Podman to trust the Certificate Authority

To configure Podman to trust your self-signed certificate authority for Project Quay, you can copy the root CA to the hostname-specific certificate directory under /etc/containers/certs.d/ or /etc/docker/certs.d/. You can verify the setup by logging in to your registry without the --tls-verify=false option.

Procedure

Copy the root CA file to one of /etc/containers/certs.d/ or /etc/docker/certs.d/. Use the exact path determined by the server hostname, and name the file ca.crt:
```
$ sudo cp rootCA.pem /etc/containers/certs.d/quay-server.example.com/ca.crt
```
Verify that you no longer need to use the --tls-verify=false option when logging in to your Project Quay registry:
```
$ sudo podman login quay-server.example.com
```
Example output
```
Login Succeeded!
```

Configuring the system to trust the certificate authority

To trust your self-signed certificate authority, you can add the root CA to the system-wide trust store and update certificate configuration. You can verify trust with the trust list command before browsing your Project Quay registry over HTTPS.

Procedure

Enter the following command to copy the rootCA.pem file to the consolidated system-wide trust store:
```
$ sudo cp rootCA.pem /etc/pki/ca-trust/source/anchors/
```
Enter the following command to update the system-wide trust store configuration:
```
$ sudo update-ca-trust extract
```
Optional. You can use the trust list command to ensure that the Quay server has been configured:
```
$ trust list | grep quay
    label: quay-server.example.com
```
Now, when you browse to the registry at https://quay-server.example.com, the lock icon shows that the connection is secure:

To remove the rootCA.pem file from system-wide trust, delete the file and update the configuration:

$ sudo rm /etc/pki/ca-trust/source/anchors/rootCA.pem

$ sudo update-ca-trust extract

$ trust list | grep quay

Additional resources

Using shared system certificates

Configuring the Podman CNI to use IPv6

You can configure the Podman Container Network Interface for IPv4 and IPv6 to run a local Project Quay instance over IPv6 for development or testing. By default, the root user Podman network uses IPv4 only.

In some cases, you might want to run a local instance of Project Quay to use IPv6. This setup is common for development or testing purposes.

Additional resources

How to configure the default podman container network for the root user to use both IPv4 and IPv6

Creating a dual-stack container network

To run a local Project Quay instance over IPv6, you can create a new Podman container network with IPv6 enabled instead of changing the default root network. New containers on this network are natively dual-stack.

Procedure

Unless the default container network must use both IPv4 and IPv6, create a new dual-stack container network. As a root user, create a new container network that is dual-stack by running the following command:
```
# podman network create ip-dual-stack --ipv6
```
With this command, new containers use this network are a natively dual-stack.

Deploying a local instance of Project Quay in IPv6

To deploy a local Project Quay instance over IPv6, you can set FEATURE_LISTEN_IP_VERSION in config.yaml and start the registry container with explicit IPv6 port mappings.

After you have created a new dual-stack container network, you can deploy a local instance of Project Quay.

Prerequisites

You have configured Redis, your PostgreSQL database, local image storage, and creating a config.yaml file with the desired settings.

Procedure

In your Project Quay config.yaml file, set the FEATURE_LISTEN_IP_VERSION field to IPv6. For example:
```
# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
```
Enter the following command to start the Quay registry container, specifying the appropriate volumes for configuration data and local storage for image data. Note that if you are using dual-stack, you must specify explicit IPv6 port mapping when starting the container.
```
$ sudo podman run -d --rm -p "[::]:80:8080" -p "[::]:443:8443"  \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   quay.io/projectquay/quay:v3.18.0
```

Next steps

After you deploy a proof of concept Project Quay registry, you can explore guides for using and managing the registry in production. These resources cover users, repositories, security scanning, mirroring, and geo-replication.

The following guides might be useful after deploying a proof of concept version of Project Quay. Many of these procedures can be used on a proof of concept deployment, offering insights to Project Quay’s features.

Using Project Quay covers adding users and repositories, using image tags, building Dockerfiles with build workers, setting up build triggers, adding notifications for repository events, and more.
Managing Project Quay covers using SSL/TLS, configuring action log storage, configuring the Clair security scanner, repository mirroring, IPv6 and dual-stack deployments, configuring OIDC for Project Quay, geo-replication, and more.

Additional resources