Secrets Manager

Overview

The Secrets Manager is a central registry for API keys, tokens, and other sensitive values. It can run as a standalone application (owning the encrypted or plaintext database) and is also exposed inside DevCentr as an integrated module that shows a repo- and environment-filtered view with a canvas-like interface and drag-and-drop to register or import secrets.

It is aware of .env usage patterns and helps users recognize the opportunity to maintain a central registry that can be copied into .env files or injected into the development process. It supports multiple environments (dev, prod, test), provider and tool profiles for consistent naming, and optional integration with Docker and Docker Secrets.

Core Features

Central registry

  • Store secrets in a single database (encrypted with user password or plaintext mode).

  • Attach secrets to projects and environments (dev, prod, test variants).

  • Search and browse globally (standalone) or filtered by current repo (DevCentr).

.env awareness

  • Recognize common .env file names and syntax (KEY=value, comments, .env.local, .env.<environment>).

  • Copy selected secrets from the registry into a project’s .env (or .env.<env>), with merge or replace behavior.

  • Suggest variable names from provider and tool profiles when writing to .env.

Provider and tool profiles

  • Provider profiles: Named templates for services (e.g. Stripe, AWS) with typical variable names and optional format hints. Used for recognition on import and for generating consistent .env output.

  • Tool profiles: Named templates for frameworks/tools (e.g. Next.js, Vite) with expected file names and variable naming (e.g. VITE_*, NEXT_PUBLIC_*). Used when copying to a project so output matches the stack.

Environments

  • Manage dev, prod, staging, and test variants. Secrets can be scoped per environment when attached to a project.

  • When copying to .env, choose target file based on environment (e.g. .env.development, .env.production).

Standalone vs integrated

  • Standalone: Launchable in its own window; owns the database; can run independently of DevCentr. User can browse global store and install secrets to a repo/environment.

  • Integrated: Inside DevCentr, a module shows secrets for the current repo and environment, with a canvas-like UI and drag-and-drop to register a secret to the project or import into the global registry. DevCentr communicates with the standalone (shared DB path or API/socket).

Injection workflow

  • Optionally, secrets can be injected into the development process (e.g. via a wrapper script or daemon that requests secrets from the manager and sets environment variables before running the app). Hook points: wrapper script, IDE run config, or local server. See Injecting Secrets into the Dev Process.

Docker

  • Interface with Docker: provide secrets for build args or run-time env (e.g. script that gets vars from manager and runs docker run -e …​ or uses manager-generated env file).

  • Interface with Docker Secrets: export from manager for docker secret create or for Compose secrets:; manager as source of truth.

Back-end providers (master front-end)

  • Optionally interface with industrial secret stores (e.g. Bitwarden Secrets Manager, 1Password, HashiCorp Vault). In this mode the Secrets Manager acts as a master front-end: it does not store those secrets; it authenticates to the provider, sends requests (list/get), and displays results in the same UI. Copy-to-.env and inject then request values from the provider at action time. See Back-end Providers.

  • The GUI must explain that we are a proxy (client of the provider); see Explaining the Proxy in the GUI.

Usage Scenarios

  1. Centralize keys: Developer has several repos with duplicated .env keys. They import existing keys into the global registry, attach them to each repo and environment, and use "Copy to .env" when needed so each project gets the right file without hand-editing.

  2. New project: Developer starts a new repo. In DevCentr they open the Secrets module, switch to "dev", drag a few secrets from the global store onto the project, then click "Copy to .env" to generate .env.development. Provider profiles ensure variable names match the stack.

  3. Standalone only: User runs only the Secrets Manager app. They browse the global store, select a repo (by path), choose environment, and "Install to repo" to write selected secrets to that repo’s .env. No DevCentr required.

  4. Docker: User runs a script that asks the manager for secrets for repo X and env Y, then runs docker compose --env-file .env.docker up. The manager wrote .env.docker or the script passes vars via -e.

Implementation Notes

  • Database ownership: The standalone application owns the secrets database. DevCentr does not create or migrate the DB; it connects as a client (read/write via API or shared path with single-writer discipline).

  • IPC: Prefer an API or socket from the standalone so DevCentr can request "list for repo/env", "copy to .env", "register secret to project". Fallback: shared database path if both use the same schema and locking.

  • Separate repository: The standalone may live in a separate repository (e.g. dev-centr/secrets-manager) with its own release cycle. DevCentr depends on a documented contract (data directory or API).

  • Encryption: User can choose encrypted (password-protected) or plaintext mode. Encrypted mode uses a key derived from the user password; no password stored on disk.

Documentation

Full documentation for the Secrets Manager lives in the Secrets Manager module:

  • Architecture, .env patterns, provider/tool profiles, environments

  • How-to: copy to .env, injection, Docker integration

  • Explanation: standalone vs integrated, encryption modes, back-end providers (Bitwarden etc.), explaining the proxy in the GUI