denver
Development Environments as code — reproducible, flexible, simple and fast.
[!NOTE] This documentation is also published as plain Markdown, one file per page mirroring this exact page tree — meant for AI tools/LLMs to ingest directly, without having to scrape rendered HTML. Start at markdown/index.md
Introduction
Start here if you have never seen a denver.yml.
Quickstart
There are some examples that show denver in action
Concepts
The vocabulary, the philosophy and the design principles behind denver
denver command
Full reference documentation of the denver command line interface and
environment variables used by denver.
Configuration
The complete config schema reference (denver.yml, denver’s default, or
denver.toml): every top-level key, every generic stage key, how import:
chains merge, and the mechanisms behind layering, hooks, overrides and
fingerprinting.
Providers
One page per provider: a full key reference for that provider’s
denver.yml section (every key, what it does, its default) plus design
notes on the patterns it supports and how it behaves under
--fast/--force.
Provider |
Purpose |
|---|---|
Create/manage a Python virtualenv via |
|
Provision native tools (compilers, cmake, ninja) via Conan |
|
Wrapper: relocate the pipeline into a compose service |
|
Manage a West (Zephyr RTOS) workspace |
|
Fetch, verify and unpack prebuilt release archives |
|
Clone/fetch a git checkout, pinned to one revision |
|
Source a nix flake’s devShell into the environment |
|
Escape hatch: an arbitrary command, sourced script or launcher |
A project can also register its own provider, without a denver fork — see “Extension providers” in Configuration.
Architecture (arc42)
Why denver is built the way it is: the problem, the constraints, the decisions, and what is known to be weak. Structured after arc42.