docs: unify all Procfile-handling documentation under the process management docs

This makes it more clear as to how the various builders utilize the Procfile, and also ensures we don't have conflicting information anywhere.

docs/deployment/builders/cloud-native-buildpacks.md

@@ -159,3 +159,7 @@ dokku buildpacks:set-property --global stack paketobuildpacks/build:base-cnb
 # unset globally
 dokku buildpacks:set-property --global stack
 ```
+
+### Specifying commands via Procfile
+
+See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.

docs/deployment/builders/dockerfiles.md

@@ -198,28 +198,7 @@ Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disa
 
 > New as of 0.5.0
 
-You can also customize the run command using a `Procfile`, much like you would on Heroku or
-with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types). The commands in your app's Procfile will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
-
-```Procfile
-web: bin/run-prod.sh
-worker: bin/run-worker.sh
-```
-
-And `Dockerfile`:
-
-```Dockerfile
-FROM ubuntu:20.04
-WORKDIR /app
-COPY . ./
-CMD ["bin/run-dev.sh"]
-```
-
-When the above example is deployed, the `web` process is started, with the command `bin/run-prod.sh` executed in the container. All other processes must be scaled up separately. If the app's `Dockerfile` contains an `ENTRYPOINT` directive, the command specified in the `Procfile` will be passed to that entrypoint script as an argument.
-
-See the [scaling apps documentation](/docs/processes/process-management.md#scaling-apps) for more information on how process scaling is performed.
-
-See the [app.json location documentation](/docs/processes/process-management.md#changing-the-procfile-location) for more information on where to place your `Procfile` file.
+See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.
 
 ### Exposed ports
 

docs/deployment/builders/herokuish-buildpacks.md

@@ -322,31 +322,6 @@ This will use the latest commit on the `master` branch of the specified buildpac
 dokku buildpacks:set node-js-app https://github.com/heroku/heroku-buildpack-nodejs#v87
 ```
 
-### Specifying commands via Procfile
-
-While many buildpacks have a default command that is run when a detected repository is pushed, it is possible to override this command via a Procfile. A Procfile can also be used to specify multiple commands, each of which is subject to process scaling. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
-
-A Procfile is a file named `Procfile`. It should be named `Procfile` exactly, and not anything else. For example, `Procfile.txt` is not valid. The file should be a simple text file.
-
-The file must be placed in the root directory of your application. It will not function if placed in a subdirectory.
-
-If the file exists, it should not be empty, as doing so may result in a failed deploy.
-
-The syntax for declaring a `Procfile` is as follows. Note that the format is one process type per line, with no duplicate process types.
-
-```
-<process type>: <command>
-```
-
-If, for example, you have multiple queue workers and wish to scale them separately, the following would be a valid way to work around the requirement of not duplicating process types:
-
-```Procfile
-worker:           env QUEUE=* bundle exec rake resque:work
-importantworker:  env QUEUE=important bundle exec rake resque:work
-```
-
-The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
-
 ### `curl` build timeouts
 
 Certain buildpacks may time out in retrieving dependencies via `curl`. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a `curl` command.
@@ -361,3 +336,7 @@ dokku config:set --global CURL_CONNECT_TIMEOUT=180
 ### Clearing buildpack cache
 
 See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache) for more information on how to clear buildpack build cache for an application.
+
+### Specifying commands via Procfile
+
+See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.

docs/deployment/schedulers/docker-local.md

@@ -84,7 +84,7 @@ By default, Dokku will deploy one instance of a given process type at a time. Th
 
 The `formation` key should be specified as follows in the `app.json` file:
 
-```Procfile
+```json
 {
   "formation": {
     "web": {