Project Structure

Here’s an example project structure.

├── app
│   └── blueprints
│       └── demo
│           └── template.rb
├── config
│   ├── app.rb
│   └── blueprints
│       └── demo
│           ├── params
│           │   ├── dev.env
│           │   └── prod.env
│           └── vars
│               ├── dev.rb
│               └── prod.rb
└── output
    └── demo
        ├── params.json
        └── template.yml

Files and Folders

To explain the files and folders, we’ll use the demo blueprint as an example:

File / Folders Description
app/blueprints Where blueprints live. Blueprints contain code to build CloudFormation templates. They can be configured with parameters and variables in config/blueprints. Blueprint Structure Docs.
app/blueprints/demo/template.rb Example of a blueprint template.rb. This is where you define your source code with the Lono DSL.
app/configsets Where configsets live. Configsets are essentially configuration management. Lono can inject them into your template making them reusable. They can be configured with config/blueprints/BLUEPRINT/configsets.
config/app.rb Lono’s behavior can be tailored with config/app.rb.
config/blueprints/demo/configsets Where configsets are configured. You can selectively add configsets to templates. Configsets Docs
config/blueprints/demo/params Where CloudFormation run-time parameters can be defined. Parameters are defined with env-like files.
config/blueprints/demo/vars Where Lono variables can be defined. Variables can be used to compile down different templates. This is useful when run-time parameters do not suffice.
output/demo/params.json Where the compiled CloudFormation parameters file get written to.
output/demo/template.yml Where the compiled CloudFormation template get written to.

That’s the basic lono project structure.