diff --git a/README.md b/README.md
index ef787ac0f..e96fdcba1 100644
--- a/README.md
+++ b/README.md
@@ -2,9 +2,9 @@
 
 **Drycc Workflow** is an open source Platform as a Service (PaaS) that adds a developer-friendly layer to any [Kubernetes][k8s-home] cluster, making it easy to deploy and manage applications.
 
-To **get started** with **Drycc Workflow** please read the [Quick Start Guide](https://drycc.cc/docs/workflow/quickstart/).
+To **get started** with **Drycc Workflow** please read the [Quick Start Guide](https://drycc.cc/quickstart/).
 
-Visit [https://drycc.cc](https://drycc.cc) for more information on [why you should use Drycc Workflow](https://drycc.cc/why-drycc/) or [learn about its features](https://drycc.cc/how-it-works/).
+Visit [https://drycc.cc](https://drycc.cc) for more information on [why you should use Drycc Workflow](https://drycc.cc/understanding-workflow/concepts/) or [learn about its features](https://drycc.cc/understanding-workflow/architecture/).
 
 This repository contains the source code for Drycc Workflow documentation. If you're looking for individual components, they live in their own repositories.
 
@@ -13,9 +13,7 @@ Please see below for links and descriptions of each component:
 - [passport](https://github.com/drycc/passport) - Workflow single sign on system
 - [controller](https://github.com/drycc/controller) - Workflow API server
 - [builder](https://github.com/drycc/builder) - Git server and source-to-image component
-- [imagebuilder](https://github.com/drycc/imagebuilder) - The builder for [Docker](https://www.docker.com/) based applications
-- [slugbuilder](https://github.com/drycc/slugbuilder) - The builder for [slug/buildpack](https://devcenter.heroku.com/articles/slug-compiler) based applications
-- [slugrunner](https://github.com/drycc/slugrunner) - The runner for slug/buildpack based applications
+- [imagebuilder](https://github.com/drycc/imagebuilder) - The builder for [Docker](https://www.docker.com/) and [CNCF Buildpacks](https://buildpacks.io/) based applications
 - [fluentd](https://github.com/drycc/fluentd) - Backend log shipping mechanism for `drycc logs`
 - [postgres](https://github.com/drycc/postgres) - The central database
 - [registry](https://github.com/drycc/registry) - The Docker registry
@@ -31,14 +29,13 @@ We welcome your input! If you have feedback, please [submit an issue][issues]. I
 
 # Working on Documentation
 [![Build Status](https://drone.drycc.cc/api/badges/drycc/workflow/status.svg)](https://drone.drycc.cc/drycc/workflow)
-[![Latest Docs](http://img.shields.io/badge/docs-latest-fc1e5e.svg)](http://docs-v2.readthedocs.org/en/latest/)
 
 The Drycc project welcomes contributions from all developers. The high level process for development matches many other open source projects. See below for an outline.
 
 * Fork this repository.
 * Make your changes.
 * [Submit a pull request][prs] (PR) to this repository with your changes, and unit tests whenever possible.
-	* If your PR fixes any [issues][issues], make sure you write `Fixes #1234` in your PR description (where `#1234` is the number of the issue you're closing).
+    * If your PR fixes any [issues][issues], make sure you write `Fixes #1234` in your PR description (where `#1234` is the number of the issue you're closing).
 * The Drycc core contributors will review your code. After each of them sign off on your code, they'll label your PR with `LGTM1` and `LGTM2` (respectively). Once that happens, a contributor will merge it.
 
 ## Requirements
diff --git a/mkdocs.yml b/mkdocs.yml
index 5c0cc694c..d65160d86 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -48,7 +48,6 @@ nav:
     - Platform Monitoring: managing-workflow/platform-monitoring.md
     - Production Deployments: managing-workflow/production-deployments.md
     - Upgrading Workflow: managing-workflow/upgrading-workflow.md
-    - Extending Workflow: managing-workflow/extending-workflow.md
   - Troubleshooting:
     - Troubleshooting Workflow: troubleshooting/index.md
     - Troubleshooting using Kubectl: troubleshooting/kubectl.md
diff --git a/src/applications/deploying-apps.md b/src/applications/deploying-apps.md
index 76d694ba7..db2698b8b 100644
--- a/src/applications/deploying-apps.md
+++ b/src/applications/deploying-apps.md
@@ -23,9 +23,9 @@ using the URL supplied by their Drycc administrator.
 
 ```
 $ drycc login http://drycc.example.com
-username: drycc
-password:
-Logged in as drycc
+Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+Waiting for login... .o.Logged in as admin
+Configuration file written to /root/.drycc/client.json
 ```
 
 ## Select a Build Process
@@ -34,7 +34,7 @@ Drycc Workflow supports three different ways of building applications:
 
 ### Buildpacks
 
-Heroku buildpacks are useful if you want to follow Heroku's best practices for building applications or if you are porting an application from Heroku.
+Cloud Native Buildpacks are useful if you want to follow [cnb's docs](https://buildpacks.io/docs/) for building applications.
 
 Learn how to deploy applications [using Buildpacks](../applications/using-buildpacks.md).
 
@@ -60,9 +60,9 @@ It is possible to configure a few of the [globally tunable](../applications/mana
 
 Setting                                         | Description
 ----------------------------------------------- | ---------------------------------
-DRYCC_DISABLE_CACHE                              | if set, this will disable the [slugbuilder cache][] (default: not set)
-DRYCC_DEPLOY_BATCHES                             | the number of pods to bring up and take down sequentially during a scale (default: number of available nodes)
-DRYCC_DEPLOY_TIMEOUT                             | deploy timeout in seconds per deploy batch (default: 120)
+DRYCC_DISABLE_CACHE                             | if set, this will disable the [slugbuilder cache][] (default: not set)
+DRYCC_DEPLOY_BATCHES                            | the number of pods to bring up and take down sequentially during a scale (default: number of available nodes)
+DRYCC_DEPLOY_TIMEOUT                            | deploy timeout in seconds per deploy batch (default: 120)
 IMAGE_PULL_POLICY                               | the kubernetes [image pull policy][pull-policy] for application images (default: "IfNotPresent") (allowed values: "Always", "IfNotPresent")
 KUBERNETES_DEPLOYMENTS_REVISION_HISTORY_LIMIT   | how many [revisions][kubernetes-deployment-revision] Kubernetes keeps around of a given Deployment (default: all revisions)
 KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS | how many seconds kubernetes waits for a pod to finish work after a SIGTERM before sending SIGKILL (default: 30)
diff --git a/src/applications/managing-app-configuration.md b/src/applications/managing-app-configuration.md
index a0440aadb..76fa19022 100644
--- a/src/applications/managing-app-configuration.md
+++ b/src/applications/managing-app-configuration.md
@@ -53,11 +53,10 @@ the application to an external PostgreSQL database.
 Detachments can be performed with `drycc config:unset`.
 
 
-## Slugbuilder Cache
+## Buildpacks Cache
 
-By default, apps using the [Slugbuilder][] will have caching turned on. This means that Drycc will
-persist all data being written to `CACHE_DIR` inside the buildpack will be persisted between
-deploys. When deploying applications that depend on third-party libraries that have to be fetched,
+By default, apps using the [Imagebuilder][] will reuse the latest image data.
+When deploying applications that depend on third-party libraries that have to be fetched,
 this could speed up deployments a lot. In order to make use of this, the buildpack must implement
 the cache by writing to the cache directory. Most buildpacks already implement this, but when using
 custom buildpacks, it might need to be changed to make full use of the cache.
diff --git a/src/applications/using-buildpacks.md b/src/applications/using-buildpacks.md
index 4b598104a..34a28dab8 100644
--- a/src/applications/using-buildpacks.md
+++ b/src/applications/using-buildpacks.md
@@ -1,6 +1,6 @@
 # Using Buildpacks
 
-Drycc supports deploying applications via [Heroku Buildpacks][]. Buildpacks are useful if you're interested in following Heroku's best practices for building applications or if you are deploying an application that already runs on Heroku.
+Drycc supports deploying applications via [Cloud Native Buildpacks](https://buildpacks.io/). Cloud Native Buildpacks are useful if you want to follow [cnb's docs](https://buildpacks.io/docs/) for building applications.
 
 ## Add SSH Key
 
@@ -44,18 +44,43 @@ Use `git push drycc master` to deploy your application.
     Compressing objects: 100% (48/48), done.
     Writing objects: 100% (75/75), 18.28 KiB | 0 bytes/s, done.
     Total 75 (delta 30), reused 58 (delta 22)
+    remote: --->
     Starting build... but first, coffee!
-    -----> Go app detected
-    -----> Checking Godeps/Godeps.json file.
-    -----> Installing go1.4.2... done
-    -----> Running: godep go install -tags heroku ./...
-    -----> Discovering process types
-           Procfile declares types -> web
-    -----> Compiled slug size is 1.7M
+    ---> Waiting podman running.
+    ---> Process podman started.
+    ---> Waiting caddy running.
+    ---> Process caddy started.
+    ---> Building pack
+    ---> Using builder docker.io/drycc/buildpacks:20
+    Builder 'docker.io/drycc/buildpacks:20' is trusted
+    Pulling image 'index.docker.io/drycc/buildpacks:20'
+    Resolving "drycc/buildpacks" using unqualified-search registries (/etc/containers/registries.conf)
+    Trying to pull docker.io/drycc/buildpacks:20...
+    Getting image source signatures
+    ...
+    ---> Skip generate base layer
+    ---> Python Buildpack
+    ---> Downloading and extracting Python 3.10.0
+    ---> Installing requirements with pip
+    Collecting Django==3.2.8
+    Downloading Django-3.2.8-py3-none-any.whl (7.9 MB)
+    Collecting gunicorn==20.1.0
+    Downloading gunicorn-20.1.0-py3-none-any.whl (79 kB)
+    Collecting sqlparse>=0.2.2
+    Downloading sqlparse-0.4.2-py3-none-any.whl (42 kB)
+    Collecting pytz
+    Downloading pytz-2021.3-py2.py3-none-any.whl (503 kB)
+    Collecting asgiref<4,>=3.3.2
+    Downloading asgiref-3.4.1-py3-none-any.whl (25 kB)
+    Requirement already satisfied: setuptools>=3.0 in /layers/drycc_python/python/lib/python3.10/site-packages (from gunicorn==20.1.0->-r requirements.txt (line 2)) (57.5.0)
+    Installing collected packages: sqlparse, pytz, asgiref, gunicorn, Django
+    Successfully installed Django-3.2.8 asgiref-3.4.1 gunicorn-20.1.0 pytz-2021.3 sqlparse-0.4.2
+    ---> Generate Launcher
+    ...
     Build complete.
-    Launching app.
-    Launching...
-    Done, skiing-keypunch:v2 deployed to Drycc
+    Launching App...
+    ...
+    Done, skiing-keypunch:v2 deployed to Workflow
 
     Use 'drycc open' to view this application in your browser
 
@@ -68,7 +93,7 @@ Use `git push drycc master` to deploy your application.
     Powered by Drycc
     Release v2 on skiing-keypunch-v2-web-02zb9
 
-Because a Heroku-style application is detected, the `web` process type is automatically scaled to 1 on first deploy.
+Because a Buildpacks-style application is detected, the `web` process type is automatically scaled to 1 on first deploy.
 
 Use `drycc scale web=3` to increase `web` processes to 3, for example. Scaling a
 process type directly changes the number of [pods] running that process.
@@ -78,18 +103,13 @@ process type directly changes the number of [pods] running that process.
 
 For convenience, a number of buildpacks come bundled with Drycc:
 
- * [Ruby Buildpack][]
- * [Nodejs Buildpack][]
+ * [Go Buildpack][]
  * [Java Buildpack][]
- * [Gradle Buildpack][]
- * [Grails Buildpack][]
- * [Play Buildpack][]
- * [Python Buildpack][]
+ * [Nodejs Buildpack][]
  * [PHP Buildpack][]
- * [Clojure Buildpack][]
- * [Scala Buildpack][]
- * [Go Buildpack][]
- * [Multi Buildpack][]
+ * [Python Buildpack][]
+ * [Ruby Buildpack][]
+ * [Rust Buildpack][]
 
 Drycc will cycle through the `bin/detect` script of each buildpack to match the code you
 are pushing.
@@ -101,32 +121,14 @@ are pushing.
 
 ## Using a Custom Buildpack
 
-To use a custom buildpack, you need create a `.buildpack` file in your root path app.
+To use a custom buildpack, you need create a `.pack_builder` file in your root path app.
 
-    $  tee > .buildpack << EOF
-       > https://github.com/dpiddy/heroku-buildpack-ruby-minimal
+    $  tee > .pack_builder << EOF
+       > docker.io/drycc/buildpacks:20
        > EOF
 
-!!! note
-    If, however, you're unable to deploy using the latest version of the buildpack, You can set an exact version of a buildpack by using a git revision in your `.buildpack`. For example: `https://github.com/dpiddy/heroku-buildpack-ruby-minimal#v13`
-
 On your next `git push`, the custom buildpack will be used.
 
-
-## Compile Hooks
-
-Sometimes, an application needs a way to stop or check if a service is running before building an
-app, which may require notifying a service that the [Builder][] has finished compiling the app. In
-order to do this, an app can provide two files in their `bin/` directory:
-
-```
-bin/pre-compile
-bin/post-compile
-```
-
-The builder will run these commands before and after the build process, respectively.
-
-
 ## Using Private Repositories
 
 To pull code from private repositories, set the `SSH_KEY` environment variable to a private key
@@ -139,13 +141,13 @@ which has access. Use either the path of a private key file or the raw key mater
 
 For example, to use a custom buildpack hosted at a private GitHub URL, ensure that an SSH public
 key exists in your [GitHub settings][]. Then set `SSH_KEY` to the corresponding SSH private key
-and set `.buildpack` to the URL:
+and set `.pack_builder` to the builder image:
 
-    $  tee > .buildpack << EOF
-       > https://github.com/dpiddy/heroku-buildpack-ruby-minimal
+    $  tee > .pack_builder << EOF
+       > docker.io/drycc/buildpacks:20
        > EOF
     $ git add .buildpack
-    $ git commit -m "chore(buildpack): modify the buildpack url"
+    $ git commit -m "chore(buildpack): modify the pack_builder"
     $ git push drycc master
 
 ## Builder selector
@@ -153,25 +155,20 @@ and set `.buildpack` to the URL:
 Which way to build a project conforms to the following principles:
 
 - If Dockerfile exists in the project, the stack uses `container`
-- If Procfile exists in the project, the stack uses `heroku-18`
+- If Procfile exists in the project, the stack uses `buildpack`
 - If both exist, `container` is used by default
-- You can also set the `DRYCC_STACK` to determine which stack to use.
+- You can also set the `DRYCC_STACK` to `container` or `buildpack` determine which stack to use.
 
 
 [pods]: http://kubernetes.io/v1.1/docs/user-guide/pods.html
 [controller]: ../understanding-workflow/components.md#controller
 [builder]: ../understanding-workflow/components.md#builder
-[Ruby Buildpack]: https://github.com/heroku/heroku-buildpack-ruby
-[Nodejs Buildpack]: https://github.com/heroku/heroku-buildpack-nodejs
-[Java Buildpack]: https://github.com/heroku/heroku-buildpack-java
-[Gradle Buildpack]: https://github.com/heroku/heroku-buildpack-gradle
-[Grails Buildpack]: https://github.com/heroku/heroku-buildpack-grails
-[Play Buildpack]: https://github.com/heroku/heroku-buildpack-play
-[Python Buildpack]: https://github.com/heroku/heroku-buildpack-python
-[PHP Buildpack]: https://github.com/heroku/heroku-buildpack-php
-[Clojure Buildpack]: https://github.com/heroku/heroku-buildpack-clojure
-[Scala Buildpack]: https://github.com/heroku/heroku-buildpack-scala
-[Go Buildpack]: https://github.com/kr/heroku-buildpack-go
-[Multi Buildpack]: https://github.com/heroku/heroku-buildpack-multi
-[Heroku Buildpacks]: https://devcenter.heroku.com/articles/buildpacks
+[Go Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/go
+[Java Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/java
+[Nodejs Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/nodejs
+[PHP Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/php
+[Python Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/python
+[Ruby Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/ruby
+[Rust Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/rust
+[Cloud Native Buildpacks]: https://buildpacks.io/
 [GitHub settings]: https://github.com/settings/ssh
diff --git a/src/installing-workflow/configuring-object-storage.md b/src/installing-workflow/configuring-object-storage.md
index 48399bf71..1b82ab739 100644
--- a/src/installing-workflow/configuring-object-storage.md
+++ b/src/installing-workflow/configuring-object-storage.md
@@ -44,7 +44,7 @@ Operators should configure object storage by editing the Helm values file before
 	All values will be automatically (base64) encoded _except_ the `key_json` values under `gcs`/`gcr`.  These must be base64-encoded.  This is to support cleanly passing said encoded text via `helm --set` cli functionality rather than attempting to pass the raw JSON data.  For example:
 
 		$ helm install workflow --namespace drycc \
-                        --set global.platform_domain=youdomain.com
+			--set global.platform_domain=youdomain.com
 			--set global.storage=gcs,gcs.key_json="$(cat /path/to/gcs_creds.json | base64 -w 0)"
 
 You are now ready to run `helm install drycc/workflow --namespace drycc -f values.yaml` using your desired object storage.
diff --git a/src/installing-workflow/configuring-postgres.md b/src/installing-workflow/configuring-postgres.md
index a10eb7f41..88fa17e88 100644
--- a/src/installing-workflow/configuring-postgres.md
+++ b/src/installing-workflow/configuring-postgres.md
@@ -1,6 +1,6 @@
 # Configuring Postgres
 
-Drycc Workflow's controller component relies on a PostgreSQL database to store platform state.
+Drycc Workflow's controller and passport component rely on a PostgreSQL database to store platform state.
 
 By default, Drycc Workflow ships with the [database] component, which provides an in-cluster PostgreSQL database backed up to in-cluster or off-cluster [object storage]. Currently, for object storage, which is utilized by _several_ Workflow components, only off-cluster solutions such as S3 or GCS are recommended in production environments. Experience has shown that many operators already opting for off-cluster object storage similarly prefer to host Postgres off-cluster as well, using Amazon RDS or similar. When excercising both options, a Workflow installation becomes entirely stateless, and is thus restored or rebuilt with greater ease should the need ever arise.
 
diff --git a/src/installing-workflow/index.md b/src/installing-workflow/index.md
index 47c9e6a1c..5b3e1e290 100644
--- a/src/installing-workflow/index.md
+++ b/src/installing-workflow/index.md
@@ -74,10 +74,8 @@ If you want to change it, set the variable when using helm.
 ```
 $ helm install --namespace drycc \
     --set builder.image_registry=quay.io \
-    --set slugbuilder.image_registry=quay.io \
     --set imagebuilder.image_registry=quay.io \
     --set controller.image_registry=quay.io \
-    --set slugrunner.image_registry=quay.io \
     --set database.image_registry=quay.io \
     --set fluentd.image_registry=quay.io \
     --set redis.image_registry=quay.io \
@@ -163,5 +161,5 @@ Once all of the pods are in the `READY` state, and `drycc-builder.$host` resolve
 
 After installing Workflow, [register a user and deploy an application](../quickstart/deploy-an-app.md).
 
-If your k8s does not provide public network loadblance, you need to install TCP proxy services such as haproxy on machines that can 
-access both internal and external networks, and then expose `80` and `443`.
\ No newline at end of file
+If your k8s does not provide public network loadblance, you need to install TCP proxy services such as haproxy on machines that can
+access both internal and external networks, and then expose `80` and `443`.
diff --git a/src/managing-workflow/extending-workflow.md b/src/managing-workflow/extending-workflow.md
deleted file mode 100644
index f2c696ebe..000000000
--- a/src/managing-workflow/extending-workflow.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Extending Workflow
-
-Drycc Workflow is an open source project which wouldn't be here without the amazing skill
-and enthusiasm of the community that has grown up around it. Several projects have blossomed
-which extend Workflow in various ways.
-
-These links are to community-contributed extensions of Drycc Workflow. Drycc makes no
-guarantees about the functionality, security, or code contained within. As with any software,
-use with caution in a production environment.
-
-## Workflow Community Projects
-
-- [alea][] is a backing services manager for Drycc Workflow, providing easy
-  access to PostgreSQL, Redis, MongoDB, and memcached.
-- [dryccdash][] is a web-based UI supporting many user and app actions without need of the
-  `drycc` command-line interface.
-- [drycc-cleanup][] is a Drycc-friendly, configurable approach to purging unneeded Docker
-  containers and images.
-- [drycc-global-config-plugin][] stores config values in [Vault][] for easy use in Workflow apps.
-- [drycc-node][] is a controller API client for a browser in NodeJS.
-- [drycc-ui][] is the beginning of a full client-side dashboard that interfaces with the
-  controller API.
-- [drycc-workflow-aws][] simplifies installing Workflow on [Amazon Web Services][], backed by
-  S3 and using ECR as the container registry.
-- [drycc-workflow-gke][] simplifies installing Workflow on [Google Container Engine][], backed
-  by Google Cloud Storage and using gcr.io as the container registry.
-- [drycc-workflow-ruby][] contains Workflow controller API bindings for Ruby programming.
-- [heroku-to-drycc][] migrates existing Heroku applications to the Workflow platform.
-- [kube-solo-osx][] creates a zero-to-Kubernetes development environment for macOS in under
-  two minutes, with specific support for installing Workflow with [Helm][] or Helm Classic.
-
-Are we missing something? Please open a [documentation pull request][] to add it.
-
-[alea]: https://github.com/Codaisseur/alea
-[Amazon Web Services]: https://aws.amazon.com/
-[dryccdash]: https://github.com/olalonde/dryccdash
-[drycc-cleanup]: https://github.com/Ragnarson/drycc-cleanup
-[drycc-global-config-plugin]: https://github.com/Rafflecopter/drycc-global-config-plugin
-[drycc-node]: https://github.com/olalonde/drycc-node
-[drycc-ui]: https://github.com/jumbojett/drycc-ui
-[drycc-workflow-aws]: https://github.com/rimusz/drycc-workflow-aws
-[drycc-workflow-gke]: https://github.com/rimusz/drycc-workflow-gke
-[drycc-workflow-ruby]: https://github.com/thomas0087/drycc-workflow-ruby
-[documentation pull request]: https://github.com/drycc/workflow/pulls
-[Google Container Engine]: https://cloud.google.com/container-engine/
-[Helm]: https://github.com/kubernetes/helm
-[heroku-to-drycc]: https://github.com/emartech/heroku-to-drycc
-[kube-solo-osx]: https://github.com/TheNewNormal/kube-solo-osx
-[Vault]: https://www.vaultproject.io/
diff --git a/src/managing-workflow/tuning-component-settings.md b/src/managing-workflow/tuning-component-settings.md
index a2518a99c..e4b7ff746 100644
--- a/src/managing-workflow/tuning-component-settings.md
+++ b/src/managing-workflow/tuning-component-settings.md
@@ -64,12 +64,11 @@ Setting                                         | Description
 REGISTRATION_MODE                               | set registration to "enabled", "disabled", or "admin_only" (default: "admin_only")
 GUNICORN_WORKERS                                | number of [gunicorn][] workers spawned to process requests (default: CPU cores * 4 + 1)
 RESERVED_NAMES                                  | a comma-separated list of names which applications cannot reserve for routing (default: "drycc, drycc-builder")
-SLUGRUNNER_IMAGE_NAME                           | the image used to run buildpack application slugs (default: "quay.io/drycc/slugrunner:canary")
-DRYCC_DEPLOY_HOOK_URLS                           | a comma-separated list of URLs to send [deploy hooks][] to.
-DRYCC_DEPLOY_HOOK_SECRET_KEY                     | a private key used to compute the HMAC signature for deploy hooks.
-DRYCC_DEPLOY_REJECT_IF_PROCFILE_MISSING          | rejects a deploy if the previous build had a Procfile but the current deploy is missing it. A 409 is thrown in the API. Prevents accidental process types removal. (default: "false", allowed values: "true", "false")
-DRYCC_DEPLOY_PROCFILE_MISSING_REMOVE             | when turned on (default) any missing process type in a Procfile compared to the previous deploy is removed. When set to false will allow an empty Procfile to go through without removing missing process types, note that new images, configs and so on will get updated on all proc types.  (default: "true", allowed values: "true", "false")
-DRYCC_DEFAULT_CONFIG_TAGS                        | set tags for all applications by default, for example: '{"role": "worker"}'. (default: '')
+DRYCC_DEPLOY_HOOK_URLS                          | a comma-separated list of URLs to send [deploy hooks][] to.
+DRYCC_DEPLOY_HOOK_SECRET_KEY                    | a private key used to compute the HMAC signature for deploy hooks.
+DRYCC_DEPLOY_REJECT_IF_PROCFILE_MISSING         | rejects a deploy if the previous build had a Procfile but the current deploy is missing it. A 409 is thrown in the API. Prevents accidental process types removal. (default: "false", allowed values: "true", "false")
+DRYCC_DEPLOY_PROCFILE_MISSING_REMOVE            | when turned on (default) any missing process type in a Procfile compared to the previous deploy is removed. When set to false will allow an empty Procfile to go through without removing missing process types, note that new images, configs and so on will get updated on all proc types.  (default: "true", allowed values: "true", "false")
+DRYCC_DEFAULT_CONFIG_TAGS                       | set tags for all applications by default, for example: '{"role": "worker"}'. (default: '')
 KUBERNETES_NAMESPACE_DEFAULT_QUOTA_SPEC         | set resource quota to application namespace by setting [ResourceQuota](http://kubernetes.io/docs/admin/resourcequota/) spec, for example: `{"spec":{"hard":{"pods":"10"}}}`, restrict app owner to spawn more then 10 pods (default: "", no quota will be applied to namespace)
 
 ### LDAP authentication settings
@@ -77,7 +76,7 @@ KUBERNETES_NAMESPACE_DEFAULT_QUOTA_SPEC         | set resource quota to applicat
 Configuration options for LDAP authentication are detailed [here](https://pythonhosted.org/django-auth-ldap/reference.html).
 
 The following environment variables are available for enabling LDAP
-authentication of user accounts in the [Controller][] component:
+authentication of user accounts in the [Passport][] component:
 
 Setting            | Description
 -------------------| ---------------------------------
@@ -89,20 +88,6 @@ LDAP_USER_FILTER   | The name of the login field in the users search base (defau
 LDAP_GROUP_BASEDN  | The distinguished name of the search base for user's groups names (default: "")
 LDAP_GROUP_FILTER  | The filter for user's groups (default: "", example: ```objectClass=person```)
 
-### OAuth 2.0 Password Grant settings
-
-The following environment variables are available for enabling OAuth 2.0 Password Grant.
-If you have configured both of LDAP authentication and OAuth 2.0, LDAP authentication first.
-authentication of user accounts in the [Controller][] component:
-
-Setting                  | Description
--------------------------| ---------------------------------
-OAUTH_ACCESS_TOKEN_URL  | The URI of the OAuth 2.0 get token server. (default: ""). If not specified, OAuth 2.0 authentication is not enabled(default: "", example: ```http://hostname```).
-OAUTH_ACCESS_API_URL    | The URI of the OAuth 2.0 get resources server. (default: "")
-OAUTH_CLIENT_ID         | The client id.
-OAUTH_CLIENT_SECRET     | The client secret.
-OAUTH_CACHE_USER_TIME   | Cache user object, prevent too frequent request to the OAuth 2.0 authentication server.
-
 ### Global and per application settings
 
 Setting                                         | Description
@@ -205,6 +190,7 @@ API_VERSION       | The version number Workflow Manager sends to the versions AP
 [Deploying Apps]: ../applications/deploying-apps.md
 [builder]: ../understanding-workflow/components.md#builder
 [controller]: ../understanding-workflow/components.md#controller
+[passport]: ../understanding-workflow/components.md#passport
 [database]: ../understanding-workflow/components.md#database
 [deploy hooks]: deploy-hooks.md#http-post-hook
 [Deployments]: http://kubernetes.io/docs/user-guide/deployments/
diff --git a/src/managing-workflow/upgrading-workflow.md b/src/managing-workflow/upgrading-workflow.md
index 98cd1e0db..9d11d5aa2 100644
--- a/src/managing-workflow/upgrading-workflow.md
+++ b/src/managing-workflow/upgrading-workflow.md
@@ -82,7 +82,7 @@ drycc-rabbitmq-0                          1/1       Running   0          5m
 Users of Drycc Workflow should now upgrade their drycc client to avoid getting `WARNING: Client and server API versions do not match. Please consider upgrading.` warnings.
 
 ```
-curl -sSL https://raw.githubusercontent.com/drycc/workflow-cli/main/install.tmpl | bash -s v1.1.0 && sudo mv drycc $(which drycc)
+curl -sfL https://drycc.cc/install-cli.sh | bash - && sudo mv drycc $(which drycc)
 ```
 
 
diff --git a/src/quickstart/deploy-an-app.md b/src/quickstart/deploy-an-app.md
index 3abb5761d..a0ecf02db 100644
--- a/src/quickstart/deploy-an-app.md
+++ b/src/quickstart/deploy-an-app.md
@@ -4,26 +4,18 @@ Drycc workflow requires a wildcard DNS record to dynamically map app names to th
 
 User should already have DNS set up pointing to their known host. The `$hostname` value can be calculated by prepending `drycc.` to the value set in `global.platform_domain`.
 
-## Register an Admin User
+## Login to Workflow
 
-The first user to register against Drycc Workflow will automatically be given administrative privileges.
-
-Use the controller `$hostname` to register a user in the cluster.
+Workflow use the passport component to create and authorize users.
+If you already have an account, use `drycc login` to authenticate against the Drycc Workflow API.
 
 ```
-$ drycc register http://$hostname
-username: admin
-password:
-password (confirm):
-email: jhansen@drycc.cc
-Registered admin
-Logged in as admin
-$ drycc whoami
-You are admin at http://$hostname
+$ drycc login http://drycc.example.com
+Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+Waiting for login... .o.Logged in as admin
+Configuration file written to /root/.drycc/client.json
 ```
 
-You have now registered your first user and you are ready to deploy an application.
-
 ## Deploy an Application
 
 Drycc Workflow supports three different types of applications, Buildpacks,
@@ -112,8 +104,8 @@ There is a lot more you can do with Drycc Workflow, play around with the CLI:
 * Roll back to a previous release with `drycc rollback -a proper-barbecue`
 * See application logs with `drycc logs -a proper-barbecue`
 * Try one of our other example applications like:
-    * [drycc/example-ruby-sinatra](https://github.com/drycc/example-ruby-sinatra)
-    * [drycc/example-nodejs-express](https://github.com/drycc/example-nodejs-express)
-    * [drycc/example-java-jetty](https://github.com/drycc/example-java-jetty)
+    * [drycc/ruby-getting-started](https://github.com/drycc/ruby-getting-started)
+    * [drycc/python-getting-started](https://github.com/drycc/python-getting-started)
+    * [drycc/php-getting-started](https://github.com/drycc/php-getting-started)
 * Read about using application [Buildpacks](../applications/using-buildpacks) or [Dockerfiles](../applications/using-dockerfiles.md)
 * Join our [#community slack channel](https://slack.drycc.cc) and meet the team!
diff --git a/src/quickstart/index.md b/src/quickstart/index.md
index 343684771..5488bb00c 100644
--- a/src/quickstart/index.md
+++ b/src/quickstart/index.md
@@ -18,4 +18,4 @@ For the quickstart we will [install Drycc Workflow CLI](install-cli-tools.md).
 
 ## Step 3: Deploy your first app
 
-Last but not least, [register a user and deploy your first application](deploy-an-app.md).
+Last but not least, [login and deploy your first application](deploy-an-app.md).
diff --git a/src/reference-guide/terms.md b/src/reference-guide/terms.md
index 9e987764d..4cbc58600 100644
--- a/src/reference-guide/terms.md
+++ b/src/reference-guide/terms.md
@@ -45,7 +45,6 @@ The controller is the "brain" of the Drycc platform. A controller manages Applic
 
 The controller is in charge of:
 
-- Authenticating and authorizing clients
 - Processing client API calls
 - Managing containers that perform work for applications
 - Managing proxies that route traffic to containers
diff --git a/src/roadmap/releases.md b/src/roadmap/releases.md
index 02d5ddfaa..2f5792c09 100644
--- a/src/roadmap/releases.md
+++ b/src/roadmap/releases.md
@@ -252,7 +252,7 @@ Kick off https://ci.drycc.info/job/workflow-cli-build-stable/ with the `TAG` bui
 and then verify `stable` artifacts are available and appropriately updated after the job completes:
 
 ```
-$ curl -sSL https://raw.githubusercontent.com/drycc/workflow-cli/main/install.tmpl | bash -s v1.1.0
+$ curl -sfL https://drycc.cc/install-cli.sh | bash -
 $ ./drycc version
 # (Should show $WORKFLOW_RELEASE)
 ```
diff --git a/src/troubleshooting/kubectl.md b/src/troubleshooting/kubectl.md
index cb31b7736..8ee023c1f 100644
--- a/src/troubleshooting/kubectl.md
+++ b/src/troubleshooting/kubectl.md
@@ -19,7 +19,6 @@ running, run:
 	drycc-logger-grupg             0/1       ContainerCreating   0          3s
 	drycc-minio-c2exb              0/1       Pending             0          3s
 	drycc-monitor-grafana-9ccur    0/1       Pending             0          3s
-	drycc-monitor-stdout-novxs     0/1       Pending             0          3s
 	drycc-monitor-telegraf-dc3y3   0/1       Pending             0          2s
 	drycc-registry-5bor6           0/1       Pending             0          3s
 	drycc-rabbitmq-0               0/1       ContainerCreating   0          3s
@@ -42,37 +41,38 @@ To fetch the logs of a specific component, use `kubectl logs`:
 To dive into a running container to inspect its environment, use `kubectl exec`:
 
 	$ kubectl --namespace=drycc exec -it drycc-database-56v39 gosu postgres psql
-	psql (9.4.7)
-	Type "help" for help.
+    psql (13.4 (Debian 13.4-1.pgdg100+1))
+    Type "help" for help.
 
 	postgres=# \l
 	                                                List of databases
-	               Name               |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
-	----------------------------------+----------+----------+------------+------------+-----------------------
-	 V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
-	 postgres                         | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
-	 template0                        | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
-	                                  |          |          |            |            | postgres=CTc/postgres
-	 template1                        | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
-	                                  |          |          |            |            | postgres=CTc/postgres
+	     Name          |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
+	-------------------+----------+----------+------------+------------+-----------------------
+	 drycc_controller  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
+	 drycc_passport    | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
+	 postgres          | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
+	 template0         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
+	                   |          |          |            |            | postgres=CTc/postgres
+	 template1         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
+	                   |          |          |            |            | postgres=CTc/postgres
 	(4 rows)
-	postgres=# \connect V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	You are now connected to database "V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc" as user "postgres".
-	V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc=# \dt
+	postgres=# \connect drycc_controller
+	You are now connected to database "drycc_controller" as user "postgres".
+	drycc_controller=# \dt
 	                                 List of relations
-	 Schema |              Name              | Type  |              Owner
-	--------+--------------------------------+-------+----------------------------------
-	 public | api_app                        | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_build                      | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_certificate                | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_config                     | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_domain                     | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_key                        | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_push                       | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | api_release                    | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
-	 public | auth_group                     | table | V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc
+	 Schema |              Name              | Type  |      Owner
+	--------+--------------------------------+-------+-------------------
+	 public | api_app                        | table | drycc_controller
+	 public | api_build                      | table | drycc_controller
+	 public | api_certificate                | table | drycc_controller
+	 public | api_config                     | table | drycc_controller
+	 public | api_domain                     | table | drycc_controller
+	 public | api_key                        | table | drycc_controller
+	 public | api_push                       | table | drycc_controller
+	 public | api_release                    | table | drycc_controller
+	 public | auth_group                     | table | drycc_controller
 	 --More--
-	 V7wckOHIAn3MZ7mO5du4q5IRq7yib1Oc=# SELECT COUNT(*) from api_app;
+	 drycc_controller=# SELECT COUNT(*) from api_app;
 	 count
 	-------
 	     0
diff --git a/src/understanding-workflow/components.md b/src/understanding-workflow/components.md
index 942732fd1..ee83b7e39 100644
--- a/src/understanding-workflow/components.md
+++ b/src/understanding-workflow/components.md
@@ -50,32 +50,17 @@ managing the build process of your [Application][]. The builder process is:
 
 Builder currently supports both buildpack and Dockerfile based builds.
 
-**Project Location:** [drycc/slugbuilder](https://github.com/drycc/slugbuilder)
-
-For Buildpack-based deploys, the builder component will launch a one-shot Pod
-in the `drycc` namespace. This pod runs `slugbuilder` component which handles
-default and custom buildpacks (specified by `.buildpacks`). The "compiled"
-application results in a slug, consisting of your application code and all of
-its dependencies as determined by the buildpack. The slug is pushed to the
-cluster-configured object storage for later execution. For more information
-about buildpacks see [using buildpacks][using-buildpacks].
-
 **Project Location:** [drycc/imagebuilder](https://github.com/drycc/imagebuilder)
 
-For Applications which contain a `Dockerfile` in the root of the repository,
-`builder` will instead launch the `imagebuilder` to package your application.
-Instead of generating a slug, `imagebuilder` generates a Docker image (using
-the underlying Docker engine). The completed image is pushed to the managed
-Docker registry on cluster. For more information see [using Dockerfiles][using-dockerfiles].
-
-## Slugrunner
-
-**Project Location:** [drycc/slugrunner](https://github.com/drycc/slugrunner)
+For Buildpack-based deploys, the builder component will launch a one-shot Job
+in the `drycc` namespace. This job runs `imagebuilder` component which handles
+default and custom buildpacks (specified by `.packbuilder`). The completed image
+is pushed to the managed Docker registry on cluster. For more information
+about buildpacks see [using buildpacks][using-buildpacks].
 
-Slugrunner is the component responsible for executing buildpack-based
-Applications. Slugrunner receives slug information from the controller and
-downloads the application slug just before launching your application
-processes.
+Unlike buildpack-based, For Applications which contain a `Dockerfile` in the root
+of the repository, it generates a Docker image (using the underlying Docker engine).
+For more information see [using Dockerfiles][using-dockerfiles].
 
 ## Object Storage
 
@@ -153,6 +138,14 @@ a more robust InfluxDB setup in a production setting.
 RabbitMQ is the most widely deployed open source message broker.
 Controller use celery with rabbitMQ to execute the asynchronous task.
 
+## HelmBroker
+
+**Project Location:** [drycc/rabbitmq](https://github.com/drycc/helmbroker)
+
+Helm Broker is a Service Broker that exposes Helm charts as Service Classes in Service Catalog.
+To do so, Helm Broker uses the concept of addons. An addon is an abstraction layer over a Helm chart
+which provides all information required to convert the chart into a Service Class.
+
 ## See Also
 
 * [Workflow Concepts][concepts]
diff --git a/src/understanding-workflow/concepts.md b/src/understanding-workflow/concepts.md
index 18aa1740b..554e307e3 100644
--- a/src/understanding-workflow/concepts.md
+++ b/src/understanding-workflow/concepts.md
@@ -44,10 +44,6 @@ a simple and straightforward "source to Docker image" capability. Supporting
 multiple language runtimes via community [buildpacks][], building your application
 in a container can be as easy as `git push drycc master`.
 
-Applications which are packaged via a buildpack are run in Docker containers as
-part of the `slugrunner` process. View the [slugrunner component][slugrunner]
-for more information.
-
 Applications which use either a Dockerfile or reference external Docker
 images are launched unmodified.
 
@@ -140,4 +136,3 @@ to external or third-party vendor services.
 [environment variables]: http://12factor.net/config
 [helm]: https://github.com/kubernetes/helm
 [release]: ../reference-guide/terms.md#release
-[slugrunner]: concepts.md#slugrunner
diff --git a/src/users/cli.md b/src/users/cli.md
index 238c51405..f662b8605 100644
--- a/src/users/cli.md
+++ b/src/users/cli.md
@@ -6,8 +6,7 @@ with Drycc Workflow.
 ## Installation
 
 Install the latest `drycc` client for Linux or Mac OS X with:
-
-    $ curl -sSL https://raw.githubusercontent.com/drycc/workflow-cli/main/install.tmpl | bash -s v1.1.0
+    $ curl -sfL https://drycc.cc/install-cli.sh | bash -
 
 The installer puts `drycc` in your current directory, but you should move it
 somewhere in your $PATH:
@@ -67,9 +66,13 @@ Examples:
 
     $ DRYCC_PROFILE=production drycc login drycc.production.com
     ...
+    Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+    Waiting for login... .o.Logged in as drycc
     Configuration saved to /home/testuser/.drycc/production.json
     $ DRYCC_PROFILE=~/config.json drycc login drycc.example.com
     ...
+    Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+    Waiting for login... .o.Logged in as drycc
     Configuration saved to /home/testuser/config.json
 
 The configuration flag works identically to and overrides `$DRYCC_PROFILE`:
diff --git a/src/users/registration.md b/src/users/registration.md
index ce9c22e40..96423625b 100644
--- a/src/users/registration.md
+++ b/src/users/registration.md
@@ -1,12 +1,15 @@
 # Users and Registration
 
-Workflow use the passport component to create and authorize users
+Workflow use the passport component to create and authorize users, it can config options for LDAP authentication or browse passport web site to register users.
 
 ## Login to Workflow
 
 If you already have an account, use `drycc login` to authenticate against the Drycc Workflow API.
 
     $ drycc login http://drycc.example.com
+    Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+    Waiting for login... .o.Logged in as drycc
+    Configuration file written to /root/.drycc/client.json
 
 ## Logout from Workflow
 
