docs: fix markup and broken links

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>

docs/content/_index.md

@@ -1,8 +1,6 @@
 ---
 description: High-level overview of the Registry
 keywords: registry, on-prem, images, tags, repository, distribution
-redirect_from:
-- /registry/overview/
 title: Docker Registry
 ---
 
@@ -35,29 +33,41 @@ The Registry is compatible with Docker engine **version 1.6.0 or higher**.
 
 Start your registry
 
+```sh
 docker run -d -p 5000:5000 --name registry registry:2
+```
 
 Pull (or build) some image from the hub
 
+```sh
 docker pull ubuntu
+```
 
 Tag the image so that it points to your registry
 
+```sh
 docker image tag ubuntu localhost:5000/myfirstimage
+```
 
 Push it
 
+```sh
 docker push localhost:5000/myfirstimage
+```
 
 Pull it back
 
+```sh
 docker pull localhost:5000/myfirstimage
+```
 
 Now stop your registry and remove all data
 
+```sh
 docker container stop registry && docker container rm -v registry
+```
 
 ## Next
 
-You should now read the [detailed introduction about the registry](./about/_index.md),
-or jump directly to [deployment instructions](./about/deploying.md).
+You should now read the [detailed introduction about the registry](about),
+or jump directly to [deployment instructions](about/deploying).

docs/content/about/_index.md

@@ -27,7 +27,7 @@ The Registry GitHub repository includes additional information about advanced
 authentication and authorization methods. Only very large or public deployments
 are expected to extend the Registry in this way.
 
-Finally, the Registry ships with a robust [notification system](notifications.md),
+Finally, the Registry ships with a robust [notification system](notifications),
 calling webhooks in response to activity, and both extensive logging and reporting,
 mostly useful for large installations that want to collect metrics.
 
@@ -39,7 +39,7 @@ Image names as used in typical docker commands reflect their origin:
  * `docker pull myregistrydomain:port/foo/bar` instructs docker to contact the registry located at `myregistrydomain:port` to find the image `foo/bar`
 
 You can find out more about the various Docker commands dealing with images in
-the [official Docker engine documentation](../engine/reference/commandline/cli.md).
+the [official Docker engine documentation](https://docs.docker.com/engine/reference/commandline/cli/).
 
 ## Use cases
 
@@ -70,4 +70,4 @@ golang are certainly useful as well for advanced operations or hacking.
 
 ## Next
 
-Dive into [deploying your registry](deploying.md)
+Dive into [deploying your registry](deploying)

docs/content/about/architecture.md

@@ -1,5 +1,5 @@
 ---
-published: false
+draft: true
 ---
 
 # Architecture

docs/content/about/compatibility.md

@@ -5,13 +5,14 @@ title: Registry compatibility
 ---
 
 ## Synopsis
+
 If a manifest is pulled by _digest_ from a registry 2.3 with Docker Engine 1.9
 and older, and the manifest was pushed with Docker Engine 1.10, a security check
 causes the Engine to receive a manifest it cannot use and the pull fails.
 
 ## Registry manifest support
 
-Historically, the registry has supported a [single manifest type](./spec/manifest-v2-1.md)
+Historically, the registry has supported a single manifest type
 known as _Schema 1_.
 
 With the move toward multiple architecture images, the distribution project
@@ -23,7 +24,6 @@ preserve compatibility with older versions of Docker Engine.
 This conversion has some implications for pulling manifests by digest and this
 document enumerates these implications.
 
-
 ## Content Addressable Storage (CAS)
 
 Manifests are stored and retrieved in the registry by keying off a digest
@@ -42,7 +42,6 @@ attempts to send a _Schema 2_ manifest, falling back to sending a
 Schema 1 type manifest when it detects that the registry does not
 support the new version.
 
-
 ## Registry v2.3
 
 ### Manifest push with Docker 1.10
@@ -75,4 +74,3 @@ registry persists to disk.
 
 When the manifest is pulled by digest or tag with any Docker version, a
 _Schema 1_ manifest is returned.
-

docs/content/about/configuration.md

@@ -20,7 +20,7 @@ To override a configuration option, create an environment variable named
 and the `_` (underscore) represents indention levels. For example, you can
 configure the `rootdirectory` of the `filesystem` storage backend:
 
-```none
+```yaml
 storage:
   filesystem:
     rootdirectory: /var/lib/registry
@@ -28,7 +28,7 @@ storage:
 
 To override this value, set an environment variable like this:
 
-```none
+```sh
 REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/somewhere
 ```
 
@@ -64,7 +64,7 @@ These are all configuration options for the registry. Some options in the list
 are mutually exclusive. Read the detailed reference information about each
 option before finalizing your configuration.
 
-```none
+```yaml
 version: 0.1
 log:
   accesslog:
@@ -293,7 +293,7 @@ the children marked **required**.
 
 ## `version`
 
-```none
+```yaml
 version: 0.1
 ```
 
@@ -307,7 +307,7 @@ The `log` subsection configures the behavior of the logging system. The logging
 system outputs everything to stderr. You can adjust the granularity and format
 with this configuration section.
 
-```none
+```yaml
 log:
   accesslog:
     disabled: true
@@ -326,7 +326,7 @@ log:
 
 ### `accesslog`
 
-```none
+```yaml
 accesslog:
   disabled: true
 ```
@@ -338,7 +338,7 @@ Access logging can be disabled by setting the boolean flag `disabled` to `true`.
 
 ## `hooks`
 
-```none
+```yaml
 hooks:
   - type: mail
     levels:
@@ -362,7 +362,7 @@ Refer to `loglevel` to configure the level of messages printed.
 
 > **DEPRECATED:** Please use [log](#log) instead.
 
-```none
+```yaml
 loglevel: debug
 ```
 
@@ -371,7 +371,7 @@ Permitted values are `error`, `warn`, `info` and `debug`. The default is
 
 ## `storage`
 
-```none
+```yaml
 storage:
   filesystem:
     rootdirectory: /var/lib/registry
@@ -436,15 +436,15 @@ returns an error. You can choose any of these backend storage drivers:
 
 | Storage driver      | Description                                                                                                                                                                                                                                                                              |
 |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `filesystem`        | Uses the local disk to store registry files. It is ideal for development and may be appropriate for some small-scale production applications. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/filesystem.md). |
-| `azure`             | Uses Microsoft Azure Blob Storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/azure.md).                                                                                                               |
-| `gcs`               | Uses Google Cloud Storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/gcs.md).                                                                                                                           |
-| `s3`                | Uses Amazon Simple Storage Service (S3) and compatible Storage Services. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/s3.md).                                                                            |
+| `filesystem`        | Uses the local disk to store registry files. It is ideal for development and may be appropriate for some small-scale production applications. See the [driver's reference documentation](/storage-drivers/filesystem). |
+| `azure`             | Uses Microsoft Azure Blob Storage. See the [driver's reference documentation](/storage-drivers/azure).                                                                                                               |
+| `gcs`               | Uses Google Cloud Storage. See the [driver's reference documentation](/storage-drivers/gcs).                                                                                                                           |
+| `s3`                | Uses Amazon Simple Storage Service (S3) and compatible Storage Services. See the [driver's reference documentation](/storage-drivers/s3).                                                                            |
 
 For testing only, you can use the [`inmemory` storage
-driver](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/inmemory.md).
+driver](/storage-drivers/inmemory).
 If you would like to run a registry from volatile memory, use the
-[`filesystem` driver](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/filesystem.md)
+[`filesystem` driver](/storage-drivers/filesystem)
 on a ramdisk.
 
 If you are deploying a registry on Windows, a Windows volume mounted from the
@@ -453,7 +453,7 @@ data-store. If you do use a Windows volume, the length of the `PATH` to
 the mount point must be within the `MAX_PATH` limits (typically 255 characters),
 or this error will occur:
 
-```none
+```text
 mkdir /XXX protocol error and your registry will not function properly.
 ```
 
@@ -496,7 +496,7 @@ Use the `delete` structure to enable the deletion of image blobs and manifests
 by digest. It defaults to false, but it can be enabled by writing the following
 on the configuration file:
 
-```none
+```yaml
 delete:
   enabled: true
 ```
@@ -531,14 +531,14 @@ instance is aggressively caching.
 To disable redirects, add a single flag `disable`, set to `true`
 under the `redirect` section:
 
-```none
+```yaml
 redirect:
   disable: true
 ```
 
 ## `auth`
 
-```none
+```yaml
 auth:
   silly:
     realm: silly-realm
@@ -593,7 +593,7 @@ security.
 
 
 For more information about Token based authentication configuration, see the
-[specification](spec/auth/token.md).
+[specification](/spec/auth/token).
 
 ### `htpasswd`
 
@@ -601,7 +601,7 @@ The _htpasswd_ authentication backed allows you to configure basic
 authentication using an
 [Apache htpasswd file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html).
 The only supported password format is
-[`bcrypt`](http://en.wikipedia.org/wiki/Bcrypt). Entries with other hash types
+[`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt). Entries with other hash types
 are ignored. The `htpasswd` file is loaded once, at startup. If the file is
 invalid, the registry will display an error and will not start.
 
@@ -629,7 +629,7 @@ object it is wrapping. For instance, a registry middleware must implement the
 This is an example configuration of the `cloudfront`  middleware, a storage
 middleware:
 
-```none
+```yaml
 middleware:
   registry:
     - name: ARegistryMiddleware
@@ -694,7 +694,7 @@ location of a proxy for the layer stored by the S3 storage driver.
 
 ## `http`
 
-```none
+```yaml
 http:
   addr: localhost:5000
   net: tcp
@@ -834,7 +834,7 @@ to access proxy statistics. These statistics are exposed at `/debug/vars` in JSO
 
 #### `prometheus`
 
-```none
+```yaml
 prometheus:
   enabled: true
   path: /metrics
@@ -879,7 +879,7 @@ settings for the registry.
 
 ## `notifications`
 
-```none
+```yaml
 notifications:
   events:
     includereferences: true
@@ -937,7 +937,7 @@ The `events` structure configures the information provided in event notification
 
 ## `redis`
 
-```none
+```yaml
 redis:
   addr: localhost:6379
   password: asecret
@@ -974,7 +974,7 @@ registry does not set an expiration value on keys.
 
 ### `pool`
 
-```none
+```yaml
 pool:
   maxidle: 16
   maxactive: 64
@@ -991,7 +991,7 @@ Use these settings to configure the behavior of the Redis connection pool.
 
 ### `tls`
 
-```none
+```yaml
 tls:
   enabled: false
 ```
@@ -1005,7 +1005,7 @@ Use these settings to configure Redis TLS.
 
 ## `health`
 
-```none
+```yaml
 health:
   storagedriver:
     enabled: true
@@ -1090,7 +1090,7 @@ attempt fails, the health check will fail.
 
 ## `proxy`
 
-```
+```yaml
 proxy:
   remoteurl: https://registry-1.docker.io
   username: [username]
@@ -1100,7 +1100,7 @@ proxy:
 
 The `proxy` structure allows a registry to be configured as a pull-through cache
 to Docker Hub. See
-[mirror](https://github.com/docker/docker.github.io/tree/master/registry/recipes/mirror.md)
+[mirror](/recipes/mirror)
 for more information. Pushing to a registry configured as a pull-through cache
 is unsupported.
 
@@ -1120,7 +1120,7 @@ username (such as `batman`) and the password for that username.
 
 ## `validation`
 
-```none
+```yaml
 validation:
   manifests:
     urls:
@@ -1159,7 +1159,7 @@ one of the `allow` regular expressions **and** one of the following holds:
 
 You can use this simple example for local development:
 
-```none
+```yaml
 version: 0.1
 log:
   level: debug
@@ -1183,10 +1183,9 @@ See
 for another simple configuration. Both examples are generally useful for local
 development.
 
-
 ## Example: Middleware configuration
 
-This example configures [Amazon Cloudfront](http://aws.amazon.com/cloudfront/)
+This example configures [Amazon Cloudfront](https://aws.amazon.com/cloudfront/)
 as the storage middleware in a registry. Middleware allows the registry to serve
 layers via a content delivery network (CDN). This reduces requests to the
 storage layer.
@@ -1195,7 +1194,7 @@ Cloudfront requires the S3 storage driver.
 
 This is the configuration expressed in YAML:
 
-```none
+```yaml
 middleware:
   storage:
   - name: cloudfront
@@ -1210,6 +1209,8 @@ middleware:
 See the configuration reference for [Cloudfront](#cloudfront) for more
 information about configuration options.
 
-> **Note**: Cloudfront keys exist separately from other AWS keys.  See
-> [the documentation on AWS credentials](http://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)
-> for more information.
+{{< hint type=note >}}
+Cloudfront keys exist separately from other AWS keys. See
+[the documentation on AWS credentials](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)
+for more information.
+{{< /hint >}}

docs/content/about/deploying.md

@@ -9,7 +9,7 @@ A registry is an instance of the `registry` image, and runs within Docker.
 
 This topic provides basic information about deploying and configuring a
 registry. For an exhaustive list of configuration options, see the
-[configuration reference](configuration.md).
+[configuration reference](../configuration).
 
 If you have an air-gapped datacenter, see
 [Considerations for air-gapped registries](#considerations-for-air-gapped-registries).
@@ -27,7 +27,7 @@ The registry is now ready to use.
 > **Warning**: These first few examples show registry configurations that are
 > only appropriate for testing. A production-ready registry must be protected by
 > TLS and should ideally use an access-control mechanism. Keep reading and then
-> continue to the [configuration guide](configuration.md) to deploy a
+> continue to the [configuration guide](../configuration) to deploy a
 > production-ready registry.
 
 ## Copy an image from Docker Hub to your registry
@@ -94,7 +94,7 @@ To configure the container, you can pass additional or modified options to the
 `docker run` command.
 
 The following sections provide basic guidelines for configuring your registry.
-For more details, see the [registry configuration reference](configuration.md).
+For more details, see the [registry configuration reference](../configuration).
 
 ### Start the registry automatically
 
@@ -144,7 +144,7 @@ $ docker run -d \
 
 ### Customize the storage location
 
-By default, your registry data is persisted as a [docker volume](../storage/volumes.md)
+By default, your registry data is persisted as a [docker volume](https://docs.docker.com/storage/volumes)
 on the host filesystem. If you want to store your registry contents at a specific
 location on your host filesystem, such as if you have an SSD or SAN mounted into
 a particular directory, you might decide to use a bind mount instead. A bind mount
@@ -166,8 +166,8 @@ $ docker run -d \
 By default, the registry stores its data on the local filesystem, whether you
 use a bind mount or a volume. You can store the registry data in an Amazon S3
 bucket, Google Cloud Platform, or on another storage back-end by using
-[storage drivers](./storage-drivers/index.md). For more information, see
-[storage configuration options](./configuration.md#storage).
+[storage drivers](/storage-drivers). For more information, see
+[storage configuration options](../configuration#storage).
 
 ## Run an externally-accessible registry
 
@@ -252,23 +252,23 @@ The registry supports using Let's Encrypt to automatically obtain a
 browser-trusted certificate. For more information on Let's Encrypt, see
 [https://letsencrypt.org/how-it-works/](https://letsencrypt.org/how-it-works/)
 and the relevant section of the
-[registry configuration](configuration.md#letsencrypt).
+[registry configuration](../configuration#letsencrypt).
 
 ### Use an insecure registry (testing only)
 
 It is possible to use a self-signed certificate, or to use our registry
 insecurely. Unless you have set up verification for your self-signed
-certificate, this is for testing only. See [run an insecure registry](insecure.md).
+certificate, this is for testing only. See [run an insecure registry](../insecure).
 
 ## Run the registry as a service
 
-[Swarm services](../engine/swarm/services.md) provide several advantages over
+[Swarm services](https://docs.docker.com/engine/swarm/services) provide several advantages over
 standalone containers. They use a declarative model, which means that you define
 the desired state and Docker works to keep your service in that state. Services
 provide automatic load balancing scaling, and the ability to control the
 distribution of your service, among other advantages. Services also allow you to
 store sensitive data such as TLS certificates in
-[secrets](../engine/swarm/secrets.md).
+[secrets](https://docs.docker.com/engine/swarm/secrets).
 
 The storage back-end you use determines whether you use a fully scaled service
 or a service with either only a single node or a node constraint.
@@ -393,18 +393,18 @@ The simplest way to achieve access restriction is through basic authentication
 This example uses native basic authentication using `htpasswd` to store the
 secrets.
 
-> **Warning**:
-> You **cannot** use authentication with authentication schemes that send
-> credentials as clear text. You must
-> [configure TLS first](deploying.md#run-an-externally-accessible-registry) for
-> authentication to work.
-{:.warning}
+{{< hint type=warning >}}
+You **cannot** use authentication with authentication schemes that send
+credentials as clear text. You must
+[configure TLS first](#run-an-externally-accessible-registry) for
+authentication to work.
+{{< /hint >}}
 
-> **Warning**
-> The official registry image **only** supports htpasswd credentials in
-> bcrypt format, so if you omit the `-B` option when generating the credential
-> using htpasswd, all authentication attempts will fail.
-{:.warning}
+{{< hint type=warning >}}
+The official registry image **only** supports htpasswd credentials in
+bcrypt format, so if you omit the `-B` option when generating the credential
+using htpasswd, all authentication attempts will fail.
+{{< /hint >}}
 
 1. Create a password file with one entry for the user `testuser`, with password
    `testpassword`:
@@ -459,21 +459,23 @@ secrets.
    Test that you can now pull an image from the registry or push an image to
    the registry.
 
-> **X509 errors**: X509 errors usually indicate that you are attempting to use
-> a self-signed certificate without configuring the Docker daemon correctly.
-> See [run an insecure registry](insecure.md).
+{{< hint type=note title="X509 errors" >}}
+X509 errors usually indicate that you are attempting to use
+a self-signed certificate without configuring the Docker daemon correctly.
+See [run an insecure registry](../insecure).
+{{< /hint >}}
 
 ### More advanced authentication
 
 You may want to leverage more advanced basic auth implementations by using a
-proxy in front of the registry. See the [recipes list](recipes/index.md).
+proxy in front of the registry. See the [recipes list](/recipes/).
 
 The registry also supports delegated authentication which redirects users to a
 specific trusted token server. This approach is more complicated to set up, and
 only makes sense if you need to fully configure ACLs and need more control over
 the registry's integration into your global authorization and authentication
-systems. Refer to the following [background information](spec/auth/token.md) and
-[configuration information here](configuration.md#auth).
+systems. Refer to the following [background information](/spec/auth/token) and
+[configuration information here](../configuration#auth).
 
 This approach requires you to implement your own authentication system or
 leverage a third-party implementation.
@@ -558,20 +560,21 @@ following:
   4. When you push images to the registries in the list, their
      non-distributable layers are pushed to the registry.
 
-      > **Warning**: Non-distributable artifacts typically have restrictions on
-      > how and where they can be distributed and shared. Only use this feature
-      > to push artifacts to private registries and ensure that you are in
-      > compliance with any terms that cover redistributing non-distributable
-      > artifacts.
-
+{{< hint type=warning >}}
+Non-distributable artifacts typically have restrictions on
+how and where they can be distributed and shared. Only use this feature
+to push artifacts to private registries and ensure that you are in
+compliance with any terms that cover redistributing non-distributable
+artifacts.
+{{< /hint >}}
 
 ## Next steps
 
 More specific and advanced information is available in the following sections:
 
- - [Configuration reference](configuration.md)
- - [Working with notifications](notifications.md)
- - [Advanced "recipes"](recipes/index.md)
- - [Registry API](spec/api.md)
- - [Storage driver model](storage-drivers/index.md)
- - [Token authentication](spec/auth/token.md)
+- [Configuration reference](../configuration)
+- [Working with notifications](../notifications)
+- [Advanced "recipes"](/recipes)
+- [Registry API](/spec/api)
+- [Storage driver model](/storage-drivers)
+- [Token authentication](/spec/auth/token)

docs/content/about/garbage-collection.md

@@ -21,15 +21,15 @@ that certain layers no longer exist on the filesystem.
 
 Filesystem layers are stored by their content address in the Registry. This
 has many advantages, one of which is that data is stored once and referred to by manifests.
-See [here](compatibility.md#content-addressable-storage-cas) for more details.
+See [here](../compatibility#content-addressable-storage-cas) for more details.
 
 Layers are therefore shared amongst manifests; each manifest maintains a reference
 to the layer. As long as a layer is referenced by one manifest, it cannot be garbage
 collected.
 
 Manifests and layers can be `deleted` with the registry API (refer to the API
-documentation [here](spec/api.md#deleting-a-layer) and
-[here](spec/api.md#deleting-an-image) for details). This API removes references
+documentation [here](/spec/api#deleting-a-layer) and
+[here](/spec/api#deleting-an-image) for details). This API removes references
 to the target and makes them eligible for garbage collection. It also makes them
 unable to be read via the API.
 

docs/content/about/glossary.md

@@ -1,5 +1,5 @@
 ---
-published: false
+draft: true
 ---
 
 # Glossary

docs/content/about/help.md

@@ -10,5 +10,3 @@ If you want to report a bug:
 
 - be sure to first read about [how to contribute](https://github.com/distribution/distribution/blob/master/CONTRIBUTING.md).
 - you can then do so on the [GitHub project bugtracker](https://github.com/distribution/distribution/issues).
-
-You can also find out more about the Docker's project [Getting Help resources](../opensource/ways.md).

docs/content/about/insecure.md

@@ -11,9 +11,9 @@ involves security trade-offs and additional configuration steps.
 
 ## Deploy a plain HTTP registry
 
-> **Warning**:
-> It's not possible to use an insecure registry with basic authentication.
-{:.warning}
+{{< hint type=warning >}}
+It's not possible to use an insecure registry with basic authentication.
+{{< /hint >}}
 
 This procedure configures Docker to entirely disregard security for your
 registry. This is **very** insecure and is not recommended. It exposes your
@@ -40,22 +40,22 @@ isolated testing or in a tightly controlled, air-gapped environment.
    With insecure registries enabled, Docker goes through the following steps:
 
    - First, try using HTTPS.
+
      - If HTTPS is available but the certificate is invalid, ignore the error
        about the certificate.
+
      - If HTTPS is not available, fall back to HTTP.
 
 
 2. Restart Docker for the changes to take effect.
 
-
 Repeat these steps on every Engine host that wants to access your registry.
 
-
 ## Use self-signed certificates
 
-> **Warning**:
-> Using this along with basic authentication requires to **also** trust the certificate into the OS cert store for some versions of docker (see below)
-{:.warning}
+{{< hint type=warning >}}
+Using this along with basic authentication requires to **also** trust the certificate into the OS cert store for some versions of docker (see below)
+{{< /hint >}}
 
 This is more secure than the insecure registry solution.
 
@@ -72,7 +72,7 @@ This is more secure than the insecure registry solution.
 
    Be sure to use the name `myregistry.domain.com` as a CN.
 
-2.  Use the result to [start your registry with TLS enabled](./deploying.md#get-a-certificate).
+2. Use the result to [start your registry with TLS enabled](../deploying#get-a-certificate).
 
 3. Instruct every Docker daemon to trust that certificate. The way to do this
    depends on your OS.
@@ -95,11 +95,11 @@ This is more secure than the insecure registry solution.
      3.  Click **Finish**. Restart Docker.
 
    - **Docker Desktop for Mac**: Follow the instructions in
-      [Adding custom CA certificates](../desktop/mac/index.md#add-tls-certificates){: target="_blank" rel="noopener" class="_"}.
+     [Adding custom CA certificates](https://docs.docker.com/desktop/mac/#add-tls-certificates).
      Restart Docker.
 
    - **Docker Desktop for Windows**: Follow the instructions in
-      [Adding custom CA certificates](../desktop/windows/index.md#adding-tls-certificates){: target="_blank" rel="noopener" class="_"}.
+     [Adding custom CA certificates](https://docs.docker.com/desktop/windows/#adding-tls-certificates).
      Restart Docker.
 
 

docs/content/about/notifications.md

@@ -8,9 +8,9 @@ The Registry supports sending webhook notifications in response to events
 happening within the registry. Notifications are sent in response to manifest
 pushes and pulls and layer pushes and pulls. These actions are serialized into
 events. The events are queued into a registry-internal broadcast system which
-queues and dispatches events to [_Endpoints_](notifications.md#endpoints).
+queues and dispatches events to [_Endpoints_](#endpoints).
 
-![Workflow of registry notifications](images/notifications.png)
+![Workflow of registry notifications](/images/notifications.png)
 
 ## Endpoints
 
@@ -45,7 +45,7 @@ The above would configure the registry with an endpoint to send events to
 5 failures happen consecutively, the registry backs off for 1 second before
 trying again.
 
-For details on the fields, see the [configuration documentation](configuration.md#notifications).
+For details on the fields, see the [configuration documentation](../configuration/#notifications).
 
 A properly configured endpoint should lead to a log message from the registry
 upon startup:

docs/content/recipes/_index.md

@@ -9,7 +9,7 @@ These recipes are not useful for most standard set-ups.
 
 ## Requirements
 
-Before following these steps, work through the [deployment guide](../deploying.md).
+Before following these steps, work through the [deployment guide](../about/deploying).
 
 At this point, it's assumed that:
 
@@ -21,8 +21,8 @@ At this point, it's assumed that:
 
 ## The List
 
- * [using Apache as an authenticating proxy](apache.md)
- * [using Nginx as an authenticating proxy](nginx.md)
- * [running a Registry on macOS](osx-setup-guide.md)
- * [mirror the Docker Hub](mirror.md)
- * [start registry via systemd](systemd.md)
+ * [using Apache as an authenticating proxy](apache)
+ * [using Nginx as an authenticating proxy](nginx)
+ * [running a Registry on macOS](osx-setup-guide)
+ * [mirror the Docker Hub](mirror)
+ * [start registry via systemd](systemd)

docs/content/recipes/apache.md

@@ -12,7 +12,7 @@ Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
 
 ### Alternatives
 
-If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](../deploying.md#native-basic-auth).
+If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](/about/deploying#native-basic-auth).
 
 ### Solution
 
@@ -30,13 +30,13 @@ Furthermore, introducing an extra http layer in your communication pipeline adds
 
 ## Setting things up
 
-Read again [the requirements](index.md#requirements).
+Read again [the requirements](../#requirements).
 
 Ready?
 
 Run the following script:
 
-```
+```sh
 mkdir -p auth
 mkdir -p data
 
@@ -191,19 +191,27 @@ EOF
 
 Now, start your stack:
 
-    docker-compose up -d
+```console
+$ docker-compose up -d
+```
 
 Log in with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
 
-    docker login myregistrydomain.com:5043
-    docker tag ubuntu myregistrydomain.com:5043/test
-    docker push myregistrydomain.com:5043/test
+```console
+$ docker login myregistrydomain.com:5043
+$ docker tag ubuntu myregistrydomain.com:5043/test
+$ docker push myregistrydomain.com:5043/test
+```
 
 Now, log in with a "pull-only" user (using `testuser` and `testpassword`), then pull back the image:
 
-    docker login myregistrydomain.com:5043
-    docker pull myregistrydomain.com:5043/test
+```console
+$ docker login myregistrydomain.com:5043
+$ docker pull myregistrydomain.com:5043/test
+```
 
 Verify that the "pull-only" can NOT push:
 
-    docker push myregistrydomain.com:5043/test
+```console
+$ docker push myregistrydomain.com:5043/test
+```

docs/content/recipes/mirror.md

@@ -2,8 +2,6 @@
 description: Setting-up a local mirror for Docker Hub images
 keywords: registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe, advanced
 title: Registry as a pull through cache
-redirect_from:
-- /engine/admin/registry_mirror/
 ---
 
 ## Use-case
@@ -88,7 +86,8 @@ but this property does not hold true for a registry cache cluster.
 
 > **Note**
 >
-> Service accounts included in the Team plan are limited to 5,000 pulls per day. See [Service Accounts](/docker-hub/service-accounts/) for more details.
+> Service accounts included in the Team plan are limited to 5,000 pulls per day.
+> See [Service Accounts](https://docs.docker.com/docker-hub/service-accounts/) for more details.
 
 ### Configure the cache
 
@@ -113,12 +112,12 @@ proxy:
 
 > **Warning**: For the scheduler to clean up old entries, `delete` must
 > be enabled in the registry configuration. See
-> [Registry Configuration](../configuration.md) for more details.
+> [Registry Configuration](/about/configuration) for more details.
 
 ### Configure the Docker daemon
 
 Either pass the `--registry-mirror` option when starting `dockerd` manually,
-or edit [`/etc/docker/daemon.json`](../../engine/reference/commandline/dockerd.md#daemon-configuration-file)
+or edit [`/etc/docker/daemon.json`](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file)
 and add the `registry-mirrors` key and value, to make the change persistent.
 
 ```json

docs/content/recipes/nginx.md

@@ -2,8 +2,6 @@
 description: Restricting access to your registry using a nginx proxy
 keywords: registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication, TLS, recipe, advanced
 title: Authenticate proxy with nginx
-redirect_from:
-- /registry/nginx/
 ---
 
 ## Use-case
@@ -19,7 +17,7 @@ mechanism fronting their internal http portal.
 
 If you just want authentication for your registry, and are happy maintaining
 users access separately, you should really consider sticking with the native
-[basic auth registry feature](../deploying.md#native-basic-auth).
+[basic auth registry feature](/about/deploying#native-basic-auth).
 
 ### Solution
 
@@ -52,7 +50,7 @@ complexity is required.
 For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets
 the following client header:
 
-```
+```none
 X-Real-IP
 X-Forwarded-For
 X-Forwarded-Proto
@@ -74,7 +72,7 @@ properly. For more information, see
 
 ## Setting things up
 
-Review the [requirements](index.md#requirements), then follow these steps.
+Review the [requirements](../#requirements), then follow these steps.
 
 1. Create the required directories
 
@@ -194,12 +192,16 @@ Review the [requirements](index.md#requirements), then follow these steps.
 
 Now, start your stack:
 
-    docker-compose up -d
+```consonle
+$ docker-compose up -d
+```
 
 Login with a "push" authorized user (using `testuser` and `testpassword`), then
 tag and push your first image:
 
-    docker login -u=testuser -p=testpassword -e=root@example.ch myregistrydomain.com:5043
-    docker tag ubuntu myregistrydomain.com:5043/test
-    docker push myregistrydomain.com:5043/test
-    docker pull myregistrydomain.com:5043/test
+```console
+$ docker login -u=testuser -p=testpassword -e=root@example.ch myregistrydomain.com:5043
+$ docker tag ubuntu myregistrydomain.com:5043/test
+$ docker push myregistrydomain.com:5043/test
+$ docker pull myregistrydomain.com:5043/test
+```

docs/content/recipes/osx-setup-guide.md

@@ -26,49 +26,65 @@ If you know, safely skip to the next section.
 
 If you don't, the TLDR is:
 
-    bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
-    source ~/.gvm/scripts/gvm
-    gvm install go1.4.2
-    gvm use go1.4.2
+```console
+$ bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
+$ source ~/.gvm/scripts/gvm
+$ gvm install go1.4.2
+$ gvm use go1.4.2
+```
 
 If you want to understand, you should read [How to Write Go Code](https://golang.org/doc/code.html).
 
 ## Checkout the source tree
 
-    mkdir -p $GOPATH/src/github.com/distribution
-    git clone https://github.com/distribution/distribution.git $GOPATH/src/github.com/distribution/distribution
-    cd $GOPATH/src/github.com/distribution/distribution
+```console
+$ mkdir -p $GOPATH/src/github.com/distribution
+$ git clone https://github.com/distribution/distribution.git $GOPATH/src/github.com/distribution/distribution
+$ cd $GOPATH/src/github.com/distribution/distribution
+```
 
 ## Build the binary
 
-    GOPATH=$(PWD)/Godeps/_workspace:$GOPATH make binaries
-    sudo mkdir -p /usr/local/libexec
-    sudo cp bin/registry /usr/local/libexec/registry
+```console
+$ GOPATH=$(PWD)/Godeps/_workspace:$GOPATH make binaries
+$ sudo mkdir -p /usr/local/libexec
+$ sudo cp bin/registry /usr/local/libexec/registry
+```
 
 ## Setup
 
 Copy the registry configuration file in place:
 
-    mkdir /Users/Shared/Registry
-    cp docs/osx/config.yml /Users/Shared/Registry/config.yml
+```console
+$ mkdir /Users/Shared/Registry
+$ cp docs/osx/config.yml /Users/Shared/Registry/config.yml
+```
 
 ## Run the registry under launchd
 
 Copy the registry plist into place:
 
-    plutil -lint docs/recipes/osx/com.docker.registry.plist
-    cp docs/recipes/osx/com.docker.registry.plist ~/Library/LaunchAgents/
-    chmod 644 ~/Library/LaunchAgents/com.docker.registry.plist
+```console
+$ plutil -lint docs/recipes/osx/com.docker.registry.plist
+$ cp docs/recipes/osx/com.docker.registry.plist ~/Library/LaunchAgents/
+$ chmod 644 ~/Library/LaunchAgents/com.docker.registry.plist
+```
 
 Start the registry:
 
-    launchctl load ~/Library/LaunchAgents/com.docker.registry.plist
+```console
+$ launchctl load ~/Library/LaunchAgents/com.docker.registry.plist
+```
 
 ### Restart the registry service
 
-    launchctl stop com.docker.registry
-    launchctl start com.docker.registry
+```console
+$ launchctl stop com.docker.registry
+$ launchctl start com.docker.registry
+```
 
 ### Unload the registry service
 
-    launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
+```console
+$ launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
+```

docs/content/recipes/systemd.md

@@ -7,8 +7,9 @@ title: Start registry via systemd
 ## Use-case
 
 Using systemd to manage containers can make service discovery and maintenance easier
-by managining all services in the same way.  Additionally, when using Podman, systemd
+by managing all services in the same way. Additionally, when using Podman, systemd
 can start the registry with socket-activation, providing additional security options:
+
 * Run as non-root and expose on a low-numbered socket (< 1024)
 * Run with `--network=none`
 
@@ -18,7 +19,8 @@ When deploying the registry via Docker, a simple service file can be used to man
 the registry:
 
 registry.service
-```
+
+```ini
 [Unit]
 Description=Docker registry
 After=docker.service
@@ -50,7 +52,7 @@ socket-activation of containers.
 
 #### Create service file
 
-```
+```sh
 podman create --name registry --network=none -v registry:/var/lib/registry registry:2
 podman generate systemd --name --new registry > registry.service
 ```
@@ -58,7 +60,8 @@ podman generate systemd --name --new registry > registry.service
 #### Create socket file
 
 registry.socket
-```
+
+```ini
 [Unit]
 Description=container registry
 

docs/content/spec/_index.md

@@ -6,7 +6,7 @@ keywords: registry, service, images, repository,  json
 
 # Docker Registry Reference
 
-* [HTTP API V2](api.md)
-* [Storage Driver](https://docs.docker.com/registry/storage-drivers/)
-* [Token Authentication Specification](auth/token.md)
-* [Token Authentication Implementation](auth/jwt.md)
+* [HTTP API V2](api)
+* [Storage Driver](/storage-drivers/)
+* [Token Authentication Specification](auth/token)
+* [Token Authentication Implementation](auth/jwt)

docs/content/spec/api.md.tmpl

@@ -2,7 +2,7 @@
 title: "HTTP API V2"
 description: "Specification for the Registry API."
 keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
-redirect_from:
+aliases:
   - /reference/api/registry_api/
 ---
 

docs/content/spec/auth/_index.md

@@ -6,7 +6,7 @@ keywords: registry, on-prem, images, tags, repository, distribution, authenticat
 
 # Docker Registry v2 authentication
 
-See the [Token Authentication Specification](token.md),
-[Token Authentication Implementation](jwt.md),
-[Token Scope Documentation](scope.md),
-[OAuth2 Token Authentication](oauth.md) for more information.
+See the [Token Authentication Specification](token),
+[Token Authentication Implementation](jwt),
+[Token Scope Documentation](scope),
+[OAuth2 Token Authentication](oauth) for more information.

docs/content/spec/auth/oauth.md

@@ -12,7 +12,7 @@ reference for the protocol and HTTP endpoints described here.
 
 **Note**: Not all token servers implement oauth2. If the request to the endpoint
 returns `404` using the HTTP `POST` method, refer to
-[Token Documentation](token.md) for using the HTTP `GET` method supported by all
+[Token Documentation](../token) for using the HTTP `GET` method supported by all
 token servers.
 
 ## Refresh token format
@@ -161,7 +161,7 @@ Content-Type: application/x-www-form-urlencoded
 
 #### Example getting refresh token
 
-```
+```none
 POST /token HTTP/1.1
 Host: auth.docker.io
 Content-Type: application/x-www-form-urlencoded
@@ -176,7 +176,7 @@ Content-Type: application/json
 
 #### Example refreshing an Access Token
 
-```
+```none
 POST /token HTTP/1.1
 Host: auth.docker.io
 Content-Type: application/x-www-form-urlencoded

docs/content/spec/auth/scope.md

@@ -41,10 +41,11 @@ is authorized for a specific resource.
 
 #### Resource Class
 
-> [!WARNING]
-> Resource Class is deprecated and ignored.
-> `repository` and `repository(plugin)` are considered equal when authorizing a token.
-> Authorization services should no longer return scopes with a resource class.
+{{< hint type=warning >}}
+Resource Class is deprecated and ignored.
+`repository` and `repository(plugin)` are considered equal when authorizing a token.
+Authorization services should no longer return scopes with a resource class.
+{{< /hint >}}
 
 The resource type might have a resource class which further classifies the
 the resource name within the resource type. A class is not required and
@@ -108,11 +109,13 @@ Full reference grammar is defined
 [here](https://pkg.go.dev/github.com/distribution/distribution/reference). Currently
 the scope name grammar is a subset of the reference grammar.
 
-> **NOTE:** that the `resourcename` may contain one `:` due to a possible port
-> number in the hostname component of the `resourcename`, so a naive
-> implementation that interprets the first three `:`-delimited tokens of a
-> `scope` to be the `resourcetype`, `resourcename`, and a list of `action`
-> would be insufficient.
+{{< hint type=note >}}
+Note that the `resourcename` may contain one `:` due to a possible port
+number in the hostname component of the `resourcename`, so a naive
+implementation that interprets the first three `:`-delimited tokens of a
+`scope` to be the `resourcetype`, `resourcename`, and a list of `action`
+would be insufficient.
+{{< /hint >}}
 
 ## Resource Provider Use
 
@@ -141,7 +144,7 @@ Each JWT access token may only have a single subject and audience but multiple
 resource scopes. The subject and audience are put into standard JWT fields
 `sub` and `aud`. The resource scope is put into the `access` field. The
 structure of the access field can be seen in the
-[jwt documentation](jwt.md).
+[jwt documentation](../jwt).
 
 ## Refresh Tokens
 

docs/content/spec/auth/token.md

@@ -8,7 +8,7 @@ keywords: registry, on-prem, images, tags, repository, distribution, Bearer auth
 
 This document outlines the v2 Docker registry authentication scheme:
 
-![v2 registry auth](../images/v2-registry-auth.png)
+![v2 registry auth](/images/v2-registry-auth.png)
 
 1. Attempt to begin a push/pull operation with the registry.
 2. If the registry requires authorization it will return a `401 Unauthorized`
@@ -191,7 +191,7 @@ https://auth.docker.io/token?service=registry.docker.io&scope=repository:samalba
 
 The token server should first attempt to authenticate the client using any
 authentication credentials provided with the request. From Docker 1.11 the
-Docker engine supports both Basic Authentication and [OAuth2](oauth.md) for
+Docker engine supports both Basic Authentication and [OAuth2](../oauth) for
 getting tokens. Docker 1.10 and before, the registry client in the Docker Engine
 only supports Basic Authentication. If an attempt to authenticate to the token
 server fails, the token server should return a `401 Unauthorized` response

docs/content/spec/deprecated-schema-v1.md

@@ -1,10 +1,9 @@
 ---
-title: Update deprecated schema image manifest version 2, v1 images
-description: Update deprecated schema v1 iamges
+title: Image manifest version 2, schema 1
+description: Update deprecated schema v1 images
 keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
 ---
 
-## Image manifest version 2, schema 1
 With the release of image manifest version 2, schema 2, image manifest version
 2, schema 1 has been deprecated. This could lead to compatibility and
 vulnerability issues in images that haven't been updated to image manifest
@@ -17,7 +16,7 @@ associated with  the deprecated image manifest that will block your image from
 running successfully. A list of possible methods to help update your image is
 also included below.
 
-### Update to image manifest version 2, schema 2
+## Update to image manifest version 2, schema 2
 
 One way to upgrade an image from image manifest version 2, schema 1 to
 schema 2 is to `docker pull` the image and then `docker push` the image with a
@@ -29,8 +28,7 @@ manifest format, but does not update the contents within the image. Images
 using manifest version 2, schema 1 may contain unpatched vulnerabilities. We
 recommend looking for an alternative image or rebuilding it.
 
-
-### Update FROM statement
+## Update FROM statement
 
 You can rebuild the image by updating the `FROM` statement in your
 `Dockerfile`. If your image manifest is out-of-date, there is a chance the

docs/content/spec/implementations.md

@@ -1,5 +1,5 @@
 ---
-published: false
+draft: true
 ---
 
 # Distribution API Implementations

docs/content/spec/json.md

@@ -1,5 +1,5 @@
 ---
-published: false
+draft: true
 title: "Docker Distribution JSON Canonicalization"
 description: "Explains registry JSON objects"
 keywords: ["registry, service, images, repository,  json"]

docs/content/spec/manifest-v2-2.md

@@ -10,7 +10,7 @@ This document outlines the format of the V2 image manifest, schema version 2.
 The original (and provisional) image manifest for V2 (schema 1), was introduced
 in the Docker daemon in the [v1.3.0
 release](https://github.com/docker/docker/commit/9f482a66ab37ec396ac61ed0c00d59122ac07453)
-and is specified in the [schema 1 manifest definition](manifest-v2-1.md)
+and is now deprecated.
 
 This second schema version has two primary goals. The first is to allow
 multi-architecture images, through a "fat manifest" which references image
@@ -71,7 +71,7 @@ image manifest based on the Content-Type returned in the HTTP response.
     - **`digest`** *string*
 
         The digest of the content, as defined by the
-        [Registry V2 HTTP API Specificiation](api.md#digest-parameter).
+        [Registry V2 HTTP API Specificiation](../api#digest-parameter).
 
     - **`platform`** *object*
 
@@ -113,7 +113,8 @@ image manifest based on the Content-Type returned in the HTTP response.
 
 ## Example Manifest List
 
-*Example showing a simple manifest list pointing to image manifests for two platforms:*
+Example showing a simple manifest list pointing to image manifests for two platforms:
+
 ```json
 {
   "schemaVersion": 2,
@@ -186,7 +187,7 @@ image. It's the direct replacement for the schema-1 manifest.
     - **`digest`** *string*
 
         The digest of the content, as defined by the
-        [Registry V2 HTTP API Specificiation](api.md#digest-parameter).
+        [Registry V2 HTTP API Specificiation](../api#digest-parameter).
 
 - **`layers`** *array*
 
@@ -212,7 +213,7 @@ image. It's the direct replacement for the schema-1 manifest.
     - **`digest`** *string*
 
         The digest of the content, as defined by the
-        [Registry V2 HTTP API Specificiation](api.md#digest-parameter).
+        [Registry V2 HTTP API Specificiation](../api#digest-parameter).
 
     - **`urls`** *array*
 
@@ -222,7 +223,8 @@ image. It's the direct replacement for the schema-1 manifest.
 
 ## Example Image Manifest
 
-*Example showing an image manifest:*
+Example showing an image manifest:
+
 ```json
 {
     "schemaVersion": 2,

docs/content/spec/menu.md

@@ -1,7 +0,0 @@
----
-title: "Reference"
-description: "Explains registry JSON objects"
-keywords: registry, service, images, repository, json
-type: "menu"
-identifier: "smn_registry_ref"
----

docs/content/storage-drivers/_index.md

@@ -1,8 +1,6 @@
 ---
 description: Explains how to use storage drivers
 keywords: registry, on-prem, images, tags, repository, distribution, storage drivers, advanced
-redirect_from:
-- /registry/storagedrivers/
 title: Registry storage driver
 ---
 
@@ -12,11 +10,11 @@ This document describes the registry storage driver model, implementation, and e
 
 This storage driver package comes bundled with several drivers:
 
-- [inmemory](inmemory.md): A temporary storage driver using a local inmemory map. This exists solely for reference and testing.
-- [filesystem](filesystem.md): A local storage driver configured to use a directory tree in the local filesystem.
-- [s3](s3.md): A driver storing objects in an Amazon Simple Storage Service (S3) bucket.
-- [azure](azure.md): A driver storing objects in [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/).
-- [gcs](gcs.md): A driver storing objects in a [Google Cloud Storage](https://cloud.google.com/storage/) bucket.
+- [inmemory](inmemory): A temporary storage driver using a local inmemory map. This exists solely for reference and testing.
+- [filesystem](filesystem): A local storage driver configured to use a directory tree in the local filesystem.
+- [s3](s3): A driver storing objects in an Amazon Simple Storage Service (S3) bucket.
+- [azure](azure): A driver storing objects in [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/).
+- [gcs](gcs): A driver storing objects in a [Google Cloud Storage](https://cloud.google.com/storage/) bucket.
 - oss: *NO LONGER SUPPORTED*
 - swift: *NO LONGER SUPPORTED*
 
@@ -41,16 +39,17 @@ with a driver name and parameters map. If no such storage driver can be found,
 ## Driver contribution
 
 New storage drivers are not currently being accepted.
-See https://github.com/distribution/distribution/issues/3988 for discussion.
+See <https://github.com/distribution/distribution/issues/3988> for discussion.
 
 There are forks of this repo that implement custom storage drivers.
 These are not supported by the OCI distribution project.
 The known forks are:
-- Storj DCS: https://github.com/storj/docker-registry
-- HuaweiCloud OBS: https://github.com/setoru/distribution/tree/obs
-- us3: https://github.com/lambertxiao/distribution/tree/main
-- Baidu BOS: https://github.com/dolfly/distribution/tree/bos
-- HDFS: https://github.com/haosdent/distribution/tree/master
+
+- Storj DCS: <https://github.com/storj/docker-registry>
+- HuaweiCloud OBS: <https://github.com/setoru/distribution/tree/obs>
+- us3: <https://github.com/lambertxiao/distribution/tree/main>
+- Baidu BOS: <https://github.com/dolfly/distribution/tree/bos>
+- HDFS: <https://github.com/haosdent/distribution/tree/master>
 
 ### Writing new storage drivers
 

docs/content/storage-drivers/gcs.md

@@ -15,5 +15,6 @@ An implementation of the `storagedriver.StorageDriver` interface which uses Goog
 | `rootdirectory`  | no | The root directory tree in which all registry files are stored. Defaults to the empty string (bucket root). If a prefix is used, the path `bucketname/<prefix>` has to be pre-created before starting the registry. The prefix is applied to all Google Cloud Storage keys to allow you to segment data in your bucket if necessary.|
 | `chunksize`  | no (default 5242880) | This is the chunk size used for uploading large blobs, must be a multiple of 256*1024. |
 
-**Note:** Instead of a key file you can use [Google Application Default Credentials](https://developers.google.com/identity/protocols/application-default-credentials).
-
+{{< hint type=note >}}
+Instead of a key file you can use [Google Application Default Credentials](https://developers.google.com/identity/protocols/application-default-credentials).
+{{< /hint >}}

docs/content/storage-drivers/inmemory.md

@@ -7,9 +7,11 @@ title: In-memory storage driver (testing only)
 For purely tests purposes, you can use the `inmemory` storage driver. This
 driver is an implementation of the `storagedriver.StorageDriver` interface which
 uses local memory for object storage. If you would like to run a registry from
-volatile memory, use the [`filesystem` driver](filesystem.md) on a ramdisk.
+volatile memory, use the [`filesystem` driver](../filesystem) on a ramdisk.
 
-**IMPORTANT**: This storage driver *does not* persist data across runs. This is why it is only suitable for testing. *Never* use this driver in production.
+{{< hint type=important >}}
+This storage driver *does not* persist data across runs. This is why it is only suitable for testing. *Never* use this driver in production.
+{{< /hint >}}
 
 ## Parameters
 

docs/content/storage-drivers/s3.md

@@ -11,8 +11,8 @@ Amazon S3 or S3 compatible services for object storage.
 
 | Parameter     | Required | Description                                                                                                                                                                                                                                                         |
 |:--------------|:---------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `accesskey` | no     | Your AWS Access Key. If you use [IAM roles](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), omit to fetch temporary credentials from IAM. |
-| `secretkey`  | no   | Your AWS Secret Key. If you use [IAM roles](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), omit to fetch temporary credentials from IAM. |
+| `accesskey` | no     | Your AWS Access Key. If you use [IAM roles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), omit to fetch temporary credentials from IAM. |
+| `secretkey`  | no   | Your AWS Secret Key. If you use [IAM roles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), omit to fetch temporary credentials from IAM. |
 | `region` |  yes  | The AWS region in which your bucket exists. |
 | `regionendpoint` | no | Endpoint for S3 compatible storage services (Minio, etc). |
 | `forcepathstyle` | no | To enable path-style addressing when the value is set to `true`. The default is `true`. |
@@ -30,10 +30,10 @@ Amazon S3 or S3 compatible services for object storage.
 
 > **Note** You can provide empty strings for your access and secret keys to run the driver
 > on an ec2 instance and handles authentication with the instance's credentials. If you
-> use [IAM roles](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html),
+> use [IAM roles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html),
 > omit these keys to fetch temporary credentials from IAM.
 
-`region`: The name of the aws region in which you would like to store objects (for example `us-east-1`). For a list of regions, see [Regions, Availability Zones, and Local Zones](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
+`region`: The name of the aws region in which you would like to store objects (for example `us-east-1`). For a list of regions, see [Regions, Availability Zones, and Local Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
 
 `regionendpoint`: (optional) Endpoint URL for S3 compatible APIs. This should not be provided when using Amazon S3.
 
@@ -55,7 +55,7 @@ Amazon S3 or S3 compatible services for object storage.
 
 `storageclass`: (optional) The storage class applied to each registry file. Defaults to STANDARD. Valid options are STANDARD and REDUCED_REDUNDANCY.
 
-`objectacl`: (optional) The canned object ACL to be applied to each registry object. Defaults to `private`. If you are using a bucket owned by another AWS account, it is recommended that you set this to `bucket-owner-full-control` so that the bucket owner can access your objects. Other valid options are available in the [AWS S3 documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl).
+`objectacl`: (optional) The canned object ACL to be applied to each registry object. Defaults to `private`. If you are using a bucket owned by another AWS account, it is recommended that you set this to `bucket-owner-full-control` so that the bucket owner can access your objects. Other valid options are available in the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl).
 
 `loglevel`: (optional) Valid values are: `off` (default), `debug`, `debugwithsigning`, `debugwithhttpbody`, `debugwithrequestretries`, `debugwithrequesterrors` and `debugwitheventstreambody`. See the [AWS SDK for Go API reference](https://docs.aws.amazon.com/sdk-for-go/api/aws/#LogLevelType) for details.
 
@@ -91,7 +91,7 @@ The following AWS policy is required by the registry for push and pull. Make sur
 }
 ```
 
-See [the S3 policy documentation](http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuAndPermissions.html) for more details.
+See [the S3 policy documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuAndPermissions.html) for more details.
 
 # CloudFront as Middleware with S3 backend
 
@@ -112,7 +112,7 @@ to see whether you need CloudFront or S3 Transfer Acceleration.
 
 If you are unfamiliar with creating a CloudFront distribution, see [Getting
 Started with
-Cloudfront](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
+Cloudfront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
 
 Defaults can be kept in most areas except:
 
@@ -162,4 +162,4 @@ middleware:
 
 A CloudFront key-pair is required for all AWS accounts needing access to your
 CloudFront distribution. You must have access to your AWS account's root credentials to create the required Cloudfront keypair. For information, see [Creating CloudFront Key
-Pairs](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).
+Pairs](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).

docs/hugo.yaml

@@ -1,4 +1,4 @@
-baseURL: https://example.com/
+baseURL: /
 languageCode: en-us
 title: CNCF Distribution
 theme: hugo-geekdoc