HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
segmentio
chamber
Go2017–2024
segmentio / chamber

chamber

CLI for managing secrets

13Distinct people
13Mentions
1Explicit recommenders
2.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

CLI for managing secrets

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

If you're on AWS, I highly recommend taking a look at Chamber + Parameter Store for secret management. If you're not on AWS, EnvKey looks like a reasonable solution with ease…

jeffnappi used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2017-09-25 23:20:54 UTC to 2024-07-12 03:29:09 UTC.

012342017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC413
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

13 sources
This seems like quite a lot of setup and hassle for what could be handled some other way with less fuss, like chamber[0] or Doppler[1]. Heck, even the classic .env seems like a better choice in every way. What are the advantages to a configuration like this? Seems the HTTP interface with non-encrypted cache and separate agent situation isn’t something secure enough to satisfy most companies these days. [0] https://github.com/segmentio/chamber [1] https://www.doppler.com/
In AWS Secrets Manager Agent
You all do know that AWS SSM Parameter Store exists, right? It’s literally a KV store explicitly for this purpose. Parameters are scoped by path, versioned, are have optional encryption at rest. Like you’re using the AWS cli! It’s one call to https://docs.aws.amazon.com/cli/latest/reference/ssm/get-par... away. It even has built in Ansible support https://docs.ansible.com/ansible/latest/collections/amazon/a... and can values can be rendered in Cloudformation templates natively. Too hard? Maybe try Chamber https://github.com/segmentio/chamber It has support for multiple backends and can render secrets in lots of different formats.
In Using Route53 as a Key Value Store in GitHub Actions
I agree that AWS Parameter store isn't great... that's why we use Chamber: https://github.com/segmentio/chamber Chamber is an open source wrapper for AWS Parameter Store. You add a secret by doing: `chamber write ENV_NAME SECRET_NAME SECRET_VALUE` And when you want to execute a command with those values in your environment... `chamber exec ENV_NAME -- yarn start:prod` Parameter Store comes with auditing tools and versioning. Chamber uses KMS for encryption. Also, you can control permissions (including namespacing) with IAM. My question is - what does Doppler provide that would make me want to switch? I'm weary about letting someone else own our secrets.
In Launch HN: Doppler (YC W19) – Easily manage your env vars and secrets
Not OP, but I've recently worked with AWS Parameter Store a lot, and I've been very happy with it so far. We store all configuration (including secrets) using it. We started by using https://github.com/segmentio/chamber/, but because of the way we decided to structure our secrets we decided to write a clone of it ourselves (https://github.com/micvbang/confman-go). In practice, we have a client written in Python that grabs configuration from Parameter Store and puts it into the process' ENV variables at startup. This allows us to avoid vendor lockin in the rest of our code, since we still just fetch all config from the environment. I like it so far :)
In Don't use ENV variables for secret data (2017)
Similar to laurentl we use AWS SSM parameter store in combination with Chamber[1] to injects our secrets as environment variables to our application code. For services running on ECS, each task definition has an IAM Role attached that has permissions to use secrets stored in parameter store with a prefix unique for that service (each service encrypts its secrets with its own KMS key). For example, serviceA will use the prefix serviceA and have a secret under serviceA/DB_PASSWORD and serviceB will have its own secret under serviceB/DB_PASSWORD. Each service cannot access each others secrets and even if they could, they also need access to use the corresponding KMS key before they're able to read the secrets. Since secrets are added as environment variables we can inject them during startup with chamber. The entry point for your docker cont
Read the rest
ainer might look as following `CMD ["chamber", "exec", "serviceA", "--", "./executable"]`. Chamber will inject the secrets store in SSM before starting the executable which reads the secrets from the env variables. For other services such as Lambda we do not use environment variables, instead we use the AWS SDK to fetch secrets during cold starts and cache them for the duration of the Lambda container. If you're using Node.js lambda functions this is a little bit trickier to do than Go or python lambdas but it's still possible. The Lambda function also has an IAM access to only fetch the secrets under its own prefix. For adding, removing or editing secrets we can use the chamber CLI with each individual devs AWS access keys. For example: `chamber write serviceA PASSWORD hunter2` to write a new secret or `chamber list serviceA` to list set secrets. [1] https://github.com/segmentio/chamber
In Ask HN: How is your company storing secrets in EC2?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.