Kimen vs 1Password and cloud secret managers

The command syntax is not the important difference.

Kimen can start a child process with selected environment variables. So can 1Password CLI. A cloud secret manager can return the same value through an API or CLI.

The useful question is who should own the value and authorize access:

individual developer and local machine
  Kimen may fit

team account and shared company vault
  1Password may fit

deployed cloud workload with IAM identity
  cloud secret manager may fit

Choose Kimen for a small local, open system.

Kimen stores an encrypted vault on the machine and keeps project requirements in committed .kmap profiles. It needs no account, hosted control plane or network connection. The source is open and the tool remains useful offline.

This is a good fit when:

one developer owns the local values;
the project should declare its runtime names and projection modes;
the same value may need to become an environment variable, private file, path or stdin;
you prefer a small local CLI over another service account.

The tradeoff is equally direct. Kimen does not currently synchronize secrets between developers, centrally revoke team access or provide an organization audit trail. Each local vault must be backed up and maintained by its owner.

Choose 1Password when the team already owns the vault together.

1Password CLI supports secret references, op run for subprocess environments and op inject for configuration files. Accounts, shared vaults and service accounts provide the team layer which local Kimen deliberately lacks.

If a company already uses 1Password and the main problem is distributing, rotating and revoking shared credentials, using 1Password CLI directly is usually simpler than copying the values into Kimen.

Kimen remains distinct when an individual wants no account, offline use and a project-specific projection contract. Kimen can also resolve an exec: source through op read, but that combination only earns its complexity when the Kimen profile or projection modes add real value.

Choose a cloud secret manager for cloud workloads.

Google Secret Manager, AWS Secrets Manager and similar services connect secret access to cloud IAM, workload identities, versions and centralized audit. That is often the right production model.

For example, Google documents access through Application Default Credentials, Google Cloud CLI credentials or a workload identity with the Secret Manager Secret Accessor role. The application asks the service for a specific secret version.

If a deployed workload already has a narrow identity, adding a local Kimen vault to that path can make the system worse. Use the native identity and secret manager.

Local development is less automatic. The developer still needs Google Cloud authentication and IAM access to the secret. Kimen is an alternative when local ownership, offline access or cloud independence matters more than central administration.

A plain local file can still be enough.

A correctly ignored private file is simple and may be reasonable for disposable local credentials in a small project. It has no extra tool, account or unlock step.

Choose Kimen when encrypted storage, explicit profiles, several environments, short unlock sessions or multiple delivery modes justify the additional command. Do not add a secret manager merely to make a low-risk local value look sophisticated.

How the daily experience differs

Kimen

kimen session start --ttl 30m
kimen run --profile dev -- ./app
kimen session lock

Without an active session, Kimen asks for the vault passphrase on every invocation.

1Password CLI

op run --env-file=.env.references -- ./app

Authentication and authorization come from the developer's 1Password account or a service account.

Google Secret Manager

gcloud secrets versions access 7 --secret=app-api-key

Authentication and authorization come from Google Cloud credentials and IAM. Production applications commonly call the API through their workload identity rather than placing this command in a startup script.

A short decision rule

Use Kimen for local, open, account-free runtime configuration.
Use 1Password for team-owned credentials when 1Password is already the shared system of record.
Use a cloud secret manager for deployed workloads with native IAM identities.
Use a simple private file when its risk and maintenance cost are genuinely acceptable.

These choices can coexist. The local development source does not have to be the production source, as long as the application receives the same runtime interface.

Should you use Kimen, 1Password or a cloud secret manager?