Skip to main content
The .lager file is a JSON configuration file that stores settings for the Lager CLI. There are two distinct versions of this file that serve different purposes: a global file shared across all projects, and a project-local file specific to a single project directory.

Two Files, Two Purposes

The CLI always knows which file to use. Commands like lager boxes and lager defaults read and write the global file. Commands like lager devenv and lager exec search upward from your current directory for a project-local file. The two files never conflict — they contain entirely different sections. When lager devenv terminal or lager exec starts a Docker container, the global ~/.lager file is automatically mounted inside the container at /lager/.lager (with LAGER_CONFIG_FILE_DIR=/lager), so that box and net definitions are available inside the container.

Global File (~/.lager)

The global file lives in your home directory and is shared across all projects. It stores your box registry, hardware net configurations, and command defaults.

DEFAULTS

Stores default values so you can omit common options from CLI commands. When you run a command without specifying --box or a net name, the CLI checks this section. Managed with lager defaults. Fields: Example:
CLI commands:
Resolution order: When a command needs a box or net name, it checks:
  1. Command-line option (--box, net argument) — highest priority
  2. LAGER_BOX environment variable (for box only)
  3. DEFAULTS section in global ~/.lager
  4. Error if required and not found

BOXES

Maps human-readable box names to their IP addresses. This is the box registry that all other commands use to resolve box names to IPs. Managed with lager boxes. Each entry can be either a simple IP string (legacy format) or an object with additional metadata. Fields (object format): Example:
CLI commands:

NETS

Stores hardware net configurations organized by box name. Each net maps a human-readable name to a physical hardware connection (channel on an instrument). Nets are stored in the global file but the actual net data lives on the box — this section serves as a local cache managed by lager nets. Structure: A dictionary keyed by box name, where each value is an array of net objects. Net object fields: Example:
CLI commands:

Project-Local File (./.lager)

The project-local file lives in your project directory (or any parent directory). The CLI finds it by searching upward from your current working directory. It is typically committed to version control so that all developers on a project share the same development environment configuration. This file is completely separate from the global ~/.lager — it contains different sections and is read by different commands.

How the local file is found

When you run lager devenv terminal, lager exec, or lager debug, the CLI starts in your current directory and walks up the directory tree until it finds a .lager file (that is not the global ~/.lager). The first one found is used.

DEVENV

Configures a Docker-based development environment for your project. Managed with lager devenv. When you run lager devenv terminal, the CLI reads this section to determine which Docker image to launch, where to mount your source code, and how to configure the container. When you run lager exec <name>, it reads the saved commands from this section. Fields: Paths in volumes may use ~, environment variables, and ${PROJECT_ROOT} (the directory containing .lager) so a committed .lager stays portable across machines — e.g. "${PROJECT_ROOT}:/workspace". CLI flags (--user, --group, --network, --platform, --entrypoint) take precedence over the config value when both are present. Any scalar key above can be set with lager devenv set <key> <value>, removed with lager devenv unset <key>, and the whole section printed with lager devenv show. | cmd.<name> | No | Custom named commands that can be executed with lager exec <name> | Example:
CLI commands:

DEBUG

Maps debug net names to local J-Link script file paths. Paths can be relative (resolved relative to the .lager file location) or absolute. This is separate from the jlink_script field on net objects in the NETS section of the global file. The DEBUG section provides project-local script overrides — lager debug commands check this section first before using the script stored on the box. This lets you keep J-Link scripts in your project repo and have them used automatically. Example:

includes

Maps destination names to source directories that should be uploaded alongside Python scripts run with lager python. This lets your test scripts import from external directories outside the project. Paths are resolved relative to the .lager file location. Example:
When you run lager python test_script.py, the CLI checks the local .lager for an includes section and uploads the referenced directories to the box so they are available as imports.

Environment Variables

These environment variables override the default file location and behavior:

Legacy Format Migration

Older .lager files may use lowercase section names. The CLI automatically upgrades these when writing: No manual migration is required. The CLI reads both formats and writes back the current uppercase format.

Complete Examples

Global ~/.lager

Project-local ./my-firmware/.lager