Use Dagster's EnvVar for secrets. Per the Dagster docs, EnvVar retrieves the value at run time and it will not be visible in the UI, while os.getenv reads when the code location loads and the value will be visible. For non-secret settings either works.
What the docs say
The Dagster guide on environment variables and secrets explains the difference directly. When you use os.getenv, the variable's value is retrieved when Dagster loads the code location and will be visible in the UI. When you use the EnvVar class, the value is retrieved at runtime and is not visible in the UI.
The guide lists benefits of EnvVar: better observability, since the UI shows information about configuration values sourced from environment variables; secret values hidden in the Launchpad, the Resources page and other places where configuration is displayed; and simpler testing, since you can pass string values directly to configuration instead of through the environment.
Where each fits
| Use | Pattern | Why |
|---|---|---|
| Database password, API token | EnvVar in resource or config | Hidden in the UI, read at run time |
| Region name, schema name | Either | Not sensitive, visibility helps debugging |
| Value needed to decide what code to load | os.getenv | Needed at load time, so never put a secret here |
The last row is the trap. If code at load time needs a value, it must use os.getenv, and the value becomes visible. So design your code so that load time decisions depend on non-secret values only, such as a deployment name.
The .env file note
The same guide says that if Dagster finds a .env file in the folder where the webserver is launched, it loads the variables automatically. The sample file in the docs shows a staging database password in plain text, and the guide lists points to keep in mind when using such a file.
That is fine on a laptop. Keep it out of version control, and do not carry it to a shared server. Add the file name to your ignore list and check that no history already contains one. For production, supply variables from your deployment platform or a secrets manager rather than a file on disk.
Checking what your UI shows
A simple review any team can run:
- Open the Launchpad and Resources pages for a job that uses credentials.
- Look for any value that looks like a key, token or password.
- If you find one, search the code for os.getenv on that name and change it to EnvVar.
- Rotate the credential, since it was visible to everyone with UI access.
- Check logs and run history for the same value.
What the UI hiding does not do
Hiding a value in the UI limits casual exposure. It does not stop code in your pipeline from printing the value, and it does not change who can run code in your deployment. Those are access control questions. See ETL pipeline secrets: where credentials leak and dbt secrets, environment variables and logs for the same pattern in other tools.
Safeguard's policy gates and dependency scanning can check the code and packages around a pipeline. For a first look, try the free scan at gold.safeguard.sh/scan.
Quick check
Can I use EnvVar for everything?
Only where a value is needed at run time. A value needed while the code location loads must use os.getenv, so keep secrets out of that path.
Is a .env file acceptable for production secrets?
The docs describe it as a convenience for loading variables. Production deployments should supply variables through the platform or a secrets manager, not a plain file.
Sources
- Using environment variables and secrets, Dagster documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
