License
Custom SSL Certificates
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:
Time Machine

Time machine keeps older copies of tags within a repository for the configured period of time, after which they are garbage collected. This allows users to revert tags to older images in case they accidentally pushed a broken image. It is highly recommended to have time machine enabled, but it does take a bit more space in storage.

Allowed expiration periods:
The expiration periods allowed for configuration. The default tag expiration *must* be in this list.
Default expiration period:
The default tag expiration period for all namespaces (users and organizations). Must be expressed in a duration string form: 30m, 1h, 1d, 2w.
Allow users to select expiration:
Enable Expiration Configuration
If enabled, users will be able to select the tag expiration duration for the namespace(s) they administrate, from the configured list of options.
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.
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.
Security Scanner Endpoint:
The HTTP URL at which the security scanner is running.
Is the security scanner behind a domain signed with a self-signed TLS certificate? If so, please make sure to register your SSL CA in the custom certificates panel above.
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:
Internal 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 in addition for login into the UI.

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:
Team synchronization:
Enable Team Synchronization Support
If enabled, organization administrators who are also superusers can set teams to have their membership synchronized with a backing group in {{ config.AUTHENTICATION_TYPE }}.
Resynchronization duration:
The duration before a team must be re-synchronized. Must be expressed in a duration string form: 30m, 1h, 1d.
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.
External Authorization (OAuth)
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:
{{ config[provider]['SERVICE_NAME'] || (getOIDCProviderId(provider) + ' Authentication') }} (Delete)
Warning: This OIDC provider is not bound to your {{ config.AUTHENTICATION_TYPE }} authentication. Logging in via this provider will create a -only user, which is not the recommended approach. It is highly recommended to choose a "Binding Field" below.
Service ID: {{ getOIDCProviderId(provider) }}
OIDC Server:
The URL of an OIDC-compliant server.
Client ID:
Client Secret:
Service Name:
The user friendly name to display for the service on the login page.
Service Icon (optional):
If specified, the icon to display for this login service on the login page. Can be either a URL to an icon or a CSS class name from Font Awesome
Binding Field:
If selected, when a user logs in via this OIDC provider, they will be automatically bound to their user in {{ config.AUTHENTICATION_TYPE }} by matching the selected field from the OIDC provider to the associated user in {{ config.AUTHENTICATION_TYPE }}.
For example, selecting Subject here with a backing authentication system of LDAP means that a user logging in via this OIDC provider will also be bound to their user in LDAP by username.
If none selected, a user unique to will be created on initial login with this OIDC provider. This is not the recommended setup.
Add OIDC Provider What is OIDC?
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://.
Application Id:
Secret: