Persist Environment Variables the Right Way
Environment variables let you configure applications without hardcoding values — but only if you persist them correctly.
What
Environment variables configure application behavior without hardcoding values. They can be set temporarily for a single session using export, or persisted permanently by adding them to shell profile files like ~/.bashrc or ~/.zshrc. Every process inherits the environment of its parent.
Why It Matters
Hardcoding config values like API keys, database URLs, and feature flags into source code is a security risk and deployment nightmare. Environment variables separate configuration from code, making it easy to change settings per environment (dev, staging, prod) without modifying your application.
Example
# Set a variable for the current session only
export API_KEY="abc123"
export DATABASE_URL="postgres://localhost:5432/mydb"
# Persist variables by adding to your shell profile
# For bash:
echo 'export API_KEY="abc123"' >> ~/.bashrc
# For zsh:
echo 'export API_KEY="abc123"' >> ~/.zshrc
# Apply changes without restarting the terminal
source ~/.bashrc # or: source ~/.zshrc
# List all environment variables
env
printenv
# Check a specific variable
echo $API_KEY
printenv API_KEY
# Unset a variable
unset API_KEYCommon Mistake
Adding variables to ~/.bashrc but forgetting to run 'source ~/.bashrc' afterward, then wondering why the variable isn't available in the current terminal. Changes to profile files only take effect in new shells or after sourcing.
Quick Fix
After editing ~/.bashrc or ~/.zshrc, always run 'source ~/.bashrc' (or 'source ~/.zshrc') in your current terminal. Or simply open a new terminal window — it will automatically load the updated profile.
Key Takeaways
- 1export VAR=value sets a variable for the current session only
- 2Add to ~/.bashrc or ~/.zshrc to persist across sessions
- 3Run 'source ~/.bashrc' to apply changes to the current terminal
- 4Use 'env' or 'printenv' to list all environment variables
- 5Never hardcode secrets — use environment variables instead
Was this tip helpful?
Help us improve the DevOpsPath daily collection