theozero

6 ms·

31.
by theozero 8mo ago
You might like https://varlock.dev - it lets you use a .env.schema file with jsdoc style comments and new function call syntax to give you validation, declarative loading, and additional guardrails. This means a unified way of m
32.
by theozero 8mo ago
Thanks for the kind words. It's actually decoupled and up to the user if they want to use it for pure validation as part of CI/deployment, just to inject values, or to integrate more deeply. But you can get the most benefit by int
33.
by theozero 8mo ago
You might like varlock ( https://varlock.dev ) You can use it to declaratively fetch from various backends, but it’s optional. At its core it lets you create a .env.schema and you get validation, type safety, guardrails for sensit
34.
by theozero 9mo ago
yeah for our DNS we use a little provider called... Cloudflare. But hey some tokenized crypto dns provider is probably much more reliable! lol
35.
by theozero 9mo ago
Better than masking them in a file, get them out of the file entirely! Pull them declaratively instead - https://varlock.dev This tool also redacts from your logs if working in js.
36.
by theozero 9mo ago
A proxy is a good solution although a bit more involved. A great first step is just getting any secrets - both the ones the AI actually needs access to and your application secrets - out of plaintext .env files. A great way to do that is ei
37.
by theozero 9mo ago
The fundamental idea of CUE (quoting them) "enable[s] data, schema, and policy constraints to coexist seamlessly" is really amazing for some use cases. But from a practical / DX perspective, the language seems pretty awkward
38.
by theozero 10mo ago
One really nice thing in varlock for monorepos is the import syntax. This lets you have shared config at the root, or just to break things up however you need. No need for diffing or copy pasting, as the schema validates everything - if som
39.
by theozero 10mo ago
I like all the extra scanning features this provides :) I've seen a few tools like this that try to keep things in sync. While it is better than the alternative of doing it manually, it is still a losing battle and not the greatest DX.
40.
by theozero 1y ago
Getting secrets out of plaintext env files is a fantastic idea, and I hope more people realize how important it is. Check out https://varlock.dev to add validation, type-safety, and additional security guardrails.
41.
by theozero 1y ago
In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of you
42.
by theozero 1y ago
For a more modern approach to .env files that includes built-in validation and type-safety, check out https://varlock.dev Instead of a .env.example (which quickly gets out of date), it uses a .env.schema - which contains extra m
43.
by theozero 1y ago
Next.js env var tooling could definitely use some improvement, and pulling from a secure external vault makes sense, but I think there's more to it. Have you seen http://varlock.dev/integrations/nextjs
44.
by theozero 1y ago
This is interesting. Amazing how something so fundamental is still such a pain, and we all build our own half-baked solutions for it on every new project. We've been thinking about this problem for a while now as well, and just launche
45.
by theozero 1y ago
Personally I don't want to write custom code from scratch or glue together 5 tools to do this on every project. I've done it - many many many times... If your project is very simple with a few env vars, it may not be a big deal, b
46.
by theozero 1y ago
On most projects you end up wiring up a bunch of custom logic to handle your config, which is often injected as environment variables - think loading from a secure source, validation logic, type safety, pre-commit git scanning, etc. It&#x27
47.
by theozero 1y ago
Exactly. We will do that to stdout - and can patch JS itself too. The goal here is to just make it dead simple to do the right thing with minimal effort. Get secrets out of plaintext, avoid the need to send them around insecurely, and help
48.
by theozero 1y ago
This is exactly the kind of thing we are trying to replace. No more hacky custom solutions needed. With varlock you get type safety, validation, and the ability to compose together your config however you need to, without having to reinvent
49.
by theozero 1y ago
We're still working on the copy. Any specific feedback is appreciated. Note that you can load env vars into anything via varlock run, not just javascript. The JS integration is a bit deeper, providing automatic type generation, log red
50.
by theozero 1y ago
Whether you like them or not, using env vars is ubiquitous because it's easy. Anything else ends up tightly coupled within your application code or only within the environment. Often you have a set of config needed both for your applic
51.
by theozero 1y ago
Even if you don't set any values in your env files (although why not set some non-sensitive defaults) you can still benefit from the schema and validation that varlock provides. Imagine every public docker container had an .env.schema
52.
by theozero 1y ago
We say "made for sharing" because .env.schema replaces .env.example which always drifts from reality - and often requires insecurely sharing secrets manually. Even if not setting values within your files, you can rely entirely on
53.
by theozero 1y ago
Right now, you can use any provider that has a CLI to fetch a single secret. In the near future, we'll be adding native plugins to make these integrations even easier. Vault can be a huge lift and doesn't make sense for many proje
54.
by theozero 1y ago
Tons of folks have plaintext secrets in their env files which are leaked via AI assistants every day. By getting those out of plaintext, the risk is totally removed. The schema itself (and the automatic types it can generate) also gives AI
55.
by theozero 1y ago
Hey all! Co-creator of varlock here. Varlock is the next evolution of what we learned building https://dmno.dev . We wanted to make things simpler (no more proprietary TypeScript schemas) and meet folks where they already are: .e
56.
by theozero 2y ago
You might like https://dmno.dev (full disclosure, I am one of the creators) It lets you manage all your config and pull from various backends (like 1Password or an encrypted file within your repo). I have not built a GCP Secret
57.
by theozero 2y ago
Not every service supports this, and there is still always a ton of config to manage, even if it’s not all sensitive.
58.
by theozero 2y ago
I think you might like https://dmno.dev It has this kind of functionality (via plugins) but also does a lot more. Validation, coercion, type-safety, composability, sharing config across monorepos, leak detection… We don’t have a
59.
by theozero 2y ago
First off, congrats on getting this published! It's a big jump from "this kind of works for just me" to "tested, documented, flexible, and ready for others to use", so good on you for seeing it through! Seems like i
60.
by theozero 2y ago
Neat. You might be interested in https://dmno.dev It let's you define a full schema for your config - including both sensitive and non-sensitive items - and then use plugins to pull sensitive values from a variety of backen

More ›