Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jeremylongshore/langchain-multi-env-setup
Build reliable dev / staging / prod isolation for LangChain 1.0 services — Pydantic `Settings` + `SecretStr`, cloud Secret Manager in prod, per-env prompt and model version pinning, env-specific checkpointer and observability.
Passed 22 of 23 test cases with the skill, and 11 of 23 without it.
and 14 more in the full report
11 fixed11 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are moving a LangChain application to production containers and need to eliminate security vulnerabilities where API keys get dumped in plain text via process environment inspection tools like container exec. Could you provide a Python configuration module using Pydantic Settings that safely loads API keys into memory across dev, staging, and production environments without polluting the OS environment table in production? Include strict validation so unexpected keys cause immediate startup errors.
| Checked | Without skill | With skill |
|---|---|---|
| API key secrets in production are loaded directly into memory from a cloud secret manager without writing them to process environment variables. | Missed | Passed |
| Unrecognized environment variables trigger validation failure by setting extra fields to forbid in the settings configuration. | Passed | Passed |
| API keys are typed as SecretStr attributes rather than plain strings. | Passed | Passed |
The instructions your model reads when the skill loads.
A team ships a LangChain 1.0 service to staging with python-dotenv loading
.env.staging into os.environ. Security audits —
docker exec STAGING-POD env prints ANTHROPIC_API_KEY=sk-ant-api03-... in
plain text. Anyone with kubectl exec, any sidecar, any core dump, any
error tracker that auto-captures process env sees the key. This is pain
P37: secrets loaded from .env in production containers leak via env.
A second failure chains. A developer runs the staging deploy from a shell
where LANGCHAIN_ENV=production was set hours earlier. The loader picks
the prod .env, staging answers with a prompt commit tuned only for the
prod model tier, latency doubles. Two root causes: no type-safe env gate,
no startup validation that would have caught the mismatched model id.
Both are one refactor:
# BAD — dotenv populates os.environ; any process with container access sees it
from dotenv import load_dotenv
load_dotenv(".env.production")
api_key = os.environ["ANTHROPIC_API_KEY"] # P37: leaks via `docker exec env`
# GOOD — SecretStr in a validated Settings object, pulled from Secret Manager
from pydantic import SecretStr
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
env: Literal["dev", "staging", "prod"]
anthropic_api_key: SecretStr
settings = build_settings() # pulls from GCP Secret Manager in prod
api_key = settings.anthropic_api_key.get_secret_value()
# repr(settings) prints `SecretStr('**********')` — safe to log
This skill owns the per-env config plumbing — Settings skeleton,
Secret Manager integration, per-env pinning, startup smoke test. It does
test cases passed, vs 11 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.