License
Basic Configuration
Enterprise Logo URL:
Enter the full URL to your company's logo.
Contact Information:
Information to show in the Contact Page. If none specified, CoreOS contact information is displayed.
Anonymous Access:
Enable Anonymous Access
If enabled, public repositories and search can be accessed by anyone that can reach the registry, even if they are not authenticated. Disable to only allow authenticated users to view and pull "public" resources.
User Creation:
Enable Open User Creation
If enabled, user accounts can be created by anyone. Users can always be created in the users panel under this superuser view.
Encrypted Client Password:
Require Encrypted Client Passwords
If enabled, users will not be able to login from the Docker command line with a non-encrypted password and must generate an encrypted password to use.
This feature is highly recommended for setups with external authentication, as Docker currently stores passwords in plaintext on user's machines.
Team Invitations:
Require Team Invitations
If enabled, when adding a new user to a team, they will receive an invitation to join the team, with the option to decline. Otherwise, users will be immediately part of a team when added by a team administrator.
Server Configuration
Server Hostname:
The HTTP host (and optionally the port number if a non-standard HTTP/HTTPS port) of the location where the registry will be accessible on the network
TLS:
Running without TLS should not be used for production workloads!
Terminating TLS outside of Quay Enterprise can result in unusual behavior if the external load balancer is not configured properly. This option is not recommended for simple setups. Please contact support if you encounter problems while using this option.
Enabling TLS also enables HTTP Strict Transport Security.
This prevents downgrade attacks and cookie theft, but browsers will reject all future insecure connections on this hostname.
Certificate:
The certificate must be in PEM format.
Private key:
redis

A redis key-value store is required for real-time events and build logs.

Redis Hostname: >
Redis port:
Access to this port and hostname must be allowed from all hosts running the enterprise registry
Redis password:
Registry Storage

Registry images can be stored either locally or in a remote storage system. A remote storage system is required for high-availability systems.

Enable Storage Replication
If enabled, replicates storage to other regions. See documentation for more information.
Location ID:
{{ sc.location }}
{{ storageConfigError[$index].location }}
Remove
Set Default:
Replicate to storage engine by default
Storage Engine:
{{ storageConfigError[$index].engine }}
{{ field.title }}: {{ field.placeholder }}
{{ field.help_text }}
See Documentation for more information
Add Additional Storage Engine
Security Scanner

If enabled, all images pushed to Quay will be scanned via the external security scanning service, with vulnerability information available in the UI and API, as well as async notification support.

Enable Security Scanning
A scanner compliant with the Quay Security Scanning API must be running to use this feature. Documentation on running Clair can be found at Running Clair Security Scanner.
Security Scanner Endpoint:
The HTTP URL at which the security scanner is running.
Authentication Key:
The security scanning service requires an authorized service key to speak to Quay. Once setup, the key can be managed in the Service Keys panel under the Super User Admin Panel.
BitTorrent-based download

If enabled, all images in the registry can be downloaded using the quayctl tool via the BitTorrent protocol. A JWT-compatible BitTorrent tracker such as Chihaya must be run.

Enable BitTorrent downloads
Announce URL:
The HTTP URL at which the torrents should be announced. A JWT-compatible tracker such as Chihaya must be run to ensure proper security. Documentation on running Chihaya with this support can be found at Running Chihaya for Quay Enterprise.
rkt Conversion

If enabled, all images in the registry can be fetched via rkt fetch or any other AppC discovery-compliant implementation.

Enable ACI Conversion
Documentation on generating these keys can be found at Generating ACI Signing Keys.
GPG2 Public Key File:
The certificate must be in PEM format.
GPG2 Private Key File:
GPG2 Private Key Name:
E-mail

Valid e-mail server configuration is required for notification e-mails and the ability of users to reset their passwords.

Enable E-mails
SMTP Server: >
SMTP Server Port:
TLS:
Require TLS
Mail Sender:
E-mail address from which all e-mails are sent. If not specified, support@quay.io will be used.
Authentication:
Requires Authentication
Username:
Password:
Authentication

Authentication for the registry can be handled by either the registry itself, LDAP or external JWT endpoint.
Additional external authentication providers (such as GitHub) can be used on top of this choice.

It is highly recommended to require encrypted client passwords. External passwords used in the Docker client will be stored in plaintext! Enable this requirement now.
Note: The "Require Encrypted Client Passwords" feature is currently enabled which will prevent passwords from being saved as plaintext by the Docker client.
Authentication:
Keystone API Version:
Keystone Authentication URL:
The URL (starting with http or https) of the Keystone Server endpoint for auth.
Keystone Administrator Username:
The username for the Keystone admin.
Keystone Administrator Password:
The password for the Keystone admin.
Keystone Administrator Tenant:
The tenant (project/group) that contains the administrator user.
JSON Web Token authentication allows your organization to provide an HTTP endpoint that verifies user credentials on behalf of .
Documentation on the API required can be found here: https://github.com/coreos/jwt-auth-example.
Authentication Issuer:
The id of the issuer signing the JWT token. Must be unique to your organization.
Public Key:
A certificate containing the public key portion of the key pair used to sign the JSON Web Tokens. This file must be in PEM format.
User Verification Endpoint:
The URL (starting with http or https) on the JWT authentication server for verifying username and password credentials.
Credentials will be sent in the Authorization header as Basic Auth, and this endpoint should return 200 OK on success (or a 4** otherwise).
User Query Endpoint:
The URL (starting with http or https) on the JWT authentication server for looking up users based on a prefix query. This is optional.
The prefix query will be sent as a query parameter with name query.
User Lookup Endpoint:
The URL (starting with http or https) on the JWT authentication server for looking up a user by username or email address.
The username or email address will be sent as a query parameter with name username.
LDAP URI:
The full LDAP URI, including the ldap:// or ldaps:// prefix.
Base DN:
A Distinguished Name path which forms the base path for looking up all LDAP records.
Example: dc=my,dc=domain,dc=com
User Relative DN:
A Distinguished Name path which forms the base path for looking up all user LDAP records, relative to the Base DN defined above.
Example: ou=employees
Secondary User Relative DNs:
A list of Distinguished Name path(s) which forms the secondary base path(s) for looking up all user LDAP records, relative to the Base DN defined above. These path(s) will be tried if the user is not found via the primary relative DN.
Example: [ou=employees]
Administrator DN:
The Distinguished Name for the Administrator account. This account must be able to login and view the records for all user accounts.
Example: uid=admin,ou=employees,dc=my,dc=domain,dc=com
Administrator DN Password:
Note: This will be stored in plaintext inside the config.yaml, so setting up a dedicated account or using a password hash is highly recommended.
The password for the Administrator DN.
UID Attribute:
The name of the property field in your LDAP user records that stores your users' username. Typically "uid".
Mail Attribute:
The name of the property field in your LDAP user records that stores your users' e-mail address(es). Typically "mail".
Custom TLS Certificate:
If specified, the certificate (in PEM format) for the LDAP TLS connection.
Allow insecure:
Allow fallback to non-TLS connections
If enabled, LDAP will fallback to insecure non-TLS connections if TLS does not succeed.
GitHub (Enterprise) Authentication

If enabled, users can use GitHub or GitHub Enterprise to authenticate to the registry.

Note: A registered GitHub (Enterprise) OAuth application is required. View instructions on how to Create an OAuth Application in GitHub

Enable GitHub Authentication
GitHub:
GitHub Endpoint:
The GitHub Enterprise endpoint. Must start with http:// or https://.
OAuth Client ID:
OAuth Client Secret:
Organization Filtering:
Restrict By Organization Membership
If enabled, only members of specified GitHub Enterprise organizations will be allowed to login via GitHub Enterprise.
Google Authentication

If enabled, users can use Google to authenticate to the registry.

Note: A registered Google OAuth application is required. Visit the Google Developer Console to register an application.

Enable Google Authentication
OAuth Client ID:
OAuth Client Secret:
Dockerfile Build Support
If enabled, users can submit Dockerfiles to be built and pushed by the Enterprise Registry.
Enable Dockerfile Build
Note: Build workers are required for this feature. See Adding Build Workers for instructions on how to setup build workers.
GitHub (Enterprise) Build Triggers

If enabled, users can setup GitHub or GitHub Enterprise triggers to invoke Registry builds.

Note: A registered GitHub (Enterprise) OAuth application (separate from GitHub Authentication) is required. View instructions on how to Create an OAuth Application in GitHub

Enable GitHub Triggers
GitHub:
GitHub Endpoint:
The GitHub Enterprise endpoint. Must start with http:// or https://.
OAuth Client ID:
OAuth Client Secret:
BitBucket Build Triggers

If enabled, users can setup BitBucket triggers to invoke Registry builds.

Note: A registered BitBucket OAuth application is required. View instructions on how to Create an OAuth Application in BitBucket

Enable BitBucket Triggers
OAuth Consumer Key:
OAuth Consumer Secret:
GitLab Build Triggers

If enabled, users can setup GitLab triggers to invoke Registry builds.

Note: A registered GitLab OAuth application is required. Visit the GitLab applications admin panel to create a new application.

The callback URL to use is:   {{ config.PREFERRED_URL_SCHEME || 'http' }}://{{ config.SERVER_HOSTNAME || 'localhost' }}/oauth2/gitlab/callback/trigger

Enable GitLab Triggers
GitLab:
GitLab Endpoint:
The GitLab Enterprise endpoint. Must start with http:// or https://.
OAuth Client ID:
OAuth Client Secret: