anchor.diff:  ## <a id="overview"></a> Overview
   
   The cf CLI command `cf push` pushes apps to <%= vars.product_short %>.
  -The `cf push` command uses flags and helper files that determine the following:
  -
  -* How the pushed app runs, including its route (URL), instance count, and memory limits.
  -* How the push process works: whether it's configured with a manifest, runs a startup script, or limits files uploaded to the Cloud Controller.
  -
  -To push an app using `cf push`, do the following:
  -
  -1. [Determine `cf push` Options](#options)
  -1. [Push the App](#push)
  -1. [(Optional) Configure App Services](#services)
  +There are two main ways to run the `cf push` command:
  +
  +- Run `cf push APP-NAME` to push an app the easiest way, using default settings.
  +- Run the `cf push` command with flags and helper files to customize:
  +    - How the pushed app runs, including its route (URL), instance count, and memory limits.
  +    - How the push process works: whether it's configured with a manifest, runs a startup script, or limits files uploaded to the Cloud Controller.
  +
  +The [Push with Defaults](#default-push) and [Push with Custom Settings](#custom-push) sections below detail both of these options.
   
   For an explanation of what <%= vars.product_short %> does when you run `cf push`, see [How Apps are Staged](../../concepts/how-applications-are-staged.html).
   
  
positive.code: <%= vars.recommended_by %> recommends that you explicitly exclude extraneous files residing within your app directory, particularly if your app is large.
  For example, if you build your app locally and push it as a binary, you can save resources by not uploading any of the app's source code.
  
  To exclude files from upload, specify them in a `.cfignore` file in the
  directory where you run the `cf push` command.
  
  For more information, see the [Ignore Unnecessary Files When Pushing](./prepare-to-deploy.html#exclude) section of the [Considerations for Designing and Running an App in the Cloud](./prepare-to-deploy.html) topic.
  
  ### <a id='profile'></a>(Optional) Configure Pre-Runtime Hooks
  
  <p class="note"><strong>Note</strong>: The Java buildpack does not support pre-runtime hooks.</p>
  
  To run custom initialization tasks for your app, include them in a `.profile` file in the root of your app directory. After <%= vars.product_short %> loads the buildpack for an app, it executes any `.profile` file that it finds, and the `.profile` tasks can access the language runtime environment.
  
  After <%= vars.product_short %> runs `.profile` tasks, it starts the app instance itself.
  
  As an example, the following `.profile` file uses `bash` to set a value for the environment variable `LANG`. Setting this value at the operating system level lets the app determine which language to use for error messages and instructions, collating sequences, and date formats:
  
  
negative.code: Your app root directory may also include a `.profile.d` directory that contains bash scripts that perform initialization tasks for the buildpack.
  Developers should not edit these scripts unless they are using a [custom buildpack](../../buildpacks/custom.html).
  
  <p class="note"><strong>Note</strong>: If you are using a PHP buildpack version prior to v4.3.18, the buildpack does not execute your PHP app's <code>.profile</code> script. Your PHP app will host the <code>.profile</code> script's contents.
  This means that any PHP app staged using the affected PHP buildpack versions can leak credentials placed in the <code>.profile</code> script.</p>
  
  Initialization tasks as described here are also called "pre-runtime hooks" and "`.profile` tasks".
  
  ### <a id='custom-push'></a> Custom Push the App
  
  To specify custom options when pushing an app with `cf push`, you can:
  
  * Include them in the `cf push APP-NAME` command itself.
  * Include them in a manifest file.
    - The manifest file must be named `manifest.yml` and reside in the directory where you run `cf push`.
    - The manifest can include the app name, which lets you run `cf push` with no arguments.
    - The manifest can also include a [Services](./manifest-attributes.html#services-block) block that lists service instances for the app to bind to automatically.
  * Both of the above, command-line options and a manifest.
  
  See [Deploying with App Manifests](./manifest.html) to learn how app settings change from push to push, and how command-line options, manifests, and commands like `cf scale` interact.
  
  See the [Cloud Foundry CLI Reference Guide](https://cli.cloudfoundry.org/en-US/cf/push.html) for a full list of `cf push` options.
  
  ### <a id='services'></a>(Optional) Configure App Services
  
  If a newly-pushed app has the same name and route as an older app version, the new app retains the service bindings and service configuration of the previously-pushed version.
  
  