anchor.diff:    - [Spring](../../buildpacks/java/configuring-service-connections/spring-service-bindings.html)
     - [Grails](../../buildpacks/java/configuring-service-connections/grails-service-bindings.html)
   
  +## <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.
  +
  +
   ## <a id='troubleshoot-push'></a>Troubleshoot App Push Problems
   
   If your app does not start on <%= vars.product_short %>, first ensure that the app can run locally.
  
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: ## <a id="overview"></a> Overview
  
  The cf CLI command `cf push` pushes apps to <%= vars.product_short %>.
  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).
  
  