EnvSentinel – contract-driven .env validation, zero dependencies
Solves a real CI/CD pain, but dotenv validation already exists (python-dotenv, pydantic).
Deterministic, CI-safe API key resolution with optional runtime validation (stdlib-only)
Deterministic fallback order (ENV → .env → vault) plus an opt-in validation mode and a strict CI-friendly option is a practical combo I wish I'd had in several projects. The doctor CLI that lists found keys and minimal provider probes (e.g., GET /v1/models for OpenAI) is a nice touch — useful for catching bad tokens before a pipeline runs. It’s not reinventing secret managers, but the zero-deps, stdlib-only approach and CI strictness make it an immediately usable tool for small teams.
Backend developers, AI/ML engineers, DevOps/CI engineers who manage API keys in development and CI environments
Resolves from ENV → .env → vault, with optional runtime validation probes. No deps beyond Python stdlib.
Example:
from api_pilot import resolve_key client = OpenAI(api_key=resolve_key("openai", validate=True))
CLI doctor command:
$ api-pilot-doctor .env file found OPENAI_API_KEY found in environment
Modes: • Default: ENV → .env → vault • Validation: optional runtime API probes • Strict: fails if .env used (CI safety)
MCP integration ready.
Feedback welcome!
Solves a real CI/CD pain, but dotenv validation already exists (python-dotenv, pydantic).
Touch ID for ENV secrets is clever, but dotenvx and 1Password CLI already solve this.
IFC + capabilities block prompt injection at execution sinks, not input filters—40yr research applied.
Msgspec config wrapper with pydantic-settings ergonomics—but Pydantic, Dynaconf, and Hydra exist.
Useful utility for key verification, but browser extensions already do this.
Scans code for variable usage to autocomplete .env keys automatically.