anchor.diff:  	end
   	```
   
  -* **A Golang sidecar**<br>The `config-server-sidecar` produces a `config-server` binary. It provides apps with their required configuration over its `/config` endpoint. It also accepts connections only over localhost on the `CONFIG_SERVER_PORT` port, which means it must be co-located in the same conrtainer so that it shares the same network namespace as the main app. This makes it a good candidate for the sidecar pattern. 
  +* **A Golang sidecar**<br>The `config-server-sidecar` produces a `config-server` binary. It provides apps with their required configuration over its `/config` endpoint. It also accepts connections only over localhost on the `CONFIG_SERVER_PORT` port. This means the sidecar must be co-located in the same container as the app, so that it shares the same network namespace as the main app. 
   
   The diagram below illustrates the app architecture:
   
  
positive.code: 
  <p class="note"><strong>Note</strong>: This procedure uses <code>v3</code> commands because it requires the server-side manifest support in CAPI v3.</p>
  
  1. If your app does not exist yet, create it:
  
  	```
  	cf v3-create-app MY-APP
  	```
  
  1. If you do not already have one, create a manifest file in the root directory of your app, such as `manifest.yml`. For more information, see [Deploying with App Manifests](./deploy-apps/manifest.html). 
  
  1. Add the following content to your app manifest file under the `applications` key:
  
  
negative.code: 
  You can run additional processes in the same container as your app. These are called sidecar processes, or sidecars. An example of a sidecar is an Application Performance Monitoring (APM) tool. 
  
  When you provide a sidecar for your app, Cloud Foundry packages the required code and configuration needed to run the sidecar and app in the same droplet. It deploys this droplet in a single container on Diego. Both processes within the container are health checked independently.
  
  For additional information about sidecars, see the _Sidecars_ section of the [CAPI v3 documentation](http://v3-apidocs.cloudfoundry.org/version/release-candidate/#sidecars). 
  
  
  ## <a id="use-case"></a> Use Cases
  
  You can use sidecars for processes that depend on each other or must run in the same container. 
  
  For example, you can use sidecars for processes that must do the following:
  
  * Communicate over a Unix socket or through localhost
  * Share the same filesystem
  * Be scaled and placed together
  * Have fast interprocess communication
  
  ## <a id="limitations"></a> Limitations
  
  Sidecars have the following limitations:
  
  * The start and stop order of app processes and their sidecars is undefined.
  * App processes and sidecars are codependent. If either crashes or exits, the other will as well.
  * Sidecars are currently not independently scalable. Sidecars share resources with the main app process and other sidecars within the container. 
  * Sidecars only support PID-based health checks. HTTP health-checks for sidecars are not currently supported.
  
  ## <a id="create"></a> Push an App with a Sidecar
  
  This section provides instructions for pushing an app with a sidecar. For an example that you can try yourself, see the [Sidecar Tutorial](#tutorial) section below. 
  
  ### <a id="prerequisite"></a> Prerequisites
  
  Before you can push an app with a sidecar, you must have the following:
  
  * An app that is currently running or ready to be pushed. 
  * A file that Cloud Foundry can execute inside the app container as a sidecar process. For example, an executable binary, a Java .jar file, or Ruby scripts.
  
  ### <a id="create"></a> Procedure
  
  