frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Open in hackernews

Magic .env files built for sharing: Human-first, AI-friendly

https://varlock.dev/
43•mooreds•6h ago

Comments

jelder•5h ago
I don't get `.env` files. Just never made sense that we'd delegate managing environment variables to the processes which consumes them.

https://direnv.net is a better solution IMO. Once you set it up in your shell, it loads environment variables from the `.envrc` file in whatever the current directory is automatically. It includes a rich standard library (https://direnv.net/man/direnv-stdlib.1.html) for manipulation of PATH, etc.

For secrets, I just add this line to `.envrc`:

    source_env_if_exists .envrc.private
And add `.envrc.private` to `.gitignore`. Now that just works anywhere, whether the authors of whatever tool I'm using official support `.env` files or not.
awestroke•4h ago
This is about formalizing required secrets for dev. Many repos have a ".env.sample", which is better than nothing - you copy it to .env and fill in the blanks. If this is done automatically, even better. If the automatic .env setup also loads secrets from your password manager (with prompting), even better.
judofyr•4h ago
With direnv you can also run commands directly in the .envrc:

    export OPENAPI_API_KEY=$(op read "op://api-prod/openai/api-key")
Every time you cd into the directory it will execute the command. Isn’t this even better than copying the secret into a local file?
conception•4h ago
1password actually has environments now so you can just load it directly.
candiddevmike•4h ago
It's such a shame this isn't built into shells. There isn't really a security issue here as you have to trust the directory first before it fires.
__jonas•4h ago
I agree that loading environment variables should not be the responsibility of the process which consumes them, not sure what the benefit of renaming .env to .envrc is.

I use mise to load environment variables from .env, since I also use it to manage tool versions. When I don't have that available I just do

  set -a; source .env; set +a
direnv is definitely another good option.
jelder•3h ago
direnv also has `dotenv` and `dotenv_if_exists` macros, which nicely gets around the fact that `.env` files typically omit the `export` statement.
throw-the-towel•4h ago
And I don't get storing your configuration in env variables, period. They're not discoverable at all, there's no namespacing nor any other isolation, there's no structure to them, and if you want a list you'll have to come up with an ad-hoc encoding. Environment variables are a mess, you'd be better off with a config file.
w0m•4h ago
I assume environment variables became popular as it's an 'easy' way to inject secrets without hardcoding them in a config file.
theozero•1h 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 application and your surrounding dev tools / scripts. This tries a provide a universal solution.

At the end of the day you could imagine varlock loading your config, and injecting it using a method that is not env vars - a file, sidecar process, etc.

0xbadcafebee•3h ago
Most tech people don't grok the abstraction between an executable program and the environment it is executed in.

The thing that runs your code is responsible for adding the environment variables from wherever they are kept for that environment. The execution environments running your code are not checking out your Git repository and reading files from it before they execute your program; that would introduce a chicken-and-egg problem (and make it much harder to run your program in new environments).

Below is an example of why you can't just load all your variables in a single ".env" file.

Environments:

    - *development*:
        host: "my laptop"
        variables: [FOO=dev]
  
    - *staging*:
        host: "a ci/cd server"
        variables: [FOO=stage]

    - *production*:
        host: "a kubernetes server"
        variables: [FOO=prod]

I want to run my program in development!

    ->> open a terminal on my MacOS laptop
             ->> change to directory with my code
  
             ->> load environment variables into shell
                 $ source .env
  
             ->> run my program
                 $ ./MyProgram.EXE
             ->> the shell takes the variables it has, and adds them to the program at runtime
                 char *const argv[] = {"/Users/me/app_src/MyProgram.EXE", NULL};
                 char *const envp[] = {"FOO=dev", NULL};
                 execve("/Users/me/app_src/MyProgram.EXE", argv, envp);
  
                 ->> the program is loaded, executed, and accesses environment variables passed to it
I want to run my program in staging!

    ->> start a job on a ci/cd server
         ->> the ci/cd server starts a Docker container
           ->> the ci/cd server begins running commands in the Docker container
               ->> checkout latest code and change to new directory
  
               ->> load environment variables into shell
                   ->> retrieves environment variables set in ci/cd job configuration
                   ->> sets those variables in the shell
  
               ->> run my program
                   $ ./MyProgram.EXE
               ->> the shell takes the variables it has, and adds them to the program at runtime
                   char *const argv[] = {"/Users/me/app_src/MyProgram.EXE", NULL};
                   char *const envp[] = {"FOO=stage", NULL};
                   execve("/Users/me/app_src/MyProgram.EXE", argv, envp);
  
                   ->> the program is loaded, executed, and accesses environment variables passed to it

I want to run my program in production!

    ->> start a job on a kubernetes server
         ->> a deployment scheduler schedules a pod to start\
  
             ->> it looks up a configmap with environment variables
             ->> it looks up a secrets object with secrets
             ->> it sets environment variables in the pod based on the configmaps and secrets
  
             ->> it starts a container in the pod
               ->> it begins running commands in the container
                   ->> run my program
                       $ ./MyProgram.EXE
                   ->> the container takes the variables it has, and adds them to the program at runtime
                       char *const argv[] = {"/Users/me/app_src/MyProgram.EXE", NULL};
                       char *const envp[] = {"FOO=prod", NULL};
                       execve("/Users/me/app_src/MyProgram.EXE", argv, envp);
  
                       ->> the program is loaded, executed, and accesses environment variables passed to it

You have to add the environment variables to the execution environment before your program ever gets run. Otherwise (for example) you could never pull a Git repository to load variables, because where would the credentials to pull your Git repository come from? They have to be added beforehand. So that beforehand step is where you add all your environment variables for that environment. Your program merely reads them when it is executed; no need for your program to read additional files.

You should not do something like keep a ".env.dev", ".env.stage", ".env.prod", packaged up in a container. Each execution environment may need slightly different settings at run time. And secrets should not be kept in your Git repo, they should be loaded as-needed, at runtime, by your execution environment.

All this is covered neatly in The Twelve Factor App (https://12factor.net/config). As someone who's been doing this for two decades, I highly recommend everyone follow their guide to the letter.

theozero•1h 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 which was validated on startup, instead of scattered info about the available env vars in their readme.

Nullabillity•5h ago
"Made for sharing", but suggests depending on 1Password?

It also seems.. irresponsible to claim that @sensitive values "will be always be redacted in CLI output", when the whole point of something like Varlock is to configure some external application that it doesn't control.

And what does "AI-friendly" mean here anyway... beyond, I suppose, varlock being AI slop itself.[0]

[0]: https://github.com/dmno-dev/varlock/tree/514917f4228d49d4404...

halfcat•4h ago
I don’t know about varlock, but 1Password’s `op` CLI tool seems to hook the STDOUT pipe and find/replace any instances of the secrets with “concealed by 1Password”. It works even if I drop into a REPL and try every way I can think of to print it out to the console.

So it would seem, on that front, that 1Password is doing the heavy lifting.

Using 1Password in this way has proven way better than storing .env files in plain text on dev machines, where the .env files get picked up if a company does backups, or someone stores a repo in their Dropbox folder, file gets flagged as potential malware and uploaded somewhere for further analysis, etc.

theozero•1h 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 env vars in the platform where the code runs and still benefit from validation provided by varlock.

Right now we give 1Password as an example, but you can use any provider that has a CLI. We are also working on a plugin system that should make it easier to integrate with any provider.

As for redaction - that note is about how we redact your secrets from _our_ CLI output. However we also provide tools to redact within your application. Right now this works only in JavaScript, by patching global console methods. We will also hook into stdout for varlock run, similar to what the 1Password cli does.

The leak detection is much more interesting - especially in hybrid client/server frameworks, where you can easily shoot yourself in the foot.

By removing plaintext secrets from env files, we totally remove the risk of them leaking via AI code assistants, which I guarantee is happening millions of times a day right now. Also the schema itself and autogenerated types give AI much more context about your env.

slacktivism123•4h ago
Use case for non-deterministic processing of .env files?
debarshri•4h ago
You have to see the `.env` file from the context of where it gets deployed.

For example, when we [1] deploy applications in Kubernetes, we have built an admission controller that fetches secrets from vault and converts them into env variables or secrets for the application at runtime. In this way, you will only have a reference in the form of annotation for the application.

If you give an `.env` as is, people will extract that value and start using it. You will end up leaking secrets.

Another way we have been exploring injecting secrets is via a sidecar for the application or via SDK but the lift seems to be a bit too much.

I think the deployment environment should be responsible for injecting the credentials for the best posture.

[1] https://adaptive.live

mathfailure•4h ago
Why not integrate with KeePass(*)-family of secret stores or HashiCorp Vault?
theozero•1h 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 projects - we wanted to build a tool that makes sense from day one, even when there is no backing provider, but can grow with your team and change providers seamlessly.

oulipo•4h ago
After having so many issues with .env files I just now do a simple .env at the root of the repo with just `ENV=prod/staging/dev` and then everything is generated (using 1password, etc) from a `config.ts` file in my `pkgs/config` from the monorepo

the file is basically a big

``` const config = { http: { server_url: ENV === "prod" ? "https://myserver.com" : "http://localhost:3000" ... } } ```

and this lets me type variables, add comments, many niceties, etc

tylergetsay•2h ago
its an old library but convict is great for this in the nodejs ecoystem
ks2048•4h ago
What makes it "AI-friendly"?
xena•4h ago
Buzzwords!
theozero•1h 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 more context about what configuration is available, and what each item is for.

vergessenmir•4h ago
I don't get it, what does this do?
0xbadcafebee•4h ago
I couldn't tell what this was at all for most of the page, but finally at the bottom it shows it's just a library for loading variables into a Node.js application
theozero•1h 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 redaction, and leak prevention.

theozero•1h 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: .env files.

We think the decorator comments (it’s an open spec we call @env-spec - RFC is here https://github.com/dmno-dev/varlock/discussions/17) are an intuitive addition to .env files that are ubiquitous.

The hope is to remove the papercuts of dealing with env vars (and configuration more generally) by introducing an easy to understand system for validation, and type-safety, with the flexibility to use any third party provider to persist your secrets. We found ourselves reimplementing this stuff on every project, wiring together many tools and custom code, only to end up with a mediocre outcome.

The very common pattern of using `.env.example` leads to constant syncing problems, with many folks resorting to sharing .env files and individual secrets over slack, even when they know they shouldn’t. By turning that example into a schema and involving it in the loading process, it can never get out of sync. With validations built in, if something is wrong, you’ll know right away with a helpful error instead of an obscure runtime crash.

Because the system is aware whether things are sensitive or not it means we can do things like log redaction and leak prevention on the application side of things. Many tools try to do scanning but use regexes, while varlock knows the actual values to look for. We felt these were problems especially worth solving in a world where more frameworks are running the same code on both the server and client.

We intended to share this ourselves on here next week but you beat us to the punch. We’re in the midst of shipping the drop-in next.js integration (hopefully just merged today).

I also see a few comments about the “AI friendly” part. Right now tons of folks have sensitive keys in their .env files that are being leaked to AI assistants left and right. By removing plaintext secrets from env files, it entirely removes this problem. We also want to highlight the fact that with this DSL on top of .env we’re making it much easier for LLMs to write safer code. Part of creating devtools is trying to understand how they will be used in the wild so we’ve been trying to work with common tools (Cursor, Windsurf, Claude, Gemini, etc) to make sure they can coherently write @env-spec for varlock.

We’re literally just getting started so all of your feedback is super valuable.

We’ll continue to expand support for non-js languages (which already work via `varlock run`) as well as add more integrations, and eventually some CI/CD features for teams to help track and manage config.

Reading License Plates

https://blog.alexrinehart.net/posts/reading-license-plates/
1•speckx•1m ago•0 comments

Show HN: I built an AI transcription app because my gf needed one for uni

2•ebukao•4m ago•0 comments

The Dickson Report

https://oakandlimestone.substack.com/p/the-dickson-report
1•atx2bos•4m ago•0 comments

LLMs show cultural theory was right about the death of the author

https://www.programmablemutter.com/p/cultural-theory-was-right-about-the
1•dcre•5m ago•0 comments

I switched to a flip phone, and I'm never going back

https://www.sfgate.com/sf-culture/article/swapped-iphone-for-flip-phone-never-going-back-20762858.php
1•pilingual•6m ago•1 comments

I built a AI transcription app because my girlfriend needed one for uni

2•ebukao•8m ago•0 comments

Pentagon to Take Stake in Rare-Earth Company, Challenging China's Control

https://www.wsj.com/business/mp-materials-enters-multibillion-dollar-partnership-with-defense-dept-c8f9f806
1•sandwichsphinx•11m ago•0 comments

Optimization Culture Is Making Us Fragile

https://bradstulberg.substack.com/p/optimization-culture-is-making-us
2•mikestew•12m ago•0 comments

Show HN: asyncmcp – SNS/SQS based custom transport layer for MCP

https://github.com/bh-rat/asyncmcp
2•bharatgel•15m ago•0 comments

Chat with 19 Years of HN Data

https://camelai.com/hackernews/
2•oldfuture•16m ago•0 comments

Press Replay on Your Dreams with the Dream Recorder

https://design-milk.com/press-replay-on-your-dreams-with-the-dream-recorder/
1•Bluestein•17m ago•0 comments

Running a static website in AWS for $0.55

https://www.cottongeeks.com/articles/2025-07-10-running-a-static-website-in-aws-for-55-cents
1•deepakjois•18m ago•0 comments

Writing Bounds-Safe Code in C with Arrays

https://uecker.codeberg.page/2025-07-09.html
1•uecker•18m ago•0 comments

The Code Inflation

https://blog.hermesloom.org/p/the-code-inflation
1•sigalor•18m ago•0 comments

A New Era of Stack Overflow – Stack Overflow

https://stackoverflow.blog/2025/07/10/a-new-era-of-stack-overflow/
3•ulrischa•19m ago•0 comments

Kagi Discover: Find articles, research, videos, code, more that match interests

https://prism.kagi.com/
2•miles•22m ago•0 comments

Why Americans Can't Buy the World's Best Electric Car

https://www.nytimes.com/2025/07/08/opinion/byd-china-car-ev.html
5•bookofjoe•23m ago•1 comments

Infinitic Tac Toe - There’s always a winner

https://maxwellito.github.io/infinitictactoe/
1•susam•23m ago•0 comments

The Problem with Microsoft

https://www.trevornestor.com/post/the-problem-with-microsoft
2•SamuelAdams•23m ago•0 comments

Woman and three teenagers arrested over M&S, Co-op and Harrods cyber attacks

https://news.sky.com/story/woman-and-three-teenagers-arrested-over-mands-co-op-and-harrods-cyber-attacks-13385738
2•austinallegro•23m ago•0 comments

The Big Bang myth – Our origins will always elude us

https://unherd.com/2025/06/the-big-bang-myth/?us
1•voxleone•25m ago•0 comments

Specification Grounding: The Missing Link in Vibe Coding

https://unstract.com/blog/specification-grounding-vibe-coding/
3•constantinum•26m ago•0 comments

Astronomers Have Traced Our New Interstellar Comet's Origin, and It's a First

https://www.sciencealert.com/astronomers-have-traced-our-new-interstellar-comets-origin-and-its-a-first
1•speckx•26m ago•0 comments

Google revamps its AI tool that lets you learn endangered languages

https://www.neowin.net/news/google-revamps-its-ai-tool-that-lets-you-learn-endangered-languages/
6•Bluestein•27m ago•0 comments

Bitcoin Transcripts v2: FOSS Archive of Bitcoin Tech Talks

https://btctranscripts.com/
1•ahoyasoy•28m ago•0 comments

Jamsocket (W22) Is Joining Modal

https://jamsocket.com/blog/jamsocket-is-joining-modal
3•paulgb•31m ago•0 comments

Australia to Saudi Arabia, these cities are getting smarter by design

https://www.businessinsider.com/sc/how-smart-cities-are-transforming-urban-living
6•Bluestein•31m ago•0 comments

Vibe Coding Casino: Rise of programming by slot machine

https://evrim.zone/blog/opinion/vibes_casino
2•evrimoztamur•32m ago•1 comments

Show HN: Endorphin AI–Run browser E2E tests from plain English with QA AI agent

https://endorphinai.dev
3•papapin777•33m ago•0 comments

Low-cost carbon capture? Bury wood debris in managed forests

https://phys.org/news/2025-06-carbon-capture-wood-debris-forests.html
2•PaulHoule•35m ago•0 comments