Layering Support

Lono supports a concept called layering. Layering is how lono merges multiple files together to produce a final result. This is useful for building multiple environments. For example, it is common to build separate production and development environment. Most of the infrastructure is the same except for a few parts that require specific environment overrides. Lono’s layering ability makes this simple to do.

Going through a few examples of how lono performs layering will help make it clear the power of layering.

Templates Layering

You configured your lono templates in the app/definitions folder. The starter project sets up a standard directory structure that layering is designed for. Here’s an example structure:

└── app
    └── definitions
        ├── base.rb
        ├── development.rb
        └── production.rb

Let’s say these template definition files contain the following:


template "example" do
  source "example"


template "example" do
  source "example-dev"


template "example" do
  source "example-prod"

Essentially with layering, when lono generate is called it will first evaluate app/definitions/base.rb and then evaluate the LONO_ENV specific definitions file. By default LONO_ENV=development, so the evaluation order looks like this:

  1. app/definitions/base.rb
  2. app/definitions/base/* # all files in this folder
  3. app/definitions/development.rb
  4. app/definitions/development/* # all files this folder

This layering results in lono generating different output/templates.yml with different template source views based on what LONO_ENV is set to. For example:

lono generate # LONO_ENV=development is default, so output/example.yml uses templates/example-dev.yml
LONO_ENV=production lono generate # output/example.yml uses templates/example-prod.yml
LONO_ENV=sandbox lono generate # output/example.yml uses templates/example.yml since there is no app/definitions/sandbox.rb yet

Notice, how for LONO_ENV=sandbox because there are no app/definitions/sandbox.rb the app/definitions/base.rb definition is used.

The layering ability of the templates definitions allows you to override which template view to use based on LONO_ENV. With this ability, you can have common infrastructure code in the base folder and override the specific environment parts.

Variables Layering

Layering is performed for the config/variables folder. Let’s say you have the following variables directory structure:

├── base.rb
├── development.rb
└── production.rb

In this case, you want to define your common variables used for templates in the config/variables/base.rb. Specific environment overrides can be defined in their respective LONO_ENV variables file. For example:


@min_size = 1
@max_size = 1


@min_size = 10
@max_size = 20

When lono generate is called with LONO_ENV=production it will use 20 for the @max_size variable. For other LONO_ENV values, the @max_size variable will be set to 1.

Depending on how you use variables with layering, you can dramatically simpify your template definitions and param files. Most of the time, you can get the template definition to a single line and use a single config/params/base file for the template.

Params Layering

Layering is also performed during param generation. For example, given the following param structure:

├── base
│   └── example.txt
└── production
    └── example.txt

When launching the example stack, lono will overlay the LONO_ENV specific param values on top of the base params values and use that result. For example, given:





Lono will use the InstanceType=t2.small parameter value when launching the stack with LONO_ENV=production. Lono will use InstanceType=t2.medium for all other LONO_ENV values. Example:

$ lono cfn create example # InstanceType=t2.small
$ LONO_ENV=production lono cfn create example # InstanceType=t2.medium


Lono’s layering concept provides you with the ability to define common infrastructure components and override them for specific environments when necessary. This helps you build multiple environments in an organized way. The layering processing happens for these lono components:

  • app/definitions - your template definitions and configurations.
  • config/variables - your shared variables available to all of your templates.
  • config/params - the runtime parameters you would like the stack to be launched with.

Pro tip: Use the <- and -> arrow keys to move back and forward.

Edit this page

See a typo or an error? You can improve this page. This website is available on GitHub and contributions are encouraged and welcomed. We love pull requests from you!