Layering Basics


Layering generally works the same for params and variables files. They use different folders. Example:


Params have a .env extension, and vars have a .rb extension. We’ll show a params example to cover the basics of layering.

├── base.env
├── dev.env
└── prod.env
  • base.env is always evaluated.
  • dev.env or prod.env is evaluated based on LONO_ENV.

In this case, you want to define your base params used for templates in the base.env and overrides in prod.env.

The basic example above shows layering with the top-level config folder. You can also define layers within the blueprint.

Separate Layers

You can have your layer files defined in the blueprint itself or at the project level. Example:

  • Blueprint Layers: These layers ship with the blueprint. Think of them as defaults that ship with the blueprint itself. IE: app/blueprints/demo/config. These layers are processed first and take lower precedence.
  • Project Layers: These layers are your project-specific settings. IE: config/blueprints/demo. These layers are processed later and take higher precedence. They override previous layer values.

It is recommended to define layers at the project-level, config/blueprints. This allow blueprints to be even more reusable.


More step-by-step docs are provided in the next documentation pages and go into more details on layering.