Skip to content

Config: reference environment variables in configuration values - #32029

Open
andig wants to merge 1 commit into
masterfrom
feat/config-env-refs
Open

Config: reference environment variables in configuration values#32029
andig wants to merge 1 commit into
masterfrom
feat/config-env-refs

Conversation

@andig

@andig andig commented Jul 21, 2026

Copy link
Copy Markdown
Member

fixes #31880

Allows any configuration value to reference an environment variable instead of containing the secret inline. Entering ${env:SUPERVISOR_TOKEN} into a form field resolves the value from the process environment when the device is created.

  • resolution happens in util.DecodeOther, so it covers all device, plugin and global settings configuration, from both UI and yaml
  • ${env:NAME} is only substituted when it makes up the entire value, keeping it clear of the existing ${var} plugin placeholder syntax
  • an undefined variable is an error, surfaced like any other configuration error instead of silently configuring an empty credential
  • values are resolved when the device is created, so a rotated variable requires a restart

NOTE: Global yaml settings parsed by viper are not covered, since yaml configuration is being retired anyway.

@andig andig added the enhancement New feature or request label Jul 21, 2026

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • In envHookFunc, calling reflect.ValueOf(data).String() assumes data is a string and can panic for other source types; consider using a type assertion or fmt.Sprint to safely handle non-string inputs.
  • The envRef regex only allows \w in environment variable names, which may be too restrictive for some deployments; consider broadening the allowed character set or aligning with the actual constraints used elsewhere for env var names.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- In `envHookFunc`, calling `reflect.ValueOf(data).String()` assumes `data` is a string and can panic for other source types; consider using a type assertion or `fmt.Sprint` to safely handle non-string inputs.
- The `envRef` regex only allows `\w` in environment variable names, which may be too restrictive for some deployments; consider broadening the allowed character set or aligning with the actual constraints used elsewhere for env var names.

## Individual Comments

### Comment 1
<location path="util/decoder.go" line_range="25" />
<code_context>
+		return data, nil
+	}
+
+	m := envRef.FindStringSubmatch(reflect.ValueOf(data).String())
+	if m == nil {
+		return data, nil
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard against nil `data` before calling `reflect.ValueOf` to avoid a panic.

`data` can still be `nil` or a non-string when the hook is invoked, and `reflect.ValueOf(nil)` will panic. Add a nil check (e.g. `if data == nil { return data, nil }`) before calling `reflect.ValueOf` to prevent this.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread util/decoder.go
return data, nil
}

m := envRef.FindStringSubmatch(reflect.ValueOf(data).String())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): Guard against nil data before calling reflect.ValueOf to avoid a panic.

data can still be nil or a non-string when the hook is invoked, and reflect.ValueOf(nil) will panic. Add a nil check (e.g. if data == nil { return data, nil }) before calling reflect.ValueOf to prevent this.

@andig

This comment has been minimized.

@github-actions

Copy link
Copy Markdown
Contributor

✅ Build finished.

@andig andig added the waiting for feedback Suspended progress label Jul 22, 2026
@github-actions github-actions Bot added the stale Outdated and ready to close label Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request needs documentation Triggers issue creation in evcc-io/docs stale Outdated and ready to close waiting for feedback Suspended progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Guided form: reference a secret from an environment variable instead of typing it inline

1 participant