diff --git a/docs/docker-hub/accounts.md b/docs/docker-hub/accounts.md
deleted file mode 100644
index a9694f2c76..0000000000
--- a/docs/docker-hub/accounts.md
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-# Accounts on Docker Hub
-
-## Docker Hub accounts
-
-You can `search` for Docker images and `pull` them from [Docker
-Hub](https://hub.docker.com) without signing in or even having an
-account. However, in order to `push` images, leave comments or to *star*
-a repository, you are going to need a [Docker
-Hub](https://hub.docker.com) account.
-
-### Registration for a Docker Hub account
-
-You can get a [Docker Hub](https://hub.docker.com) account by
-[signing up for one here](https://hub.docker.com/account/signup/). A valid
-email address is required to register, which you will need to verify for
-account activation.
-
-### Email activation process
-
-You need to have at least one verified email address to be able to use your
-[Docker Hub](https://hub.docker.com) account. If you can't find the validation email,
-you can request another by visiting the [Resend Email Confirmation](
-https://hub.docker.com/account/resend-email-confirmation/) page.
-
-### Password reset process
-
-If you can't access your account for some reason, you can reset your password
-from the [*Password Reset*](https://hub.docker.com/account/forgot-password/)
-page.
-
-## Organizations and groups
-
-A Docker Hub organization contains public and private repositories just like
-a user account. Access to push, pull or create these organisation owned repositories
-is allocated by defining groups of users and then assigning group rights to
-specific repositories. This allows you to distribute limited access
-Docker images, and to select which Docker Hub users can publish new images.
-
-### Creating and viewing organizations
-
-You can see what organizations [you belong to and add new organizations](
-https://hub.docker.com/account/organizations/) from the Account Settings
-tab. They are also listed below your user name on your repositories page
-and in your account profile.
-
-
-
-### Organization groups
-
-Users in the `Owners` group of an organization can create and modify the
-membership of groups.
-
-Unless they are the organization's `Owner`, users can only see groups of which they
-are members.
-
-
-
-### Repository group permissions
-
-Use organization groups to manage the users that can interact with your repositories.
-
-You must be in an organization's `Owners` group to create a new group, Hub
-repository, or automated build. As an `Owner`, you then delegate the following
-repository access rights to groups:
-
-| Access Right | Description |
-|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `Read` | Users with this right can view, search, and pull a private repository. |
-| `Write` | Users with this right can push to non-automated repositories on the Docker Hub. |
-| `Admin` | Users with this right can modify a repository's "Description", "Collaborators" rights. They can also mark a repository as unlisted, change its "Public/Private" status and "Delete" the repository. Finally, `Admin` rights are required to read the build log on a repo. |
-| | |
-
-Regardless of their actual access rights, users with unverified email addresses
-have `Read` access to the repository. Once they have verified their address,
-they have their full access rights as granted on the organization.
diff --git a/docs/docker-hub/builds.md b/docs/docker-hub/builds.md
deleted file mode 100644
index 015fcef1ef..0000000000
--- a/docs/docker-hub/builds.md
+++ /dev/null
@@ -1,465 +0,0 @@
-
-
-# Automated Builds on Docker Hub
-
-## About Automated Builds
-
-*Automated Builds* are a special feature of Docker Hub which allow you to
-use [Docker Hub's](https://hub.docker.com) build clusters to automatically
-create images from a GitHub or Bitbucket repository containing a `Dockerfile`
-The system will clone your repository and build the image described by the
-`Dockerfile` using the directory the `Dockerfile` is in (and subdirectories)
-as the build context. The resulting automated image will then be uploaded
-to the Docker Hub registry and marked as an *Automated Build*.
-
-Automated Builds have several advantages:
-
-* Users of *your* Automated Build can trust that the resulting
-image was built exactly as specified.
-* The `Dockerfile` will be available to anyone with access to
-your repository on the Docker Hub registry.
-* Because the process is automated, Automated Builds help to
-make sure that your repository is always up to date.
-* Not having to push local Docker images to Docker Hub saves
-you both network bandwidth and time.
-
-Automated Builds are supported for both public and private repositories
-on both [GitHub](http://github.com) and [Bitbucket](https://bitbucket.org/).
-
-To use Automated Builds, you must have an [account on Docker Hub](
-https://docs.docker.com/userguide/dockerhub/#creating-a-docker-hub-account)
-and on GitHub and/or Bitbucket. In either case, the account needs
-to be properly validated and activated before you can link to it.
-
-The first time you to set up an Automated Build, your
-[Docker Hub](https://hub.docker.com) account will need to be linked to
-a GitHub or Bitbucket account.
-This will allow the registry to see your repositories.
-
-If you have previously linked your Docker Hub account, and want to view or modify
-that link, click on the "Manage - Settings" link in the sidebar, and then
-"Linked Accounts" in your Settings sidebar.
-
-## Automated Builds from GitHub
-
-If you've previously linked your Docker Hub account to your GitHub account,
-you'll be able to skip to the [Creating an Automated Build](#creating-an-automated-build).
-
-### Linking your Docker Hub account to a GitHub account
-
-> *Note:*
-> Automated Builds currently require *read* and *write* access since
-> [Docker Hub](https://hub.docker.com) needs to setup a GitHub service
-> hook. We have no choice here, this is how GitHub manages permissions, sorry!
-> We do guarantee nothing else will be touched in your account.
-
-To get started, log into your Docker Hub account and click the
-"+ Add Repository" button at the upper right of the screen. Then select
-[Automated Build](https://registry.hub.docker.com/builds/add/).
-
-Select the [GitHub service](https://registry.hub.docker.com/associate/github/).
-
-When linking to GitHub, you'll need to select either "Public and Private",
-or "Limited" linking.
-
-The "Public and Private" option is the easiest to use,
-as it grants the Docker Hub full access to all of your repositories. GitHub
-also allows you to grant access to repositories belonging to your GitHub
-organizations.
-
-By choosing the "Limited" linking, your Docker Hub account only gets permission
-to access your public data and public repositories.
-
-Follow the onscreen instructions to authorize and link your
-GitHub account to Docker Hub. Once it is linked, you'll be able to
-choose a source repository from which to create the Automatic Build.
-
-You will be able to review and revoke Docker Hub's access by visiting the
-[GitHub User's Applications settings](https://github.com/settings/applications).
-
-> **Note**: If you delete the GitHub account linkage that is used for one of your
-> automated build repositories, the previously built images will still be available.
-> If you re-link to that GitHub account later, the automated build can be started
-> using the "Start Build" button on the Hub, or if the webhook on the GitHub repository
-> still exists, will be triggered by any subsequent commits.
-
-### Auto builds and limited linked GitHub accounts.
-
-If you selected to link your GitHub account with only a "Limited" link, then
-after creating your automated build, you will need to either manually trigger a
-Docker Hub build using the "Start a Build" button, or add the GitHub webhook
-manually, as described in [GitHub Service Hooks](#github-service-hooks).
-
-### Changing the GitHub user link
-
-If you want to remove, or change the level of linking between your GitHub account
-and the Docker Hub, you need to do this in two places.
-
-First, remove the "Linked Account" from your Docker Hub "Settings".
-Then go to your GitHub account's Personal settings, and in the "Applications"
-section, "Revoke access".
-
-You can now re-link your account at any time.
-
-### GitHub organizations
-
-GitHub organizations and private repositories forked from organizations will be
-made available to auto build using the "Docker Hub Registry" application, which
-needs to be added to the organization - and then will apply to all users.
-
-To check, or request access, go to your GitHub user's "Setting" page, select the
-"Applications" section from the left side bar, then click the "View" button for
-"Docker Hub Registry".
-
-
-
-The organization's administrators may need to go to the Organization's "Third
-party access" screen in "Settings" to Grant or Deny access to the Docker Hub
-Registry application. This change will apply to all organization members.
-
-
-
-More detailed access controls to specific users and GitHub repositories would be
-managed using the GitHub People and Teams interfaces.
-
-### Creating an Automated Build
-
-You can [create an Automated Build](
-https://registry.hub.docker.com/builds/github/select/) from any of your
-public or private GitHub repositories that have a `Dockerfile`.
-
-Once you've selected the source repository, you can then configure:
-
-- The Hub user/org the repository is built to - either your Hub account name,
-or the name of any Hub organizations your account is in
-- The Docker repository name the image is built to
-- If the Docker repository should be "Public" or "Private"
- You can change the accessibility options after the repository has been created.
- If you add a Private repository to a Hub user, then you can only add other users
- as collaborators, and those users will be able to view and pull all images in that
- repository. To configure more granular access permissions, such as using groups of
- users or allow different users access to different image tags, then you need
- to add the Private repository to a Hub organization that your user has Administrator
- privilege on.
-- If you want the GitHub to notify the Docker Hub when a commit is made, and thus trigger
- a rebuild of all the images in this automated build.
-
-You can also select one or more
-- The git branch/tag, which repository sub-directory to use as the context
-- The Docker image tag name
-
-You can set a description for the repository by clicking "Description" link in the righthand side bar after the automated build - note that the "Full Description" will be over-written next build from the README.md file.
-has been created.
-
-### GitHub private submodules
-
-If your GitHub repository contains links to private submodules, you'll get an
-error message in your build.
-
-Normally, the Docker Hub sets up a deploy key in your GitHub repository.
-Unfortunately, GitHub only allows a repository deploy key to access a single repository.
-
-To work around this, you need to create a dedicated user account in GitHub and attach
-the automated build's deploy key that account. This dedicated build account
-can be limited to read-only access to just the repositories required to build.
-
-
-
-
- Step |
- Screenshot |
- Description |
-
-
-
-
- 1. |
-  |
- First, create the new account in GitHub. It should be given read-only
- access to the main repository and all submodules that are needed. |
-
-
- 2. |
-  |
- This can be accomplished by adding the account to a read-only team in
- the organization(s) where the main GitHub repository and all submodule
- repositories are kept. |
-
-
- 3. |
-  |
- Next, remove the deploy key from the main GitHub repository. This can be done in the GitHub repository's "Deploy keys" Settings section. |
-
-
- 4. |
-  |
- Your automated build's deploy key is in the "Build Details" menu
- under "Deploy keys". |
-
-
- 5. |
-  |
- In your dedicated GitHub User account, add the deploy key from your
- Docker Hub Automated Build. |
-
-
-
-
-### GitHub service hooks
-
-The GitHub Service hook allows GitHub to notify the Docker Hub when something has
-been committed to that git repository. You will need to add the Service Hook manually
-if your GitHub account is "Limited" linked to the Docker Hub.
-
-Follow the steps below to configure the GitHub Service hooks for your Automated Build:
-
-
-
-
- Step |
- Screenshot |
- Description |
-
-
-
-
- 1. |
-  |
- Log in to GitHub.com, and go to your Repository page. Click on "Settings" on
- the right side of the page. You must have admin privileges to the repository in order to do this. |
-
-
- 2. |
-  |
- Click on "Webhooks & Services" on the left side of the page. |
- 3. |
-  |
- Find the service labeled "Docker" (or click on "Add service") and click on it. |
- 4. |
-  |
- Make sure the "Active" checkbox is selected and click the "Update service" button to save your changes. |
-
-
-
-
-## Automated Builds with Bitbucket
-
-In order to setup an Automated Build, you need to first link your
-[Docker Hub](https://hub.docker.com) account with a Bitbucket account.
-This will allow the registry to see your repositories.
-
-To get started, log into your Docker Hub account and click the
-"+ Add Repository" button at the upper right of the screen. Then
-select [Automated Build](https://registry.hub.docker.com/builds/add/).
-
-Select the [Bitbucket source](
-https://registry.hub.docker.com/associate/bitbucket/).
-
-Then follow the onscreen instructions to authorize and link your
-Bitbucket account to Docker Hub. Once it is linked, you'll be able
-to choose a repository from which to create the Automatic Build.
-
-### Creating an Automated Build
-
-You can [create an Automated Build](
-https://registry.hub.docker.com/builds/bitbucket/select/) from any of your
-public or private Bitbucket repositories with a `Dockerfile`.
-
-### Adding a Hook
-
-When you link your Docker Hub account, a `POST` hook should get automatically
-added to your Bitbucket repository. Follow the steps below to confirm or modify the
-Bitbucket hooks for your Automated Build:
-
-
-
-
- Step |
- Screenshot |
- Description |
-
-
-
-
- 1. |
-  |
- Log in to Bitbucket.org and go to your Repository page. Click on "Settings" on
- the far left side of the page, under "Navigation". You must have admin privileges
- to the repository in order to do this. |
-
-
- 2. |
-  |
- Click on "Hooks" on the near left side of the page, under "Settings". |
-
- 3. |
-  | You should now see a list of hooks associated with the repo, including a POST hook that points at
- registry.hub.docker.com/hooks/bitbucket. |
-
-
-
-
-
-## The Dockerfile and Automated Builds
-
-During the build process, Docker will copy the contents of your `Dockerfile`.
-It will also add it to the [Docker Hub](https://hub.docker.com) for the Docker
-community (for public repositories) or approved team members/orgs (for private
-repositories) to see on the repository page.
-
-### README.md
-
-If you have a `README.md` file in your repository, it will be used as the
-repository's full description.The build process will look for a
-`README.md` in the same directory as your `Dockerfile`.
-
-> **Warning:**
-> If you change the full description after a build, it will be
-> rewritten the next time the Automated Build has been built. To make changes,
-> modify the `README.md` from the Git repository.
-
-## Remote Build triggers
-
-If you need a way to trigger Automated Builds outside of GitHub or Bitbucket,
-you can set up a build trigger. When you turn on the build trigger for an
-Automated Build, it will give you a URL to which you can send POST requests.
-This will trigger the Automated Build, much as with a GitHub webhook.
-
-Build triggers are available under the Settings menu of each Automated Build
-repository on the Docker Hub.
-
-
-
-You can use `curl` to trigger a build:
-
-```
-$ curl --data "build=true" -X POST https://registry.hub.docker.com/u/svendowideit/testhook/trigger/be579c
-82-7c0e-11e4-81c4-0242ac110020/
-OK
-```
-
-> **Note:**
-> You can only trigger one build at a time and no more than one
-> every five minutes. If you already have a build pending, or if you
-> recently submitted a build request, those requests *will be ignored*.
-> To verify everything is working correctly, check the logs of last
-> ten triggers on the settings page .
-
-## Webhooks
-
-Automated Builds also include a Webhooks feature. Webhooks can be called
-after a successful repository push is made. This includes when a new tag is added
-to an existing image.
-
-The webhook call will generate a HTTP POST with the following JSON
-payload:
-
-```
-{
- "callback_url": "https://registry.hub.docker.com/u/svendowideit/testhook/hook/2141b5bi5i5b02bec211i4eeih0242eg11000a/",
- "push_data": {
- "images": [
- "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
- "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
- ...
- ],
- "pushed_at": 1.417566161e+09,
- "pusher": "trustedbuilder"
- },
- "repository": {
- "comment_count": 0,
- "date_created": 1.417494799e+09,
- "description": "",
- "dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\nMAINTAINER\u0009SvenDowideit@home.org.au\n\n\nVOLUME\u0009\u0009[\"/var/cache/apt-cacher-ng\"]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
- "full_description": "Docker Hub based automated build from a GitHub repo",
- "is_official": false,
- "is_private": true,
- "is_trusted": true,
- "name": "testhook",
- "namespace": "svendowideit",
- "owner": "svendowideit",
- "repo_name": "svendowideit/testhook",
- "repo_url": "https://registry.hub.docker.com/u/svendowideit/testhook/",
- "star_count": 0,
- "status": "Active"
- }
-}
-```
-
-Webhooks are available under the Settings menu of each Repository.
-Use a tool like [requestb.in](http://requestb.in/) to test your webhook.
-
-> **Note**: The Docker Hub servers use an elastic IP range, so you can't
-> filter requests by IP.
-
-### Webhook chains
-
-Webhook chains allow you to chain calls to multiple services. For example,
-you can use this to trigger a deployment of your container only after
-it has been successfully tested, then update a separate Changelog once the
-deployment is complete.
-After clicking the "Add webhook" button, simply add as many URLs as necessary
-in your chain.
-
-The first webhook in a chain will be called after a successful push. Subsequent
-URLs will be contacted after the callback has been validated.
-
-### Validating a callback
-
-In order to validate a callback in a webhook chain, you need to
-
-1. Retrieve the `callback_url` value in the request's JSON payload.
-1. Send a POST request to this URL containing a valid JSON body.
-
-> **Note**: A chain request will only be considered complete once the last
-> callback has been validated.
-
-To help you debug or simply view the results of your webhook(s),
-view the "History" of the webhook available on its settings page.
-
-### Callback JSON data
-
-The following parameters are recognized in callback data:
-
-* `state` (required): Accepted values are `success`, `failure` and `error`.
- If the state isn't `success`, the webhook chain will be interrupted.
-* `description`: A string containing miscellaneous information that will be
- available on the Docker Hub. Maximum 255 characters.
-* `context`: A string containing the context of the operation. Can be retrieved
- from the Docker Hub. Maximum 100 characters.
-* `target_url`: The URL where the results of the operation can be found. Can be
- retrieved on the Docker Hub.
-
-*Example callback payload:*
-
- {
- "state": "success",
- "description": "387 tests PASSED",
- "context": "Continuous integration by Acme CI",
- "target_url": "http://ci.acme.com/results/afd339c1c3d27"
- }
-
-## Repository links
-
-Repository links are a way to associate one Automated Build with
-another. If one gets updated, the linking system triggers a rebuild
-for the other Automated Build. This makes it easy to keep all your
-Automated Builds up to date.
-
-To add a link, go to the repository for the Automated Build you want to
-link to and click on *Repository Links* under the Settings menu at
-right. Then, enter the name of the repository that you want have linked.
-
-> **Warning:**
-> You can add more than one repository link, however, you should
-> do so very carefully. Creating a two way relationship between Automated Builds will
-> cause an endless build loop.
diff --git a/docs/docker-hub/home.md b/docs/docker-hub/home.md
deleted file mode 100644
index c2e44e17a4..0000000000
--- a/docs/docker-hub/home.md
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
-# The Docker Hub Registry help
-
-## Introduction
-
-For your questions about the [Docker Hub](https://hub.docker.com) registry you
-can use [this documentation](docs.md).
-
-If you can not find something you are looking for, please feel free to
-[contact us](https://docker.com/resources/support/).
diff --git a/docs/docker-hub/hub-images/bb_hooks.png b/docs/docker-hub/hub-images/bb_hooks.png
deleted file mode 100644
index 9efe4907f5..0000000000
Binary files a/docs/docker-hub/hub-images/bb_hooks.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/bb_menu.png b/docs/docker-hub/hub-images/bb_menu.png
deleted file mode 100644
index fba1a03a5d..0000000000
Binary files a/docs/docker-hub/hub-images/bb_menu.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/bb_post-hook.png b/docs/docker-hub/hub-images/bb_post-hook.png
deleted file mode 100644
index 53100dbbce..0000000000
Binary files a/docs/docker-hub/hub-images/bb_post-hook.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/build-trigger.png b/docs/docker-hub/hub-images/build-trigger.png
deleted file mode 100644
index 02caf51adb..0000000000
Binary files a/docs/docker-hub/hub-images/build-trigger.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/dashboard.png b/docs/docker-hub/hub-images/dashboard.png
deleted file mode 100644
index 924799ddce..0000000000
Binary files a/docs/docker-hub/hub-images/dashboard.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/deploy_key.png b/docs/docker-hub/hub-images/deploy_key.png
deleted file mode 100644
index f1d8d92d22..0000000000
Binary files a/docs/docker-hub/hub-images/deploy_key.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh-check-admin-org-dh-app-access.png b/docs/docker-hub/hub-images/gh-check-admin-org-dh-app-access.png
deleted file mode 100644
index 0df38c6946..0000000000
Binary files a/docs/docker-hub/hub-images/gh-check-admin-org-dh-app-access.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh-check-user-org-dh-app-access.png b/docs/docker-hub/hub-images/gh-check-user-org-dh-app-access.png
deleted file mode 100644
index f24424af99..0000000000
Binary files a/docs/docker-hub/hub-images/gh-check-user-org-dh-app-access.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_add_ssh_user_key.png b/docs/docker-hub/hub-images/gh_add_ssh_user_key.png
deleted file mode 100644
index 3926fcf18f..0000000000
Binary files a/docs/docker-hub/hub-images/gh_add_ssh_user_key.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_docker-service.png b/docs/docker-hub/hub-images/gh_docker-service.png
deleted file mode 100644
index 7a84c81b7e..0000000000
Binary files a/docs/docker-hub/hub-images/gh_docker-service.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_menu.png b/docs/docker-hub/hub-images/gh_menu.png
deleted file mode 100644
index 84458a445f..0000000000
Binary files a/docs/docker-hub/hub-images/gh_menu.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_org_members.png b/docs/docker-hub/hub-images/gh_org_members.png
deleted file mode 100644
index 465f5da565..0000000000
Binary files a/docs/docker-hub/hub-images/gh_org_members.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_repo_deploy_key.png b/docs/docker-hub/hub-images/gh_repo_deploy_key.png
deleted file mode 100644
index 983b5eec77..0000000000
Binary files a/docs/docker-hub/hub-images/gh_repo_deploy_key.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_service_hook.png b/docs/docker-hub/hub-images/gh_service_hook.png
deleted file mode 100644
index c344c24afc..0000000000
Binary files a/docs/docker-hub/hub-images/gh_service_hook.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_settings.png b/docs/docker-hub/hub-images/gh_settings.png
deleted file mode 100644
index 2af9cb5138..0000000000
Binary files a/docs/docker-hub/hub-images/gh_settings.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/gh_team_members.png b/docs/docker-hub/hub-images/gh_team_members.png
deleted file mode 100644
index 3bdf4abd95..0000000000
Binary files a/docs/docker-hub/hub-images/gh_team_members.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/groups.png b/docs/docker-hub/hub-images/groups.png
deleted file mode 100644
index 272ab23ca9..0000000000
Binary files a/docs/docker-hub/hub-images/groups.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/hub.png b/docs/docker-hub/hub-images/hub.png
deleted file mode 100644
index 354a9cde28..0000000000
Binary files a/docs/docker-hub/hub-images/hub.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/invite.png b/docs/docker-hub/hub-images/invite.png
deleted file mode 100644
index c58b4abf12..0000000000
Binary files a/docs/docker-hub/hub-images/invite.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/org-repo-collaborators.png b/docs/docker-hub/hub-images/org-repo-collaborators.png
deleted file mode 100644
index 3e25475fc4..0000000000
Binary files a/docs/docker-hub/hub-images/org-repo-collaborators.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/orgs.png b/docs/docker-hub/hub-images/orgs.png
deleted file mode 100644
index ffd368c206..0000000000
Binary files a/docs/docker-hub/hub-images/orgs.png and /dev/null differ
diff --git a/docs/docker-hub/hub-images/repos.png b/docs/docker-hub/hub-images/repos.png
deleted file mode 100644
index c07c3d1f1c..0000000000
Binary files a/docs/docker-hub/hub-images/repos.png and /dev/null differ
diff --git a/docs/docker-hub/index.md b/docs/docker-hub/index.md
deleted file mode 100644
index 42b1a4c8c2..0000000000
--- a/docs/docker-hub/index.md
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-# Docker Hub
-
-The [Docker Hub](https://hub.docker.com) provides a cloud-based platform service
-for distributed applications, including container image distribution and change
-management, user and team collaboration, and lifecycle workflow automation.
-
-
-
-## [Finding and pulling images](./userguide.md)
-
-Find out how to [use the Docker Hub](./userguide.md) to find and pull Docker
-images to run or build upon.
-
-## [Accounts](./accounts.md)
-
-[Learn how to create](./accounts.md) a Docker Hub
-account and manage your organizations and groups.
-
-## [Your Repositories](./repos.md)
-
-Find out how to share your Docker images in [Docker Hub
-repositories](./repos.md) and how to store and manage private images.
-
-## [Automated builds](./builds.md)
-
-Learn how to automate your build and deploy pipeline with [Automated
-Builds](./builds.md)
-
diff --git a/docs/docker-hub/official_repos.md b/docs/docker-hub/official_repos.md
deleted file mode 100644
index 0bb2486506..0000000000
--- a/docs/docker-hub/official_repos.md
+++ /dev/null
@@ -1,113 +0,0 @@
-
-
-# Official Repositories on Docker Hub
-
-The Docker [Official Repositories](http://registry.hub.docker.com/official) are
-a curated set of Docker repositories that are promoted on Docker Hub. They are
-designed to:
-
-* Provide essential base OS repositories (for example,
- [`ubuntu`](https://registry.hub.docker.com/_/ubuntu/),
- [`centos`](https://registry.hub.docker.com/_/centos/)) that serve as the
- starting point for the majority of users.
-
-* Provide drop-in solutions for popular programming language runtimes, data
- stores, and other services, similar to what a Platform-as-a-Service (PAAS)
- would offer.
-
-* Exemplify [`Dockerfile` best practices](/articles/dockerfile_best-practices)
- and provide clear documentation to serve as a reference for other `Dockerfile`
- authors.
-
-* Ensure that security updates are applied in a timely manner. This is
- particularly important as many Official Repositories are some of the most
- popular on Docker Hub.
-
-* Provide a channel for software vendors to redistribute up-to-date and
- supported versions of their products. Organization accounts on Docker Hub can
- also serve this purpose, without the careful review or restrictions on what
- can be published.
-
-Docker, Inc. sponsors a dedicated team that is responsible for reviewing and
-publishing all Official Repositories content. This team works in collaboration
-with upstream software maintainers, security experts, and the broader Docker
-community.
-
-While it is preferable to have upstream software authors maintaining their
-corresponding Official Repositories, this is not a strict requirement. Creating
-and maintaining images for Official Repositories is a public process. It takes
-place openly on GitHub where participation is encouraged. Anyone can provide
-feedback, contribute code, suggest process changes, or even propose a new
-Official Repository.
-
-## Should I use Official Repositories?
-
-New Docker users are encouraged to use the Official Repositories in their
-projects. These repositories have clear documentation, promote best practices,
-and are designed for the most common use cases. Advanced users are encouraged to
-review the Official Repositories as part of their `Dockerfile` learning process.
-
-A common rationale for diverging from Official Repositories is to optimize for
-image size. For instance, many of the programming language stack images contain
-a complete build toolchain to support installation of modules that depend on
-optimized code. An advanced user could build a custom image with just the
-necessary pre-compiled libraries to save space.
-
-A number of language stacks such as
-[`python`](https://registry.hub.docker.com/_/python/) and
-[`ruby`](https://registry.hub.docker.com/_/ruby/) have `-slim` tag variants
-designed to fill the need for optimization. Even when these "slim" variants are
-insufficient, it is still recommended to inherit from an Official Repository
-base OS image to leverage the ongoing maintenance work, rather than duplicating
-these efforts.
-
-## How can I get involved?
-
-All Official Repositories contain a **User Feedback** section in their
-documentation which covers the details for that specific repository. In most
-cases, the GitHub repository which contains the Dockerfiles for an Official
-Repository also has an active issue tracker. General feedback and support
-questions should be directed to `#docker-library` on Freenode IRC.
-
-## How do I create a new Official Repository?
-
-From a high level, an Official Repository starts out as a proposal in the form
-of a set of GitHub pull requests. You'll find detailed and objective proposal
-requirements in the following GitHub repositories:
-
-* [docker-library/official-images](https://github.com/docker-library/official-images)
-
-* [docker-library/docs](https://github.com/docker-library/docs)
-
-The Official Repositories team, with help from community contributors, formally
-review each proposal and provide feedback to the author. This initial review
-process may require a bit of back and forth before the proposal is accepted.
-
-There are also subjective considerations during the review process. These
-subjective concerns boil down to the basic question: "is this image generally
-useful?" For example, the [`python`](https://registry.hub.docker.com/_/python/)
-Official Repository is "generally useful" to the large Python developer
-community, whereas an obscure text adventure game written in Python last week is
-not.
-
-When a new proposal is accepted, the author becomes responsible for keeping
-their images up-to-date and responding to user feedback. The Official
-Repositories team becomes responsible for publishing the images and
-documentation on Docker Hub. Updates to the Official Repository follow the same
-pull request process, though with less review. The Official Repositories team
-ultimately acts as a gatekeeper for all changes, which helps mitigate the risk
-of quality and security issues from being introduced.
-
-> **Note**: If you are interested in proposing an Official Repository, but would
-> like to discuss it with Docker, Inc. privately first, please send your
-> inquiries to partners@docker.com. There is no fast-track or pay-for-status
-> option.
diff --git a/docs/docker-hub/repos.md b/docs/docker-hub/repos.md
deleted file mode 100644
index 0bddc02bd2..0000000000
--- a/docs/docker-hub/repos.md
+++ /dev/null
@@ -1,193 +0,0 @@
-
-
-# Your Hub repositories
-
-Docker Hub repositories make it possible for you to share images with co-workers,
-customers or the Docker community at large. If you're building your images internally,
-either on your own Docker daemon, or using your own Continuous integration services,
-you can push them to a Docker Hub repository that you add to your Docker Hub user or
-organization account.
-
-Alternatively, if the source code for your Docker image is on GitHub or Bitbucket,
-you can use an "Automated build" repository, which is built by the Docker Hub
-services. See the [automated builds documentation](./builds.md) to read about
-the extra functionality provided by those services.
-
-
-
-Your Docker Hub repositories have a number of useful features.
-
-## Stars
-
-Your repositories can be starred and you can star repositories in
-return. Stars are a way to show that you like a repository. They are
-also an easy way of bookmarking your favorites.
-
-## Comments
-
-You can interact with other members of the Docker community and maintainers by
-leaving comments on repositories. If you find any comments that are not
-appropriate, you can flag them for review.
-
-## Collaborators and their role
-
-A collaborator is someone you want to give access to a private
-repository. Once designated, they can `push` and `pull` to your
-repositories. They will not be allowed to perform any administrative
-tasks such as deleting the repository or changing its status from
-private to public.
-
-> **Note:**
-> A collaborator cannot add other collaborators. Only the owner of
-> the repository has administrative access.
-
-You can also assign more granular collaborator rights ("Read", "Write", or "Admin")
-on Docker Hub by using organizations and groups. For more information
-see the [accounts documentation](accounts/).
-
-## Private repositories
-
-Private repositories allow you to have repositories that contain images
-that you want to keep private, either to your own account or within an
-organization or group.
-
-To work with a private repository on [Docker
-Hub](https://hub.docker.com), you will need to add one via the [Add
-Repository](https://registry.hub.docker.com/account/repositories/add/)
-link. You get one private repository for free with your Docker Hub
-account. If you need more accounts you can upgrade your [Docker
-Hub](https://registry.hub.docker.com/plans/) plan.
-
-Once the private repository is created, you can `push` and `pull` images
-to and from it using Docker.
-
-> *Note:* You need to be signed in and have access to work with a
-> private repository.
-
-Private repositories are just like public ones. However, it isn't
-possible to browse them or search their content on the public registry.
-They do not get cached the same way as a public repository either.
-
-It is possible to give access to a private repository to those whom you
-designate (i.e., collaborators) from its Settings page. From there, you
-can also switch repository status (*public* to *private*, or
-vice-versa). You will need to have an available private repository slot
-open before you can do such a switch. If you don't have any available,
-you can always upgrade your [Docker
-Hub](https://registry.hub.docker.com/plans/) plan.
-
-## Webhooks
-
-A webhook is an HTTP call-back triggered by a specific event.
-You can use a Hub repository webhook to notify people, services, and other
-applications after a new image is pushed to your repository (this also happens
-for Automated builds). For example, you can trigger an automated test or
-deployment to happen as soon as the image is available.
-
-To get started adding webhooks, go to the desired repository in the Hub,
-and click "Webhooks" under the "Settings" box.
-A webhook is called only after a successful `push` is
-made. The webhook calls are HTTP POST requests with a JSON payload
-similar to the example shown below.
-
-*Example webhook JSON payload:*
-
-```
-{
- "callback_url": "https://registry.hub.docker.com/u/svendowideit/busybox/hook/2141bc0cdec4hebec411i4c1g40242eg110020/",
- "push_data": {
- "images": [
- "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
- "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
- ...
- ],
- "pushed_at": 1.417566822e+09,
- "pusher": "svendowideit"
- },
- "repository": {
- "comment_count": 0,
- "date_created": 1.417566665e+09,
- "description": "",
- "full_description": "webhook triggered from a 'docker push'",
- "is_official": false,
- "is_private": false,
- "is_trusted": false,
- "name": "busybox",
- "namespace": "svendowideit",
- "owner": "svendowideit",
- "repo_name": "svendowideit/busybox",
- "repo_url": "https://registry.hub.docker.com/u/svendowideit/busybox/",
- "star_count": 0,
- "status": "Active"
-}
-```
-
-
-
-For testing, you can try an HTTP request tool like [requestb.in](http://requestb.in/).
-
-> **Note**: The Docker Hub servers use an elastic IP range, so you can't
-> filter requests by IP.
-
-### Webhook chains
-
-Webhook chains allow you to chain calls to multiple services. For example,
-you can use this to trigger a deployment of your container only after
-it has been successfully tested, then update a separate Changelog once the
-deployment is complete.
-After clicking the "Add webhook" button, simply add as many URLs as necessary
-in your chain.
-
-The first webhook in a chain will be called after a successful push. Subsequent
-URLs will be contacted after the callback has been validated.
-
-### Validating a callback
-
-In order to validate a callback in a webhook chain, you need to
-
-1. Retrieve the `callback_url` value in the request's JSON payload.
-1. Send a POST request to this URL containing a valid JSON body.
-
-> **Note**: A chain request will only be considered complete once the last
-> callback has been validated.
-
-To help you debug or simply view the results of your webhook(s),
-view the "History" of the webhook available on its settings page.
-
-#### Callback JSON data
-
-The following parameters are recognized in callback data:
-
-* `state` (required): Accepted values are `success`, `failure` and `error`.
- If the state isn't `success`, the webhook chain will be interrupted.
-* `description`: A string containing miscellaneous information that will be
- available on the Docker Hub. Maximum 255 characters.
-* `context`: A string containing the context of the operation. Can be retrieved
- from the Docker Hub. Maximum 100 characters.
-* `target_url`: The URL where the results of the operation can be found. Can be
- retrieved on the Docker Hub.
-
-*Example callback payload:*
-
- {
- "state": "success",
- "description": "387 tests PASSED",
- "context": "Continuous integration by Acme CI",
- "target_url": "http://ci.acme.com/results/afd339c1c3d27"
- }
-
-## Mark as unlisted
-
-By marking a repository as unlisted, you can create a publicly pullable repository
-which will not be in the Hub or commandline search. This allows you to have a limited
-release, but does not restrict access to anyone that is told, or guesses the repository
-name.
diff --git a/docs/docker-hub/userguide.md b/docs/docker-hub/userguide.md
deleted file mode 100644
index 4a9bb73db7..0000000000
--- a/docs/docker-hub/userguide.md
+++ /dev/null
@@ -1,63 +0,0 @@
-
-
-# Using the Docker Hub
-
-Docker Hub is used to find and pull Docker images to run or build upon, and to
-distribute and build images for other users to use.
-
-
-
-## Finding repositories and images
-
-There are two ways you can search for public repositories and images available
-on the Docker Hub. You can use the "Search" tool on the Docker Hub website, or
-you can `search` for all the repositories and images using the Docker commandline
-tool:
-
- $ docker search ubuntu
-
-Both will show you a list of the currently available public repositories on the
-Docker Hub which match the provided keyword.
-
-If a repository is private or marked as unlisted, it won't be in the repository
-search results. To see all the repositories you have access to and their statuses,
-you can look at your profile page on [Docker Hub](https://hub.docker.com).
-
-## Pulling, running and building images
-
-You can find more information on [working with Docker images](../userguide/dockerimages.md).
-
-## Official Repositories
-
-The Docker Hub contains a number of [Official
-Repositories](http://registry.hub.docker.com/official). These are
-certified repositories from vendors and contributors to Docker. They
-contain Docker images from vendors like Canonical, Oracle, and Red Hat
-that you can use to build applications and services.
-
-If you use Official Repositories you know you're using an optimized and
-up-to-date image to power your applications.
-
-> **Note:**
-> If you would like to contribute an Official Repository for your
-> organization, see [Official Repositories on Docker
-> Hub](/docker-hub/official_repos) for more information.
-
-## Building and shipping your own repositories and images
-
-The Docker Hub provides you and your team with a place to build and ship Docker images.
-
-Collections of Docker images are managed using repositories -
-
-You can configure two types of repositories to manage on the Docker Hub:
-[Repositories](./repos.md), which allow you to push images to the Hub from your local Docker daemon,
-and [Automated Builds](./builds.md), which allow you to configure GitHub or Bitbucket to
-trigger the Hub to rebuild repositories when changes are made to the repository.
diff --git a/docs/userguide/dockerhub.md b/docs/userguide/dockerhub.md
deleted file mode 100644
index 57d376fe0f..0000000000
--- a/docs/userguide/dockerhub.md
+++ /dev/null
@@ -1,78 +0,0 @@
-
-
-# Getting started with Docker Hub
-
-
-This section provides a quick introduction to the [Docker Hub](https://hub.docker.com),
-including how to create an account.
-
-The [Docker Hub](https://hub.docker.com) is a centralized resource for working with
-Docker and its components. Docker Hub helps you collaborate with colleagues and get the
-most out of Docker. To do this, it provides services such as:
-
-* Docker image hosting.
-* User authentication.
-* Automated image builds and work-flow tools such as build triggers and web
- hooks.
-* Integration with GitHub and Bitbucket.
-
-In order to use Docker Hub, you will first need to register and create an account. Don't
-worry, creating an account is simple and free.
-
-## Creating a Docker Hub account
-
-There are two ways for you to register and create an account:
-
-1. Via the web, or
-2. Via the command line.
-
-### Register via the web
-
-Fill in the [sign-up form](https://hub.docker.com/account/signup/) by
-choosing your user name and password and entering a valid email address. You can also
-sign up for the Docker Weekly mailing list, which has lots of information about what's
-going on in the world of Docker.
-
-
-
-### Register via the command line
-
-You can also create a Docker Hub account via the command line with the
-`docker login` command.
-
- $ docker login
-
-### Confirm your email
-
-Once you've filled in the form, check your email for a welcome message asking for
-confirmation so we can activate your account.
-
-
-### Login
-
-After you complete the confirmation process, you can login using the web console:
-
-
-
-Or via the command line with the `docker login` command:
-
- $ docker login
-
-Your Docker Hub account is now active and ready to use.
-
-## Next steps
-
-Next, let's start learning how to Dockerize applications with our "Hello world"
-exercise.
-
-Go to [Dockerizing Applications](/userguide/dockerizing).
-
diff --git a/docs/userguide/dockerrepos.md b/docs/userguide/dockerrepos.md
index e06894ef76..37c70944ec 100644
--- a/docs/userguide/dockerrepos.md
+++ b/docs/userguide/dockerrepos.md
@@ -82,8 +82,7 @@ You now have an image from which you can run containers.
Anyone can pull public images from the [Docker Hub](https://hub.docker.com)
registry, but if you would like to share your own images, then you must
-register first, as we saw in the [first section of the Docker User
-Guide](/userguide/dockerhub/).
+[register first](/docker-hub/accounts).
## Pushing a repository to Docker Hub
diff --git a/docs/userguide/index.md b/docs/userguide/index.md
index 7add251d59..1a218803be 100644
--- a/docs/userguide/index.md
+++ b/docs/userguide/index.md
@@ -33,7 +33,7 @@ Docker Hub is the central hub for Docker. It hosts public Docker images
and provides services to help you build and manage your Docker
environment. To learn more:
-Go to [Using Docker Hub](/userguide/dockerhub).
+Go to [Using Docker Hub](/docker-hub).
## Dockerizing applications: A "Hello world"
diff --git a/docs/userguide/login-web.png b/docs/userguide/login-web.png
deleted file mode 100644
index 353705ba5e..0000000000
Binary files a/docs/userguide/login-web.png and /dev/null differ
diff --git a/docs/userguide/register-web.png b/docs/userguide/register-web.png
deleted file mode 100644
index 709badc6d5..0000000000
Binary files a/docs/userguide/register-web.png and /dev/null differ