To confirm what I am observing, that a .env for secret or local testing environment values is not read by netlify build but is by netlify dev ?
Hi @moop-moop 
My use case is a site that has both a local .env and ‘prod’ env vars defined in the Netlify UI - but yes, from what I am seeing, netlify build does appear to actually be reaching out to the Netlify UI / home-base and using the env vars from there for environment context when running netlify build. I know for certain that netlify dev uses local .env vars, but I agree that this is an interesting finding.
Now, I’ll let the official Netlify team speak on the impetus for the behavior, but do recall that netlify build is indeed meant to be the full “production” build of a site. I can’t confirm this, but I even think I read somewhere that the actual build images are just running the very same netlify build to build your actual site image in the Netlify cloud… so if that’s the case, that does make sense.
May I ask why your would want different behavior?
Hope that helps!
–
Jon
Hey @moop-moop,
To tag on to Jon’s response, we’d love to know more about your use case and expected behaviours!
I am DevOps and work more on the build performance (and build plugin) side of things. So I am using netlify build all the time. Being able to use a .env file locally like netlify dev is mostly a matter of convenience. For build testing and development locally, I may need to use different keys, values. These might even be different from say the develop branch (context) that is deployed on Netlify proper. And I don’t want to permanently store in the netlify.toml.
I did learn about the ability to specify build context on the command line:
https://cli.netlify.com/commands/build
And using the Contextual ENV build plugin:
I can probably set up a number of ENV variables named with contexts in a Site I am working with. This is better than including the netlify.toml configuration file (with contexts), but not ideal since really this is temporary information. And I like simplicity. 
Thanks!
Makes sense! Since you have all the context, mind filing a feature request here? Then our dev team can consider implementing it, or let you know if they have something better than our Support team could think of: