Menu
AWS CodeDeploy
User Guide (API Version 2014-10-06)

AWS CodeDeploy AppSpec File Reference

This topic is a reference only. For a conceptual overview of the AppSpec file, see Application Specification Files.

The application specification file (AppSpec file) is a YAML-formatted file used by AWS CodeDeploy to determine:

  • what it should install onto your instances from your application revision in Amazon S3 or GitHub.

  • which lifecycle event hooks to run in response to deployment lifecycle events.

An AppSpec file must be named appspec.yml and it must be placed in the root of an application's source code's directory structure. Otherwise, deployments will fail.

After you have a completed AppSpec file, you bundle it, along with the content to deploy, into an archive file (zip, tar, or compressed tar). For more information, see Working with Application Revisions.

Note

The tar and compressed tar archive file formats (.tar and .tar.gz) are not supported for Windows Server instances.

After you have a bundled archive file (known in AWS CodeDeploy as a revision), you upload it to an Amazon S3 bucket or Git repository. Then you use AWS CodeDeploy to deploy the revision. For instructions, see Deploying Revisions.

AppSpec file Structure

The AppSpec file has the following high-level structure:

version: 0.0
os: operating-system-name
files:
  source-destination-files-mappings
permissions:
  permissions-specifications
hooks:
  deployment-lifecycle-event-mappings

In this structure:

version

This section specifies the version of the AppSpec file. Do not change this value. It is reserved by AWS CodeDeploy for future use.

os

This section specifies the operating system value for the instance.

files

This section specifies the names of files that should be copied to the instance during the deployment's Install event.

permissions

This section specifies how special permissions, if any, should be applied to the files in the files section as they are being copied over to the instance. This section applies to Amazon Linux, Ubuntu Server, and Red Hat Enterprise Linux (RHEL) instances only.

hooks

This section specifies scripts to run at specific deployment lifecycle events during the deployment.

version Section

Indicates the version of your application specification file. It is required. Currently the only allowed value is 0.0.

os Section

Indicates the operating system of the instance to which you will deploy. It is required. The following values can be specified:

  • linux – The instance is an Amazon Linux, Ubuntu Server, or RHEL instance.

  • windows – The instance is a Windows Server instance.

files Section

Provides information to AWS CodeDeploy about which files from your application revision should be installed on the instance during the deployment's Install event. This section is required only if you will be copying files from your revision to locations on the instance during deployment.

This section has the following structure:

files:
  - source: source-file-location
    destination: destination-file-location

Multiple source and destination pairs can be set.

The source instruction identifies a file or directory from your revision to copy to the instance:

  • If source refers to a file, only the specified file will be copied to the instance.

  • If source refers to a directory, then all files in the directory will be copied to the instance.

  • If source is a single slash (/), then all of the files from your revision will be copied to the instance.

The paths used in source are relative paths, starting from the root of your revision.

The destination instruction identifies the location on the instance where the files should be copied. This must be a fully qualified path.

Here's an example files section for an Amazon Linux, Ubuntu Server, or RHEL instance.

files:
  - source: Config/config.txt
    destination: /webapps/Config
  - source: source
    destination: /webapps/myApp

In this example, the following two operations will be performed during the Install event:

  1. Copy the Config/config.txt file in your revision to the /webapps/Config/config.txt path on the instance.

  2. Recursively copy all of the files in your revision's source directory to the /webapps/myApp directory on the instance.

files Examples

The following examples show how to specify the files section. Although these examples describe Windows Server file and directory (folder) structures, they can easily be adapted for Amazon Linux, Ubuntu Server, and RHEL instances.

For the following examples, we assume these files appear in the root of source:

  • appspec.yml

  • my-file.txt

  • my-file-2.txt

  • my-file-3.txt

# 1) Copy only my-file.txt to the destination folder c:\temp.
#
files:
  - source: .\my-file.txt
    destination: c:\temp
#
# Result:
#   c:\temp\my-file.txt
#
# ---------------------
#
# 2) Copy only my-file-2.txt and my-file-3.txt to the destination folder c:\temp.
#
files:
  - source: my-file-2.txt
    destination: c:\temp
  - source: my-file-3.txt
    destination: c:\temp
#
# Result:
#   c:\temp\my-file-2.txt
#   c:\temp\my-file-3.txt
#
# ---------------------
#
# 3) Copy my-file.txt, my-file-2.txt, and my-file-3.txt (along with the appspec.yml file) to the destination folder c:\temp.
#
files:
  - source: \
    destination: c:\temp
#
# Result:
#   c:\temp\appspec.yml
#   c:\temp\my-file.txt
#   c:\temp\my-file-2.txt
#   c:\temp\my-file-3.txt

For the following examples, we assume the appspec.yml appears in the root of source along with a folder named my-folder that contains three files:

  • appspec.yml

  • my-folder\my-file.txt

  • my-folder\my-file-2.txt

  • my-folder\my-file-3.txt

# 4) Copy the 3 files in my-folder (but do not copy my-folder itself) to the destination folder c:\temp. 
#
files:
  - source: .\my-folder
    destination: c:\temp
#
# Result:
#   c:\temp\my-file.txt
#   c:\temp\my-file-2.txt
#   c:\temp\my-file-3.txt
#
# ---------------------
#
# 5) Copy my-folder and its 3 files to my-folder within the destination folder c:\temp.
#
files:
  - source: .\my-folder
    destination: c:\temp\my-folder
#
# Result:
#   c:\temp\my-folder\my-file.txt
#   c:\temp\my-folder\my-file-2.txt
#   c:\temp\my-folder\my-file-3.txt
#
# ---------------------
#
# 6) Copy the 3 files in my-folder to other-folder within the destination folder c:\temp.
#
files:
  - source: .\my-folder
    destination: c:\temp\other-folder
#
# Result:
#   c:\temp\other-folder\my-file.txt
#   c:\temp\other-folder\my-file-2.txt
#   c:\temp\other-folder\my-file-3.txt	
#
# ---------------------
#
# 7) Copy only my-file-2.txt and my-file-3.txt to my-folder within the destination folder c:\temp.
#
files:
  - source: .\my-folder\my-file-2.txt
    destination: c:\temp\my-folder
  - source: .\my-folder\my-file-3.txt
    destination: c:\temp\my-folder
#
# Result:
#   c:\temp\my-folder\my-file-2.txt
#   c:\temp\my-folder\my-file-3.txt
#
# ---------------------
#
# 8) Copy only my-file-2.txt and my-file-3.txt to other-folder within the destination folder c:\temp.
#
files:
  - source: .\my-folder\my-file-2.txt
    destination: c:\temp\other-folder
  - source: .\my-folder\my-file-3.txt
    destination: c:\temp\other-folder
#
# Result:
#   c:\temp\other-folder\my-file-2.txt
#   c:\temp\other-folder\my-file-3.txt
#
# ---------------------
#
# 9) Copy my-folder and its 3 files (along with the appspec.yml file) to the destination folder c:\temp.
#
files:
  - source: \
    destination: c:\temp
#
# Result:
#   c:\temp\appspec.yml
#   c:\temp\my-folder\my-file.txt
#   c:\temp\my-folder\my-file-2.txt
#   c:\temp\my-folder\my-file-3.txt

permissions Section

The permissions section specifies how special permissions, if any, should be applied to the files and directories/folders in the files section after they are copied to the instance. Multiple object instructions can be specified. This section is optional. It applies to Amazon Linux, Ubuntu Server, and RHEL instances only.

This section has the following structure:

permissions:
  - object: object-specification
    pattern: pattern-specification
    except: exception-specification
    owner: owner-account-name
    group: group-name
    mode: mode-specification
    acls: 
      - acls-specification 
    context:
      user: user-specification
      type: type-specification
      range: range-specification
    type:
      - object-type

The instructions are as follows:

  • object – Required. This is a set of file system objects (files or directories/folders) that the specified permissions will be applied to after the file system objects are copied to the instance.

  • pattern – Optional. Specifies a pattern to apply permissions. If specified with the special characters "**", or if not specified altogether, the specified permissions will be applied to all matching files or directories, depending on the type.

  • except – Optional. Specifies any exceptions to pattern.

  • owner – Optional. The name of the owner of object. If not specified, all existing owners applied to the original file or directory/folder structure will remain unchanged after the copy operation.

  • group – Optional. The name of the group for object. If not specified, all existing groups applied to the original file or directory/folder structure will remain unchanged after the copy operation.

  • mode – Optional. An integer specifying the octal mode for the permissions to be applied to object. For example, 644 represents read and write permissions for the owner, read-only permissions for the group, and read-only permissions for all other users; while 4755 represents the setuid attribute being set, full control permissions for the owner, read and execute permissions for the group, and read and execute permissions for all other users. (For additional examples, see the Linux chmod command documentation.) If mode is not specified, all existing modes applied to the original file or directory/folder structure will remain unchanged after the copy operation.

  • acls – Optional. A list of character strings representing one or more Access Control List (ACL) entries applied to object. For example, u:bob:rw represents read and write permissions for user bob. (For additional examples, see ACL entry format examples in the Linux setfacl command documentation.) Multiple ACL entries an be specified. If acls is not specified, any existing ACLs applied to the original file or directory/folder structure will remain unchanged after the copy operation. These will replace any existing ACLs.

    Note

    Setting unnamed users, unnamed groups, or other similar ACL entries will cause the AppSpec file to fail. Use mode to specify these types of permissions instead.

  • context – Optional. For Security-Enhanced Linux (SELinux)-enabled instances, a list of security-relevant context labels to apply to the copied objects. Labels are specified as keys containing user, type, and range. (For more information, see the SELinux documentation.) If not specified, any existing labels applied to the original file or directory/folder structure will remain unchanged after the copy operation.

    • user – Optional. The SELinux user.

    • type – Optional. The SELinux type name.

    • range – Optional. The SELinux range specifier. This has no effect unless Multi-Level Security (MLS) and Multi-Category Security (MCS) is enabled on the machine. If MLS/MCS is not enabled, range defaults to s0.

  • type – Optional. The types of objects to apply the specified permissions to. This can be set to file or directory. If file is specified, the permissions will be applied only to files that are immediately contained within object after the copy operation (and not to object itself). If directory is specified, the permissions will be recursively applied to all directories/folders that are anywhere within object after the copy operation (but not to object itself).

permissions Example

The following example shows how to specify the permissions section with the object, pattern, except, owner, mode, and type instructions. This example applies to Amazon Linux, Ubuntu Server, and RHEL instances only. In this example, assume the following files and folders are copied to the instance in this hierarchy:

/tmp
  `-- my-app
       |-- my-file-1.txt
       |-- my-file-2.txt
       |-- my-file-3.txt
       |-- my-folder-1
       |     |-- my-file-4.txt
       |     |-- my-file-5.txt
       |     `-- my-file-6.txt
       `-- my-folder-2
             |-- my-file-7.txt
             |-- my-file-8.txt
             |-- my-file-9.txt
	         `-- my-folder-3

The following AppSpec file shows how to set permissions on these files and folders after they are copied:

version: 0.0
os: linux
# Copy over all of the folders and files with the permissions they
#  were originally assigned.
files:
  - source: ./my-file-1.txt
    destination: /tmp/my-app
  - source: ./my-file-2.txt
    destination: /tmp/my-app
  - source: ./my-file-3.txt
    destination: /tmp/my-app
  - source: ./my-folder-1
    destination: /tmp/my-app/my-folder-1
  - source: ./my-folder-2
    destination: /tmp/my-app/my-folder-2
# 1) For all of the files in the /tmp/my-app folder ending in -3.txt
#  (for example, just my-file-3.txt), owner = adm, group = wheel, and
#  mode = 464 (-r--rw-r--).
permissions:
  - object: /tmp/my-app
    pattern: "*-3.txt"
    owner: adm
    group: wheel
    mode: 464
    type:
      - file
# 2) For all of the files ending in .txt in the /tmp/my-app
#  folder, but not for the file my-file-3.txt (for example,
#  just my-file-1.txt and my-file-2.txt),
#  owner = ec2-user and mode = 444 (-r--r--r--).
  - object: /tmp/my-app
    pattern: "*.txt"
    except: [my-file-3.txt]
    owner: ec2-user
    mode: 444
    type:
      - file
# 3) For all the files in the /tmp/my-app/my-folder-1 folder except
#  for my-file-4.txt and my-file-5.txt, (for example,
#  just my-file-6.txt), owner = operator and mode = 646 (-rw-r--rw-).
  - object: /tmp/my-app/my-folder-1
    pattern: "**"
    except: [my-file-4.txt, my-file-5.txt]
    owner: operator
    mode: 646
    type:
      - file
# 4) For all of the files that are immediately under
#  the /tmp/my-app/my-folder-2 folder except for my-file-8.txt,
#  (for example, just my-file-7.txt and
#  my-file-9.txt), owner = ec2-user and mode = 777 (-rwxrwxrwx).
  - object: /tmp/my-app/my-folder-2
    pattern: "**"
    except: [my-file-8.txt]
    owner: ec2-user
    mode: 777
    type:
      - file
# 5) For all folders at any level under /tmp/my-app that contain
#  the name my-folder but not
#  /tmp/my-app/my-folder-2/my-folder-3 (for example, just
#  /tmp/my-app/my-folder-1 and /tmp/my-app/my-folder-2),
#  owner = ec2-user and mode = 555 (dr-xr-xr-x).
  - object: /tmp/my-app
    pattern: "*my-folder*"
    except: [tmp/my-app/my-folder-2/my-folder-3]
    owner: ec2-user
    mode: 555
    type:
      - directory
# 6) For the folder /tmp/my-app/my-folder-2/my-folder-3,
#  group = wheel and mode = 564 (dr-xrw-r--).
  - object: /tmp/my-app/my-folder-2
    group: wheel
    mode: 564
    type:
      - directory

The resulting permissions are as follows:

-r--r--r-- ec2-user root  my-file-1.txt
-r--r--r-- ec2-user root  my-file-2.txt
-r--rw-r-- adm      wheel my-file-3.txt

dr-xr-xr-x ec2-user root  my-folder-1
-rw-r--r-- root     root  my-file-4.txt
-rw-r--r-- root     root  my-file-5.txt
-rw-r--rw- operator root  my-file-6.txt

dr-xr-xr-x ec2-user root  my-folder-2
-rwxrwxrwx ec2-user root  my-file-7.txt
-rw-r--r-- root     root  my-file-8.txt
-rwxrwxrwx ec2-user root  my-file-9.txt

dr-xrw-r-- root     wheel my-folder-3

The following example shows how to specify the permissions section with the addition of the acls and context instructions. This example applies to Amazon Linux, Ubuntu Server, and RHEL instances only.

permissions:
  - object: /var/www/html/WordPress
    pattern: "**"
    except: [/var/www/html/WordPress/ReadMe.txt]
    owner: bob
    group: writers
    mode: 644
    acls: 
      - u:mary:rw
      - u:sam:rw
      - m::rw
    context:
      user: unconfined_u
      type: httpd_sys_content_t
      range: s0
    type:
      - file

hooks Section

The hooks section of the AppSpec file contains mappings that link deployment lifecycle event hooks to one or more scripts. If an event hook is not present, then no operation is executed for that event. This section is required only if you will be running scripts as part of the deployment.

The available event hooks are:

  1. ApplicationStop – This deployment lifecycle event occurs even before the application revision is downloaded. You can use this event if you want to gracefully stop the application or remove currently installed packages in preparation of a deployment. The AppSpec file and scripts used for this deployment lifecycle event are from the last successfully deployed application revision.

    Note

    An AppSpec file file does not exist on an instance before you deploy to it. For this reason, the ApplicationStop hook will not run the first time you deploy to the instance. You can use the ApplicationStop hook the second time you deploy to an instance.

    To determine the location of the last successfully deployed application revision, the AWS CodeDeploy agent looks up the location listed in the deployment-group-id_last_successful_install file. This file is located in:

     

    /opt/codedeploy-agent/deployment-root/deployment-instructions folder on Amazon Linux, Ubuntu Server, and RHEL Amazon EC2 instances.

    C:\ProgramData\Amazon\CodeDeploy\deployment-instructions folder on Windows Server Amazon EC2 instances.

     

    To troubleshoot a deployment that fails during the ApplicationStop deployment lifecycle event, see Troubleshooting a failed ApplicationStop deployment lifecycle event.

     

  2. DownloadBundle – During this deployment lifecycle event, the AWS CodeDeploy agent copies the application revision files to a temporary location:

     

    /opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive folder on Amazon Linux, Ubuntu Server, and RHEL Amazon EC2 instances.

     

    C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive folder on Windows Server Amazon EC2 instances.

     

    This event is reserved for the AWS CodeDeploy agent and cannot be used to run scripts.

     

    To troubleshoot a deployment that fails during the DownloadBundle deployment lifecycle event, see Troubleshooting a failed DownloadBundle deployment lifecycle event with "UnknownError: not opened for reading".

     

  3. BeforeInstall – You can use this deployment lifecycle event for preinstall tasks, such as decrypting files and creating a backup of the current version.

     

  4. Install – During this deployment lifecycle event, the AWS CodeDeploy agent copies the revision files from the temporary location to the final destination folder. This event is reserved for the AWS CodeDeploy agent and cannot be used to run scripts.

     

  5. AfterInstall – You can use this deployment lifecycle event for tasks such as configuring your application or changing file permissions.

     

  6. ApplicationStart – You typically use this deployment lifecycle event to restart services that were stopped during ApplicationStop.

     

  7. ValidateService – This is the last deployment lifecycle event. It is used to verify the deployment was completed successfully.

These event hooks occur in the order in which they are described here.

Deployment lifecycle events in order

Note

The Start, DownloadBundle, Install, and End events in the deployment cannot be scripted, which is why they appear in gray in this diagram. However, you can edit the files section of the AppSpec file to affect what's installed during the Install event.

This section has the following structure:

hooks:
   deployment-lifecycle-event-name
     - location: script-location
       timeout: timeout-in-seconds
       runas: user-name

You can include the following elements in a hook entry after the deployment lifecycle event name:

location

Required. The location of the script file for the revision.

timeout

Optional. The number of seconds to allow the script to execute before it is considered to have failed. The default is 3600 seconds (1 hour).

Note

3600 seconds (1 hour) is the maximum amount of time allowed for script execution for each deployment lifecycle event. If scripts exceed this limit, the deployment will stop and the deployment to the instance will fail. Make sure the total number of seconds specified in timeout for all scripts in each deployment lifecycle event do not exceed this limit.

runas

Optional. The user to impersonate when running the script. By default, this is the AWS CodeDeploy agent running on the instance. AWS CodeDeploy does not store passwords, so the user cannot be impersonated if the runas user needs a password. This element applies to Amazon Linux and Ubuntu Server instances only.

During each deployment lifecycle event, hook scripts can access the following environment variables:

APPLICATION_NAME

The name of the application in AWS CodeDeploy that corresponds to the current deployment (for example, WordPress_App).

DEPLOYMENT_ID

The ID AWS CodeDeploy has assigned to the current deployment (for example, d-AB1CDEF23).

DEPLOYMENT_GROUP_NAME

The name of the deployment group in AWS CodeDeploy that corresponds to the current deployment (for example, WordPress_DepGroup).

DEPLOYMENT_GROUP_ID

The ID of the deployment group in AWS CodeDeploy that corresponds to the current deployment (for example, b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE).

LIFECYCLE_EVENT

The name of the current deployment lifecycle event (for example, AfterInstall).

These environment variables are local to each deployment lifecycle event.

The following script changes the listening port on an Apache HTTP Server to 9090 instead of 80 if the value of DEPLOYMENT_GROUP_NAME is equal to Staging. This script must be invoked during the BeforeInstall deployment lifecycle event:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf
fi

The following script example changes the verbosity level of messages recorded in its error log from the warning to debug if the value of the DEPLOYMENT_GROUP_NAME environment variable is equal to Staging. This script must be invoked during the BeforeInstall deployment lifecycle event:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf
fi

The following script example replaces the text in the specified web page with text that displays the value of these environment variables. This script must be invoked during the AfterInstall deployment lifecycle event:

#!/usr/bin/python

import os
 
strToSearch="<h2>This application was deployed using AWS CodeDeploy.</h2>"
strToReplace="<h2>This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.</h2>"
 
fp=open("/var/www/html/index.html","r")
buffer=fp.read()
fp.close()
 
fp=open("/var/www/html/index.html","w")
fp.write(buffer.replace(strToSearch,strToReplace))
fp.close()

hooks Example

Here is an example of a hooks entry:

hooks:
   AfterInstall:
     - location: Scripts/RunResourceTests.sh
       timeout: 180

The Scripts/RunResourceTests.sh script will be run during the AfterInstall stage of the deployment process. The deployment will be unsuccessful if it takes the script more than 180 seconds (3 minutes) to run.

AppSpec File Example

Here is an example of an AppSpec file for an Amazon Linux, Ubuntu Server, or RHEL instance.

os: linux
files:
  - source: Config/config.txt
    destination: webapps/Config
  - source: source
    destination: /webapps/myApp
hooks:
  BeforeInstall:
    - location: Scripts/UnzipResourceBundle.sh
    - location: Scripts/UnzipDataBundle.sh
  AfterInstall:
    - location: Scripts/RunResourceTests.sh
      timeout: 180
  ApplicationStart:
    - location: Scripts/RunFunctionalTests.sh
      timeout: 3600
  ValidateService:
    - location: Scripts/MonitorService.sh
      timeout: 3600
      runas: codedeployuser

For a Windows Server instance, change os: linux to os: windows. Also, you must fully qualify the destination paths (for example, c:\temp\webapps\Config and c:\temp\webapps\myApp). Do not include the runas element.

Here is the sequence of events during deployment:

  1. Run the script located at Scripts/UnzipResourceBundle.sh.

  2. If the previous script returned an exit code of 0 (success), run the script located at Scripts/UnzipDataBundle.sh.

  3. Copy the file from the path of Config/config.txt to the path /webapps/Config/config.txt.

  4. Recursively copy all the files in the source directory to the /webapps/myApp directory.

  5. Run the script located at Scripts/RunResourceTests.sh with a timeout of 180 seconds (3 minutes).

  6. Run the script located at Scripts/RunFunctionalTests.sh with a timeout of 3600 seconds (1 hour).

  7. Run the script located at Scripts/MonitorService.sh as the user codedeploy with a timeout of 3600 seconds (1 hour).

AppSpec File Spacing

The following is the correct format for AppSpec file spacing. The numbers in square brackets indicate the number of spaces that must occur between items. For example, [4] means to insert four spaces between the items. AWS CodeDeploy will raise an error that may be difficult to debug if the locations and number of spaces in an AppSpec file are not correct.

version:[1]version-number
os:[1]operating-system-name
files:
[2]-[1]source:[1]source-files-location
[4]destination:[1]destination-files-location
permissions:
[2]-[1]object:[1]object-specification
[4]pattern:[1]pattern-specification
[4]except:[1]exception-specification
[4]owner:[1]owner-account-name
[4]group:[1]group-name
[4]mode:[1]mode-specification
[4]acls: 
[6]-[1]acls-specification 
[4]context:
[6]user:[1]user-specification
[6]type:[1]type-specification
[6]range:[1]range-specification
[4]type:
[6]-[1]object-type
hooks:
[2]deployment-lifecycle-event-name:
[4]-[1]location:[1]script-location
[6]timeout:[1]timeout-in-seconds
[6]runas:[1]user-name

Here is an example of a conforming AppSpec file:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/WordPress
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root

For more information about spacing, see the YAML specification.

Validating Your AppSpec File

You can use a YAML validator to validate your AppSpec file.

To verify that you have placed your AppSpec file in the root directory of the application's source content's directory structure, run one of the following commands:

For Linux, OS X, or Unix:

find /path/to/root/directory -name appspec.yml

If the AppSpec file is not located there, there will be no output.

For Windows:

dir path\to\root\directory\appspec.yml

If the AppSpec file is not located there, a "File Not Found" error will be displayed.