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. [(Optional) Configure Domains](#domain)
   1. [Determine `cf push` Options](#options)
   1. [Push the App](#push)
   
  
positive.code:   - [Considerations for Designing and Running an App in the Cloud](./prepare-to-deploy.html)
    - Any [Buildpacks](../../buildpacks/index.html) guides specific to your app language or framework, such as [Getting Started Deploying Ruby on Rails Apps](../../buildpacks/ruby/gsg-ror.html)
  
  * All required app resources are uploaded.
  For example, you may need to include a database driver.
  
  * Extraneous files and artifacts are excluded from upload.
  You should explicitly exclude extraneous files that reside within your
  app directory structure, particularly if your app is large.
  
  * Every service that your app needs has an instance that it can access, for example running in the same space.
  
  * Your <%= vars.product_short %> installation supports the type of app you are going to
  push, or you have the URL of an externally-available buildpack that can stage
  the app.
  
  * You have all of the following:
    - The API endpoint for your <%= vars.product_short %> installation. Also known as the target
  URL, this is <%=vars.api_endpoint%>.
    - Your username and password for your <%= vars.product_short %> installation.
    - The organization and space where you want to push your app.
  A <%= vars.product_short %> workspace is organized into organizations, and within them,
  spaces.
  As a <%= vars.product_short %> user, you may have access to one or more organizations and
  spaces.
  
  ## <a id='options'></a>Push Options
  
  Before you push an app, you need to collect basic field values and decide on some larger options.
  
  ### <a name='basic'></a>Basic Fields
  
  Before you push an app, you need values for the following fields, unless you want the defaults:
  
  
negative.code: 
  ## <a id='push'></a> Push the App
  
  To push an app with default values for the number of instances, amount of memory, and other attributes, run the following command:
  
    `cf push APP-NAME`
  
  To specify options, as described in [Determine `cf push` Options](#options), include them in the `cf push` command itself, in a `manifest.yml` file, or both.
  
  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.
  
  ### <a id='updates'></a> App Updates and Downtime
  
  When you push an app that is already running, <%= vars.product_short %> stops all existing instances of that app. Users who try to access the app get a "404 Not Found" message while `cf push` runs.
  
  With some app updates, old and new versions of your code should never run at the same time. A worst-case example is if your app update migrates a database schema, causing old app instances to fail and lose user data.  To prevent this, you need to stop all running instances of your app before you push the new version.
  
  When old and new versions of your app can run simultaneously, you can avoid app downtime by using the [blue-green method](./blue-green.html) to swap routes between app versions running in parallel.
  
  