Repository navigation
config:get does not distinguish between unset and empty env vars #3450
Description
When attempting to purge env vars from environments (when an env var has been removed from the application and is no longer necessary), we've been using config:get to grab the current values (for posterity) before removal.
However, a frustrating part of the current config:get behavior is that it does not give any indication that an env var is completely unset (does not exist).
Ideally, config:get with an unset env variable would exit with a nonzero status code, so we could respond accordingly and know that the env var is completely removed from the environment. As it stands, there is no way to tell the difference between an env var that is set to the empty string, from one that is unset entirely.
Activity
michaelmalave commentedon Jan 13, 2026
@jasonkarns Thanks for raising this. To help users like you distinguish between between these different cases, we're implementing a --json flag for this command. This will help distinguish between an unset config and an empty string as we will output a null value and a double quoted empty string respectively.
jasonkarns commentedon Jan 13, 2026
I appreciate that and it will be an improvement. However, I'm not sure that covers the use case.
I'd expect the
--shellflag to output the vars in a format that reproduces the same state. One should be able to pipe that output right back toconfig:setand have nothing change.While the
--jsonflag is helpful, it doesn't really address the issue, IMO.--shellformat should omit any vars that are not set.tlowrimore-heroku commentedon Jan 20, 2026
Hi @jasonkarns! 👋 I'm jumping in to assist on this issue. Quick question: is it necessary to use
heroku config:get <KEY> -a <app_name>for your use case, or could you useheroku config -a <app_name>with either the--shellor--jsonflag? I ask as the later command makes it easy to determine whether the env var is present but empty, or not present at all.Thanks for helping me better understand your use case!
jasonkarns commentedon Mar 22, 2026
I'm not sure I understand the question. It's a matter of correctness.
--shelland--jsonflags change the output format. Surely one wouldn't expect them to change the behavior or semantic content.That's why my initial recommendation is that a nonexistent env var would return a non-zero exit code (and hopefully include corresponding warning message to STDERR). This behavior would not be dependent upon the desired output format.
I recognize that the base output format (simply printing the value) can't distinguish between an empty string and "unset". That's why the exit code would be critical.