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: 	delays restarting the instance.
  * **Start Command**: This is the command that <%= vars.product_short %> uses to start each
  instance of your app.
  This start command varies by app framework.
  * **Services**: Apps can bind to services such as databases, messaging,
  and key-value stores.
  Apps are pushed into app spaces.
  An app can only bind to a service that has an existing instance in the
  target app space.
  
  ### <a id='route'></a>Route
  
  <%= vars.product_short %> directs requests to an app based on its route.
  The route is a URL made up of a hostname and a domain, as in `https://HOSTNAME.example.com`.
  
  You can customize an app's hostname and domain or let `cf push` use the defaults.
  
  #### Route Defaults
  
  <%= vars.product_short %> default an app's route as follows:
  
  * **Hostname**: The name of the app.
    - If the app name contains underscores, <%= vars.product_short %> converts them to hyphens when creating the app's route.
  
  * **Domain**: The default apps domain for the <%= vars.product_short %> installation.
  
  #### (Optional) Customize Routes
  
  Do the following to customize an app's route:
  
  * **Hostname**
    - Pass the custom hostname to `cf push` with the `-n` flag.
  
  * **Domain**
    - Pass the custome domain to `cf push` with the `-d` flag.
    The custom domain must be registered, and mapped to the org that contains the app's target space
  
  #### Ensure Uniqueness
  
  The app's route must be globally unique, whether you let <%= vars.product_short %> use defaults
  for the host or domain, or specify custom values.
  
  To help ensure route uniqueness, you can use the following `cf push` options:
  
  * `-n` assigns a different HOST name for the app
  * `--random-route` creates a URL that includes the app name and random words
  
  <p class='note'><strong>Note</strong>: Run <code>cf help push</code> to view other options for the <code>cf push</code> command.</p>
  
  <%=vars.ssl%>
  
  
  
  For more information about domains, see [Routes and Domains](./routes-domains.html).
  
  ### <a name='manifests'></a>Manifests
  
  You can define push options on the command line, in a manifest 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.
  
  For more information about the manifest file, see the [Deploying with App Manifests](./manifest.html) topic.
  
  ### <a name='exclude'></a>Files to Upload
  
  <%= vars.product_short %> uploads all app files except version control files and
  folders with names such as `.svn`, `.git`, and `_darcs`.
  
  To exclude other files from upload, specify them in a `.cfignore` file in the
  directory where you run the `cf push` command.
  For example, if you build your app locally and push it as a binary, you can save resources by not uploading any of its source code.
  
  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 name='profile'></a>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 which language to use for error messages and instructions, collating sequences, and date formats:
  
  ~~~bash
  # Set the default LANG for your apps
  
negative.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)
  
  * 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.
  
  * All required app resources are uploaded.
  For example, you may need to include a database driver.
  
  * Your app can access an instance of every service that it needs, because the service instance is either running in or shared with the app's space. See [Determine the Org and Space](#space).
  
  * You have 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.
  
  ## <a id='options'></a>Determine cf push Options
  
  Before you push an app, you need to collect basic field values and make some choices.
  
  ### <a id='basic'></a>Collect Basic Field Values
  
  Before you push an app, you need values for the following fields, unless you want the defaults:
  
  