crops
ejson
crops | ejson | |
---|---|---|
4 | 8 | |
24 | 1,312 | |
- | 0.7% | |
8.7 | 4.3 | |
5 months ago | 1 day ago | |
Crystal | Go | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crops
-
Very detailed article by Ariel Juodziukynas on Environment Variable handling in Ruby
I prefer env vars too. After looking for a way to handle encrypted files with dotenv, I ended up adding EJSON support to ops, so I could just put my env vars in secrets.ejson and check it in if I wanted.
- Ported a CLI program from Ruby to Crystal; very happy with the result
- Ops: Low-cognitive-load automation for projects in any language
- Ported a CLI program from Ruby to Crystal; very happy with the result!
ejson
- EJSON is a small library to manage encrypted secrets using asymmetric encryption
-
The Twelve-Factor App
> If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway.
You can load the secret file directly into the app, no need to load it as env vars or keep it strictly as key-value pairs.
> If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.
You can use tools like ejson[1] or sops[2] to get encrypted files checked into Git that have key level granularity on diffs.
There is definitely a place for higher level abstractions than Kubernetes. Mostly it gives operators a standard platform to build from when teams outgrow the PaaS sandbox.
[1] https://github.com/Shopify/ejson
-
Very detailed article by Ariel Juodziukynas on Environment Variable handling in Ruby
I prefer env vars too. After looking for a way to handle encrypted files with dotenv, I ended up adding EJSON support to ops, so I could just put my env vars in secrets.ejson and check it in if I wanted.
-
What is the proper way to use a secret manager with Next.js to fetch back secrets?
Where to store secrets (AWS Secret Manager, EJSON, Vercel's control panel, etc.) is more of a consideration of infra, and there aren't standard Next practices of where to store secrets.
-
Side project: Privie, an attempt to replace/improve `ejson`
After a few weeks using ejson (a utility for managing a collection of secrets in source control), using it still felt kind of awkward, so as side-project, I started working on privie.
-
Sharing certs & env variables across the team without Vault, etc?
Another (less good) option is using something like shopify/ejson and commit that config file to your repo and then hand out the private key to devs and have them stored elsewhere.
-
Ask HN: How to handle secrets (one-person SaaS)
Thanks!
About https://www.envkey.com/ : this requires a third-party server available 24/7, right? I mean, if that service is down... then I cannot deploy my code?
About https://github.com/Shopify/ejson: what's the advantage over simple PGP? Having yet another dependency is not very appealing. I'll take a look nevertheless.
What are some alternatives?
ops - The operations team for your project.
Secrets - Opinionated .NET library for resolving secrets in application configuration
privie
sops - Simple and flexible tool for managing secrets