<commit_before>---
title: Deploying with Application Manifests
---

_This page assumes you are using cf CLI v6._

Application manifests tell `cf push` what to do with applications. This includes everything from how many instances to create and how much memory to allocate to what services applications should use.

A manifest can help you automate deployment, especially of multiple applications at once.

##<a id='find-manifest'></a>How cf push Finds the Manifest ##

By default, the `cf push` command deploys an application using a `manifest.yml`
file in the current working directory.
Use the `-f` option to provide a non-standard manifest location or filename.

To use `cf push` without an `-f` option, you must provide a manifest named `manifest.yml` in the current working directory.

~~~
$ cf push
Using manifest file /path_to_working_directory/manifest.yml
~~~

With the `-f` option, a path with no filename means that the filename must be `manifest.yml`.

~~~
$ cf push -f ./some_directory/some_other_directory/
Using manifest file /path_to_working_directory/some_directory/some_other_directory/manifest.yml
~~~

If the manifest is named something other than `manifest.yml`, use the `-f` option with both path _and_ filename.

~~~
$ cf push -f ./some_directory/some_other_directory/alternative_manifest.yml
Using manifest file /path_to_working_directory/some_directory/some_other_directory/alternative_manifest.yml
~~~

## <a id='minimal-manifest'></a>A Minimal Manifest ##

You can deploy applications without ever using a manifest. The benefits manifests may provide include consistency and reproducibility. When you want applications to be portable between different clouds, manifests may prove especially useful.

Manifests are written in YAML. The minimal manifest illustrated below introduces some YAML indentation conventions that your manifests should follow.

 <%= image_tag("minimal_manifest_v6_edit1.png") %>

The directory that contains the bits you want to push is a good place to put your manifest and to run `cf push`, because `cf` looks for a manifest in the current working directory.

## <a id='name'></a>Always Provide an Application Name to cf push ##

`cf push` requires an application name, which you provide either in a manifest or at the command line.

As described in [How cf push Finds the Manifest](#find-manifest) above, the simple command `cf push` works when the `manifest.yml` file is in the current working directory.

If you do _not_ use a manifest, the minimal push command looks like this:

~~~
cf push my-application-name
~~~

<p class="note"><strong>Note</strong>: When you provide an application name at the command line, <code>cf push</code> uses that application name whether or not there is a different application name in the manifest.
If the manifest describes multiple applications, you can push a single application by providing its name at the command line; <code>cf</code> does not push the others.
These behaviors are useful for testing.</p>

## <a id='find-app'></a>How cf push Finds the Application ##

By default, `cf push` recursively pushes the contents of the current working directory. Alternatively, you can provide a path using either a manifest or a command line option.

- If the path is to a directory, `cf push` recursively pushes the contents of that directory instead of the current working directory.
- If the path is to a file, `cf push` pushes only that file.

<p class="note"><strong>Note</strong>: If you want to push more than a single file, but not the entire contents of a directory, consider using a <code>.cfignore</code> file to tell <code>cf push</code> what to exclude.</p>

## <a id='precedence'></a>Precedence Between Manifests, Command line Options, and Most Recent Values ##

When you push an application for the first time, Cloud Foundry applies default values to any attributes that you do not set in a manifest or `cf push` command line options.

* For example, `cf push my-application-name` with no manifest might deploy one instance of the app with one gigabyte of memory.
In this case the default values for instances and memory are "1" and "1G", respectively.

Between one push and another, attribute values can change in other ways.

* For example, the `cf scale` command changes the number of instances.

The attribute values on the server at any one time represent the cumulative result of all settings applied up to that point: defaults, attributes in the manifest, `cf push` command line options, and commands like `cf scale`.
There is no special name for this resulting set of values on the server.
You can think of them as the most recent values.

`cf push` follows rules of precedence when setting attribute values:

* Manifests override most recent values, including defaults.
* Command line options override manifests.

In general, you can think of manifests as just another input to `cf push`, to be combined with command line options and most recent values.

## <a id='optional-attributes'></a>Optional Attributes ##

This section explains how to describe optional application attributes in manifests. Each of these attributes can also be specified by a command line option. Command line options override the manifest.

### <a id='buildpack'></a>The buildpack attribute

If your application requires a custom buildpack, you can use the `buildpack` attribute to specify its URL or name:

~~~
buildpack: buildpack_URL
~~~

<p class="note"><strong>Note</strong>: The <code>cf buildpacks</code> command lists the buildpacks that you can refer to by name in a manifest or a command line option.</p>

The command line option that overrides this attribute is `-b`.

### <a id='start-commands'></a>The command attribute ###

Some languages and frameworks require that you provide a custom command to start an application. Refer to the [buildpack](../../buildpacks/index.html) documentation to determine if you need to provide a custom start command.

You can provide the custom start command in your application manifest or on the command line.

* In your application manifest, add `command: START-COMMAND` to specify the custom start command.

  Example: To use `bundle exec rake VERBOSE=true` as a custom start command in your manifest, add the following line to your application manifest:

  ~~~
  command: bundle exec rake VERBOSE=true
  ~~~

* On the command line, use the `-c` flag to specify the custom start command.

  Example:

  ~~~
  $ cf push my-App -c "bundle exec rake VERBOSE=true"
  ~~~

  <p class="note"><strong>Note</strong>: The <code>-c</code> option with a value of 'null' forces <code>cf push</code> to use the buildpack start command. See <a href="./app-startup.html">About Starting Applications</a> for more information.</p>

### <a id='domain'></a>The domain attribute ###

Every `cf push` deploys applications to one particular Cloud Foundry instance.
Every Cloud Foundry instance may have a shared domain set by an admin.
Unless you specify a domain, Cloud Foundry incorporates that shared domain in the route to your application.

You can use the `domain` attribute when you want your application to be served from a domain other than the default shared domain.

~~~
domain: unique-example.com
~~~

The command line option that overrides this attribute is `-d`.

### <a id='instances'></a>The instances attribute ###

Use the `instances` attribute to specify the number of app instances you want to start upon push:

~~~
instances: 2
~~~

We recommend that you run at least two instances of any apps for which fault tolerance matters.

The command line option that overrides this attribute is `-i`.

### <a id='memory'></a>The memory attribute ###

Use the `memory` attribute to specify the memory limit for all instances of an app. This attribute requires a unit of measurement: `M`, `MB`, `G`, or `GB`, in upper case or lower case. For example:

~~~
memory: 1024M
~~~

The default memory limit is 1G. You might want to specify a smaller limit to conserve <%=vars.quota_resource%> if you know that your app instances do not require 1G of memory.

The command line option that overrides this attribute is `-m`.

### <a id='host'></a>The host attribute ###

Use the `host` attribute to provide a hostname, or subdomain, in the form of a string. This segment of a route helps to ensure that the route is unique. If you do not provide a hostname, the URL for the app takes the form of `APP-NAME.DOMAIN`.

~~~
host: my-app
~~~

The command line option that overrides this attribute is `-n`.

### <a id='path'></a>The path attribute
<commit_msg>document the use of hosts in manifest<commit_after>---
title: Deploying with Application Manifests
---

_This page assumes you are using cf CLI v6._

Application manifests tell `cf push` what to do with applications. This includes everything from how many instances to create and how much memory to allocate to what services applications should use.

A manifest can help you automate deployment, especially of multiple applications at once.

##<a id='find-manifest'></a>How cf push Finds the Manifest ##

By default, the `cf push` command deploys an application using a `manifest.yml`
file in the current working directory.
Use the `-f` option to provide a non-standard manifest location or filename.

To use `cf push` without an `-f` option, you must provide a manifest named `manifest.yml` in the current working directory.

~~~
$ cf push
Using manifest file /path_to_working_directory/manifest.yml
~~~

With the `-f` option, a path with no filename means that the filename must be `manifest.yml`.

~~~
$ cf push -f ./some_directory/some_other_directory/
Using manifest file /path_to_working_directory/some_directory/some_other_directory/manifest.yml
~~~

If the manifest is named something other than `manifest.yml`, use the `-f` option with both path _and_ filename.

~~~
$ cf push -f ./some_directory/some_other_directory/alternative_manifest.yml
Using manifest file /path_to_working_directory/some_directory/some_other_directory/alternative_manifest.yml
~~~

## <a id='minimal-manifest'></a>A Minimal Manifest ##

You can deploy applications without ever using a manifest. The benefits manifests may provide include consistency and reproducibility. When you want applications to be portable between different clouds, manifests may prove especially useful.

Manifests are written in YAML. The minimal manifest illustrated below introduces some YAML indentation conventions that your manifests should follow.

 <%= image_tag("minimal_manifest_v6_edit1.png") %>

The directory that contains the bits you want to push is a good place to put your manifest and to run `cf push`, because `cf` looks for a manifest in the current working directory.

## <a id='name'></a>Always Provide an Application Name to cf push ##

`cf push` requires an application name, which you provide either in a manifest or at the command line.

As described in [How cf push Finds the Manifest](#find-manifest) above, the simple command `cf push` works when the `manifest.yml` file is in the current working directory.

If you do _not_ use a manifest, the minimal push command looks like this:

~~~
cf push my-application-name
~~~

<p class="note"><strong>Note</strong>: When you provide an application name at the command line, <code>cf push</code> uses that application name whether or not there is a different application name in the manifest.
If the manifest describes multiple applications, you can push a single application by providing its name at the command line; <code>cf</code> does not push the others.
These behaviors are useful for testing.</p>

## <a id='find-app'></a>How cf push Finds the Application ##

By default, `cf push` recursively pushes the contents of the current working directory. Alternatively, you can provide a path using either a manifest or a command line option.

- If the path is to a directory, `cf push` recursively pushes the contents of that directory instead of the current working directory.
- If the path is to a file, `cf push` pushes only that file.

<p class="note"><strong>Note</strong>: If you want to push more than a single file, but not the entire contents of a directory, consider using a <code>.cfignore</code> file to tell <code>cf push</code> what to exclude.</p>

## <a id='precedence'></a>Precedence Between Manifests, Command line Options, and Most Recent Values ##

When you push an application for the first time, Cloud Foundry applies default values to any attributes that you do not set in a manifest or `cf push` command line options.

* For example, `cf push my-application-name` with no manifest might deploy one instance of the app with one gigabyte of memory.
In this case the default values for instances and memory are "1" and "1G", respectively.

Between one push and another, attribute values can change in other ways.

* For example, the `cf scale` command changes the number of instances.

The attribute values on the server at any one time represent the cumulative result of all settings applied up to that point: defaults, attributes in the manifest, `cf push` command line options, and commands like `cf scale`.
There is no special name for this resulting set of values on the server.
You can think of them as the most recent values.

`cf push` follows rules of precedence when setting attribute values:

* Manifests override most recent values, including defaults.
* Command line options override manifests.

In general, you can think of manifests as just another input to `cf push`, to be combined with command line options and most recent values.

## <a id='optional-attributes'></a>Optional Attributes ##

This section explains how to describe optional application attributes in manifests. Each of these attributes can also be specified by a command line option. Command line options override the manifest.

### <a id='buildpack'></a>The buildpack attribute

If your application requires a custom buildpack, you can use the `buildpack` attribute to specify its URL or name:

~~~
buildpack: buildpack_URL
~~~

<p class="note"><strong>Note</strong>: The <code>cf buildpacks</code> command lists the buildpacks that you can refer to by name in a manifest or a command line option.</p>

The command line option that overrides this attribute is `-b`.

### <a id='start-commands'></a>The command attribute ###

Some languages and frameworks require that you provide a custom command to start an application. Refer to the [buildpack](../../buildpacks/index.html) documentation to determine if you need to provide a custom start command.

You can provide the custom start command in your application manifest or on the command line.

* In your application manifest, add `command: START-COMMAND` to specify the custom start command.

  Example: To use `bundle exec rake VERBOSE=true` as a custom start command in your manifest, add the following line to your application manifest:

  ~~~
  command: bundle exec rake VERBOSE=true
  ~~~

* On the command line, use the `-c` flag to specify the custom start command.

  Example:

  ~~~
  $ cf push my-App -c "bundle exec rake VERBOSE=true"
  ~~~

  <p class="note"><strong>Note</strong>: The <code>-c</code> option with a value of 'null' forces <code>cf push</code> to use the buildpack start command. See <a href="./app-startup.html">About Starting Applications</a> for more information.</p>

### <a id='domain'></a>The domain attribute ###

Every `cf push` deploys applications to one particular Cloud Foundry instance.
Every Cloud Foundry instance may have a shared domain set by an admin.
Unless you specify a domain, Cloud Foundry incorporates that shared domain in the route to your application.

You can use the `domain` attribute when you want your application to be served from a domain other than the default shared domain.

~~~
domain: unique-example.com
~~~

The command line option that overrides this attribute is `-d`.

### <a id='instances'></a>The instances attribute ###

Use the `instances` attribute to specify the number of app instances you want to start upon push:

~~~
instances: 2
~~~

We recommend that you run at least two instances of any apps for which fault tolerance matters.

The command line option that overrides this attribute is `-i`.

### <a id='memory'></a>The memory attribute ###

Use the `memory` attribute to specify the memory limit for all instances of an app. This attribute requires a unit of measurement: `M`, `MB`, `G`, or `GB`, in upper case or lower case. For example:

~~~
memory: 1024M
~~~

The default memory limit is 1G. You might want to specify a smaller limit to conserve <%=vars.quota_resource%> if you know that your app instances do not require 1G of memory.

The command line option that overrides this attribute is `-m`.

### <a id='host'></a>The host attribute ###

Use the `host` attribute to provide a hostname, or subdomain, in the form of a string. This segment of a route helps to ensure that the route is unique. If you do not provide a hostname, the URL for the app takes the form of `APP-NAME.DOMAIN`.

~~~
host: my-app
~~~

The command line option that overrides this attribute is `-n`.

### <a id='hosts'></a>The hosts attribute ###

Use the `hosts` attribute to provide multiple hostnames or subdomains; each hostname will generate a unique route for the app. `hosts` can be used in conjuntion with `host`. If both attributes are defined, routes will be created for hostnames defined in both `host` and `hosts`.

~~~
hosts:
 - app_host1
 - app_host2
~~~

The command line option that overrides this attribute is `-n`.

### <a id='path'></a>The path attribute

{'fraction_non_alphanumeric': 0.07899073705745298, 'fraction_numerical': 0.0014775245780530772, 'mean_word_length': 4.5426771653543305, 'pattern_counts': {'":': 0, '<': 125, '<?xml version=': 0, '>': 125, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1762420', 'n_tokens_mistral': 4641, 'n_tokens_neox': 4451, 'n_words': 2502}