AHENA

Solutions · Secrets & environment variables

Know what every environment needs, and that it's really there

An app's configuration ends up spread across local env files, CI, the hosting provider and half a dozen provider dashboards. Ahena keeps one encrypted record per environment, checks that what the app needs exists, and keeps values out of places they don't belong.

Get started freeSecrets

How configuration sprawls

The same handful of values gets copied into more and more places:

  • Local .env files, development and production variants, CI secrets, hosting-provider variables and provider dashboards all hold copies.
  • A variable is missing in one environment and nobody notices until a request fails.
  • A development or test credential ends up in production, or the same value is reused across environments.
  • Values are copied between dashboards by hand, and the copies go stale.
  • Coding agents need to work on the app, and the easiest way to let them is to give them the keys.

What Ahena does

  1. One encrypted record per environment

    ahena env set stores a value for one environment with its own AES-256-GCM key, bound to that organization, project and environment. Values come from stdin or a hidden prompt, never the command line.

  2. Names everywhere, values nowhere

    The dashboard, Doctor, plans, logs, audit events and MCP tools refer to secrets by name; ahena env secrets lists names, versions and a masked hint. Setting a value again creates a new version.

  3. Checks that what's needed exists

    Doctor checks that the secrets your app needs are stored (by name), and ahena deploy-check fails a deploy that's missing one.

  4. Environment separation

    Doctor flags a test-mode key in production, a live key outside production, and the same value in production and another environment (compared inside Ahena, reported by name only).

  5. Secrets out of the repository

    Doctor's repository checks flag an .env that isn't git-ignored, committed .env* files and credentials in tracked files, reporting locations only; values never leave your machine.

  6. Provider-created secrets

    Secrets a provider returns once, such as a webhook signing secret, are stored the same way when Ahena creates them.

  7. A typed env schema

    ahena generate writes .env.example blocks and an env module with missingEnv() and assertEnv(), so the app fails fast when a variable is missing.

What Ahena shows, and to whom

What it isWho sees it
ExistenceWhether a secret is stored in an environmentEveryone in the project, Doctor, CI and agents
MetadataName, version, masked hint, when it changedEveryone in the project (lists show names only)
ConfigurationWhich secrets an app needs, per environmentDeclared in git-safe config; checked by Doctor
ValueThe secret itselfOnly by ahena env reveal in a terminal: permission-checked, audited, never for agents or CI tokens

Managing an environment's secrets

$ ahena env secrets production  # names, versions, masked hints
$ ahena env set production API_KEY  # hidden prompt; a new version each time
$ ahena doctor -e production  # required secrets present, separation checks
$ ahena env reveal production STRIPE_WEBHOOK_SECRET  # terminal only, audited

A security boundary, stated plainly

  • Ahena's providers never receive the secret values Ahena holds, so Ahena can't write them into another service. GitHub Actions secret values and Vercel sensitive environment variables are set by you: Doctor checks they exist by name and gives the exact command. This is deliberate isolation, not a missing button.
  • Revealing a value is possible for people with the right role (developers outside production, owners and admins in production), in a terminal only, and every reveal is audited. Provider connection credentials can't be revealed at all.
  • Ahena isn't a general-purpose secrets manager or vault: it stores the credentials it needs to manage providers and the app secrets you keep with an environment.

Questions

How do I manage environment variables across multiple services?

Declare each environment's providers in ahena.config.ts, store secrets per environment with ahena env set, and let Doctor and ahena deploy-check confirm that every required variable exists in each environment, by name, before you deploy. Values stay encrypted in Ahena; you set them on your host from a terminal reveal.

Can Ahena push my secrets into GitHub Actions or Vercel?

Not today. Providers never receive values Ahena holds, so GitHub Actions secrets and Vercel sensitive variables are set by you. Ahena checks that they exist and prints the command to run.