anchor.diff:  
   ## <a id='service-connection'></a>Step 6: (Optional) Configure Service Connections ##
   
  -If you bound a service to the application that you deployed, you might need to
  -configure your application with the service URL and credentials.
  -For more information, see the specific documentation for your application
  +If you bound a service to the app that you deployed, you might need to
  +configure your app with the service URL and credentials.
  +For more information, see the specific documentation for your app
   framework:
   
   * [Ruby](../../buildpacks/ruby/ruby-service-bindings.html)
  
positive.code: 
  ### <a id='profile'></a>Configure Pre-Runtime Hooks ###
  
  To configure pre-runtime hooks, create a file named `.profile` and place it in the root of your application directory. If the directory includes a `.profile` script, then Cloud Foundry executes it immediately before each instance of your application starts. Because the `.profile` script executes after the buildpack, the script has access to the language runtime environment created by the buildpack.
  
  <p class="note"><strong>Note</strong>: Your application root directory may also include a <code>.profile.d</code> directory that contains bash scripts that perform initialization tasks for the buildpack. Developers should not edit these scripts unless they are using a <a href="../../buildpacks/custom.html">custom buildpack</a>.</p>
  
  You can use the `.profile` script to perform application-specific initialization tasks, such as setting custom environment variables. Environment variables are key-value pairs defined at the operating system level. These key-value pairs provide a way to configure the applications running on a system. For example, any application can access the LANG environment variable to determine which language to use for error messages and instructions, collating sequences, and date formats.
  
  To set an environment variable, add the appropriate bash commands to your `.profile` file. See the example below.
  
  ~~~bash
  # Set the Java environment path for your applications
  export JAVA_HOME=/usr/lib/jvm/jdk1.7.0
  export PATH=$PATH:$JAVA_HOME/bin
  
  # Set the default LANG for your applications
  export LANG=en_US.UTF-8
  ~~~
  
  <p class="note"><strong>Note</strong>: If you are using a PHP buildpack version prior to v4.3.18, the buildpack will 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>
  
  ## <a id='push'></a>Step 5: Push the Application ##
  
  Run the following command to deploy an application without a manifest:
  
    `cf push APP-NAME`
  
  If you provide the application name in a manifest, you can reduce the command to
  `cf push`.
  See [Deploying with Application Manifests](./manifest.html).
  
  Since all you have provided is the name of your application, `cf push` sets the
  number of instances, amount of memory, and other attributes of your application
  to the default values.
  You can also use command-line options to specify these and additional
  attributes.
  
  The following transcript illustrates  how Cloud Foundry assigns default values
  to application when given a `cf push` command.
  
  <p class ="note"><strong>Note</strong>: When deploying your own apps, avoid generic names like <code>my-app</code>. Cloud Foundry uses the app name to compose the route to the app, and deployment fails unless the app has a globally unique route.</p>
  
  
negative.code: Before you deploy, you need to decide on the following:
  
  * **Name**: You can use any series of alpha-numeric characters, without spaces,
  as the name of your app.
  * **Instances**: Generally speaking, the more instances you run, the less
  downtime your app will experience.
  If your app is still in development, running a single instance can
  simplify troubleshooting.
  For any production app, we recommend a minimum of two instances.
  * **Memory Limit**: The maximum amount of memory that each instance of your
  app can consume.
  If an instance exceeds this limit, Cloud Foundry restarts the instance.
      <p class='note'><strong>Note</strong>: Initially, Cloud Foundry immediately
  	restarts any instances that exceed the memory limit. If an instance
  	repeatedly exceeds the memory limit in a short period of time, Cloud Foundry
  	delays restarting the instance.</p>
  * **Start Command**: This is the command that Cloud Foundry uses to start each
  instance of your app.
  This start command varies by app framework.
  * **Subdomain (host) and Domain**:
  The route, which is the combination of subdomain and domain, must be globally
  unique.
  This is true whether you specify a portion of the route or allow Cloud Foundry
  to use defaults.
  * **Services**: Apps can bind to services such as databases, messaging,
  and key-value stores.
  Apps are deployed into app spaces.
  An app can only bind to a service that has an existing instance in the
  target app space.
  
  ### <a id='defining-options'></a>Define Deployment Options ###
  
  You can define deployment options on the command line, in a manifest file, or
  both together.
  See [Deploying with Application 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.
  
  When you deploy an app while it is running, Cloud Foundry stops all instances of that app and then deploys.
  Users who try to run the app get a "404 not found" message while `cf push` runs.
  Stopping all instances is necessary to prevent two versions of your code from running at the same time.
  A worst-case example would be deploying an update that involved a database
  schema migration, because instances running the old code would not work and
  users could lose data.
  
  Cloud Foundry uploads all app files except version control files with
  file extensions `.svn`, `.git`, and `.darcs`.
  To exclude other files from upload, specify them in a `.cfignore` file in the
  directory where you run the push command.
  