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:
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:
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:
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.
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
SSL:
A valid SSL certificate and private key files are required to use this option.
Enabling SSL 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-avaliability systems.

If enabled, replicates storage to other regions.
Location ID:
{{ sc.location }}
{{ storageConfigError[$index].location }}
Remove
Set Default:
Storage Engine:
{{ storageConfigError[$index].engine }}
{{ field.title }}:
{{ field.help_text }}
See Documentation for more information
Add Additional Storage Engine
E-mail

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

SMTP Server: >
SMTP Server Port:
TLS:
Mail Sender:
E-mail address from which all e-mails are sent. If not specified, support@quay.io will be used.
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 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.
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).
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.
LDAP URI:
The full LDAP URI, including the ldap:// or ldaps:// prefix.
Base DN:
A list of Distinguished Name pieces which forms the base path for looking up all LDAP records.
Example: [dc=my,dc=domain,dc=com]
User Relative DN:
A list of Distinguished Name pieces which forms the base path for looking up all user LDAP records, relative to the Base DN defined above.
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".
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

GitHub:
GitHub Endpoint:
The GitHub Enterprise endpoint. Must start with http:// or https://.
OAuth Client ID:
OAuth Client Secret:
Organization Filtering:
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.

OAuth Client ID:
OAuth Client Secret:
Dockerfile Build Support
If enabled, users can submit Dockerfiles to be built and pushed by the Enterprise Registry.
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

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

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

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