Files sources

AWS Common configuration

As described in AWS IAM Override , you can override the IAM role you want to use when attempting to retrieve files from an AWS Service.

The IAM override defined the closest to the resource to retrieve is used. See IAM Override Priority for more details.

AWS S3 Source

This allows you to define an S3 source with the Bucket name and Object key that you want to retrieve.


All files downloaded from S3 are opened as a StreamingBody to avoid any casting error that could lead to corruption. You can download all types of files. (Flat files, Images and ZIP have been tested for that purpose)


Docker images meant to be immutable and light, we recommend to keep the files you retrieve from AWS S3 light to avoid complications and delay the startup of your applications.

AWS SSM Source

Similarly to AWS S3, this allows to retrieve the content of a SSM Parameter and store it as file. This can be useful simple credentials syntax and otherwise String defined parameters.


If you are using a SecureString, make sure that you IAM role has kms:Decrypt permissions on the KMS Key.

AWS Secrets Manager Source


This should only be used for very edgy use-cases, such as retrieving certificates stored as flat content in AWS SSM. You should absolutely use the AWS ECS Task Definition Secrets definitions

Url Source

Allows you to download a file from an arbitrary URL. You can specify basic auth credentials if the file is not publicly accessible.


We do not recommend to put the basic auth credentials in plain text in the configuration, unless the source of the configuration for ECS Files Composer comes from AWS Secrets manager.

Files Rendering

To allow further flexibility, you have the possibility to set a context which indicates whether the file should be used as a template for a supported renderer.


The default value is plain, which means no alteration at all is to be done and the file should be used as-is.


Do not attempt to perform rendering on a file that is not text (i.e. Images/ZIP etc.)

Jinja2 & Custom filters

Used in a lot of very well known frameworks and Applications, such as Ansible, Jinja2 is a very powerful template rendering engine. Therefore, that will allow you to use Jinja filters to alter the file as you need it to.


When using the jinja2 context, the file is placed into a randomly generated folder. That folder then auto-destroys itself once the processing of the given file is complete, and the file is then rendered and written at the defined location.

See also

More about Jinja2 and Jinja2 filters

env_override filter

This filter allows you to very simply interpolate an environment variable value from the key of that env var. Take the following example

    content: >-
      this is a test {{ "default" | env_override('ENV_VAR_TO_CHANGE') }}
    owner: john
    group: root
    mode: 600
    context: jinja2

Files composer will use the content as template, which has been written to a temporary directory. It then invokes Jinja, with the custom filter env_override . If the filter finds an environment variable named ENV_VAR_TO_CHANGE , it then retrieves the value and pass it to Jinja. If not, Jinja will use default as the value.