[Enhancement] Expand environment variables to non-sensitive

[cadalau]

Summary

It is good to see there is support for at the minimal environment variables for credentials (https://docs.pangolin.net/self-host/advanced/config-file#environment-variables, https://github.com/orgs/fosrl/discussions/830). However in an automated deployment scenario and for support / multiple environments / change control and config drift security problems it does make it more robust and secure to reduce the amount of hardcoded configurations stored on disk.

Feature: Expended Environment Variables
As a operator
I want to be able to configure all nodes on mass from source control
So I can run my secure deployment pipeline for updates / destroy and deploy

Scenario: Have all environment variables able to be populated from a secrets vault
Given a vault can inject config on compose up
When using a build script i can place more configs in env to be used to execute the compose from secrets vault
Then the solution should be able to accept all configurations specific to the environment

As an auditor
I want to be able to check code using my toolset connected to the source control in addition to nodes logs
So I can reduce the audit time on a secure deployment

As a security engineer
I want to be able to manage and reduce config drift
So I can meet the security profile or the organisation.

Just examples there are more but you probably get the idea.

Motivation

Automated configuration for environments reduces support resourcing and allows pushing more of the configuration to code over clickops. Security best practice config as code.

Proposed Solution

Expand the number of environment variables that can be used enabling more robust automated deployment.

Alternatives Considered

Hardcoded configs of not too sensitive information (current), change management, logging, permissions, hardcoded configs in code base deployed. Might be a big one depending on your architecture.

Additional Context

Might be a big one depending on your architecture.

https://dora.dev/capabilities/flexible-infrastructure/ (those I realise Wireguard is not NIST FIPS 140-3 and this solution not for the use of that purpose so just ignore the NIST references!).
https://12factor.net/ (2017)
https://oneuptime.com/blog/post/2026-02-20-twelve-factor-app-guide/view bit newer same sort of theory
https://github.com/orgs/fosrl/discussions/830