Guides
This page applies the model to a real workflow. Open the guides overview
Docker¶
Use envctl with Docker when you want the container runtime to receive
an explicit, validated environment instead of relying on unclear shell state or stale local files.
When to use this guide¶
Use this page when:
- Docker or Compose should receive the resolved environment explicitly
- local runtime and container runtime tend to drift
- you need to decide between
run,export, and file-based handoff
Starting point¶
The goal is simple:
- validate first
- choose one explicit projection path
- give Docker only what it should actually receive
A good Docker workflow with envctl makes the runtime handoff more visible, not less.
The default path: run¶
Use run when the Docker command can inherit environment variables from the parent process:
$ envctl check
$ envctl run -- docker compose up
Choose this when you want the narrowest handoff and do not want to write a dotenv file first.
Use export when Docker expects a file¶
Some workflows need an explicit env file:
Use this when Docker tooling already expects file-based input.
Profiles fit naturally here¶
Profiles are often the cleanest way to keep Docker-specific local context separate:
Same shared contract, different local value set.
Common mistakes to avoid¶
- treating exported dotenv files as the source of truth
- skipping
checkbecause “Docker will fail anyway” - mixing shell exports, Docker env files, and
envctlwithout a clear order
A useful rule¶
In practice:
- prefer
runwhen subprocess inheritance is enough - prefer
exportwhen Docker truly needs a file - keep the handoff narrow and explicit
Read next¶
Debugging¶
Use a more explicit flow when the container still sees the wrong value.