Why not put these .env variables inside the checks.yaml config file? What is the advantage of two config files with two separate syntaxes?
The idea is the values in .env files can be configured via environment variables, while checks.yaml is for things that can be hard coded.
In this case it's a bit moot because the yaml file works like a database, but when you deploy this using, say, Docker or k8s, you can use a different method to configure environment variables and skip .env files.
Why can't I change the port of my database server via an environment variable? This would be required for e.g. Nomad support.
If this is a goal, why is it a goal for only half the configuration?
Something I do in my yaml configs is support ${ENV} template variables with the string Template's substitute method using *os.environ.
good question and answer … on a tangent, it makes me wonder if YAMLscript could be used to preload .env values on startup