Stop putting secrets in .env

Welcome to Syntax. If you have a dot EMV file sitting on your computer, this is the episode for you because we're gonna talk to you about why you shouldn't be doing that. My name is Wes Bos. And with us today, we've got Theo Ephraim and Phil Miller. They work on Varlock, which is a solution, a library that'll help you inject your secrets into your app and into your coding agents. But, we also just wanna, like, talk about just, like, why is everyone just putting, like, text files on their computer with all of their secrets when we have all of this, like, logging ESLint Notion for me JS, like, a ritual where I have to, like, use a thousand things, and there's there's beep, bop, boom, pin codes and everything. And then then we just put the, like, database string in a dot e m v file. So welcome, guys. Thanks a lot for coming on. Yeah. Thanks for having us. So much for having us. So let's start there.

Yep. What's wrong with dot e m v files? Yeah. I mean, why don't we first just talk about, like, you know, you have these files sitting there. Often, you're putting plain text secrets in there. And, you know, maybe you don't have any, like, super sensitive production secrets in there, but you still probably have Vercel. Or, you know, maybe you needed to run some script that connected to production, so you put it in there once and, you know, you forget that the file's even there. And, you know, especially now in the era of AI coding agents Wes they're just reading all your files, slurping it all up, sending it off to some Vercel, like, the only real safe way to ensure that they're gonna be not sent up to, you know, OpenAI is to get them out of plain text altogether. To go back a bit to to answer your question, I think the reason they're sitting in plain text is because every tutorial on the Internet, the first step is

put the secret in plain text Node dot e n e file and then then do the rest of the tutorial.

So everyone is still telling people to do that even though we know that it's wrong, and then we copy and paste those files on Slack. Right? I think that even the harder challenge is is for the most part that most people

don't even know of a different way to do it. Like, that's just the way. Right? Yeah. Or the way that the way the easier way or sorry. The right way is, like, such a pain. Right? Or has seat fees of, you know, $20 per developer per month. So it's like Mhmm. You're like, oh, I could do it that way, but it's just not worth the hassle. And people like to say that they do, you know, security best practice even if they don't always do them. Right? They're gonna they're they're gonna choose the path of least resistance,

especially if it's a last minute thing. Right? Yeah. I'll I'll give you an example.

So, me and Serge were working on the mad CSS website, and and he was Scott, like, scaffolding it out and and building, like, kind of the first run of it. I had some, like, GitHub secrets that, for, like, the login. Right? And, like, I threw them in one password as an environment, and then he went through it. And he he say he spent, like, half a day just trying to, like, get them injected with the, like, one password CLI thing, and then he ended up just being like, screw it. You Node? I can't get it to work with, like, these two specific things. Scott paste it. Which I think happens probably more often, where people are just like, ideally, Wes. I would have something, but it's it just doesn't work as well. It doesn't work with my setup and whatnot.

So, like, what is what what is the solution here?

Like, what what should we be doing? So, like, let's also let's go back a second and just talk about, like, dot m dot example. Because, like, regardless of how you're shoving stuff in there, like Yeah. The common way JS, like, okay. At least we have a dot m dot example. That's clearly better than having nothing. Right? It's clearly well, arguably better than having it, you know, buried in a readme in a custom table.

But, like, what are the what are the problems there? Right? So, like, you open it up. It's a mix of half of them half of the values are real values that should be used, right, like a port number or some feature flags or things like that.

And half of it is like a placeholder that's like your put your key here. You know? Talk to Bob to provision a key. Right? It's unclear which are real things to use. It's unclear which are placeholders.

Like, the the utility of having an example there depending on the item is arguable.

And then you copy paste this thing, and now you suddenly have this, like, problem of trying to keep these two things in sync. Right? You don't have a single source of truth.

So, like, half of the you know, there's documentation in that file. There's also documentation in your validation code if you have it at all. You maybe have type generation or maybe you're hand maintaining types. So, like, all this stuff gets spread out all over the place to the point where you just say, you know what? If I can avoid using this at all, I'm going to. So you don't put things that should be environment variables or just, like, sort of static config in there anymore. You just you just put them in const, Scott all throughout your code base. Dude.

I yeah. You're just like you're doing it. You're speaking exactly what I do. Yeah. Have you been looking at our Node, cool. This is hit me. Yeah.

So so the solution there, and this is kind of how Varlock came into being, is like, okay. Rather than having a tool that tries to keep your, you know, in example or your schema in sync with some other file that actually has values, what if we unify this? So you have one file that contains both schema information and can set values declaratively or just have static values.

And what if we make it sort of a unified toolkit to deal with sensitive things and nonsensitive things, and we understand exactly which ones are sensitive? So, that's kind of what Varlock is all about. So we it looks like a normal dot end file, but we use JS doc style decorator comments. So you can say in a comment right above the item at required, at sensitive, at type equals email, at type equals string starts with whatever, a BCUnderscore.

Right? So there's this very rich schema, that you can express through just these comments that feels still familiar because it's like a dot end file.

And then aside from the schema sort of stuff that you that you use through comments, we also have a function call syntax so that you can declaratively say, go fetch this from one password.

Like, similar to the OP inject or OP run or whatever, except for that it's totally general and you have a function. So there's a plug in for one password, OP whatever. There's a plug in for AWS, for GCP, for Azure, for whatever. And it's super easy to write new plug ins. So you have this sort of unified toolkit, like, fetch it from here, validate it, generate types, single source of truth, documentation,

everything all in one place. The nice thing there is that you don't have to put all your eggs in one basket. Right? So you can use one password for development or up to staging. You can use secrets manager in production. You can inject from Vercel in production, whatever you like. So you're not sort of, like, tied to one vendor for the actual persistence of those secrets.

Okay. So I'm I'm looking at it right now. It's a it's a dot e n v dot schema file that you I assume you commit to your repo. Right? Like, this is something that's that's allowed to go Yes. Node. Into your repo.

And then you declare the types, which is really nice because, like like, half the time, like, I try to get somebody else spun up on a project.

You're like, oh, yeah. Here's here's what I think you need in, like, the dot e m v file. And then they're, like they run it, and they get an error, process dot e m v dot whatever, not defined. Right? And your example is out of date, all that type of stuff. So that's really nice that you do that as well as as the actual types, which is Yeah. Also Node. Like, you can describe starts with Scott, like, s k dash, because, like, somebody might call it a token. Somebody else might call it an ID, and you're like, which one do I need? That's that's really cool. So and then so everybody who's working in your project then has the dot e m v dot schema file.

Then does everybody in your team need to use the same way to expose those? Like, if somebody if one of them uses one password,

do they need to use one password as well? It's it's up to you. Right? So there's there's you could have it so that this only has the schema and does validation, and then you're putting values in, you know, in a dot e n v dot local file that you're still, whatever, copy pasting, doing whatever you want. You could, in the schema, declaratively say, hey. Go fetch this from one password and wire up sort of, you know, each item to Okay. The right place. You can load a whole bunch of stuff from one password at once, like, an JS whether it's an environment or a single item that's, like, a dot end blob, you could load from, you know, a variety of other places. Or, like, in production, you know, often the first step of sort of implementing this is set this up. The validation will run, but you're still gonna inject real environment variables from, you know, the Vercel secrets UI, right, for prod. You're still getting that extra validation and, you know, especially when it fails, now instead of getting this weird runtime explosion Oh, yeah. It's like, this thing blew up. When it goes to try to build or boot or whatever, it's gonna say, hey. This environment variable is missing, and it's marked as required. Or this thing doesn't you know, it's it's typed in wrong. Yeah. I remember when I first saw this, I was worried about, like, production. But you're you're not

modifying the e n v file. You're just you're still copying and pasting the e n v vars in the Vercel or whoever's dashboard the same way, but you are still getting all the features. So that's

that's that's really You Node do either. You could do it. You could you could you Node, the first step would be, here's a schema, run validation, leave that stuff being injected how it was before. The second step is, you know, I wanna actually centralize all this, so I'm gonna move everything to 1Password.

And then on production, you would just set one single key, which would be like a service account token, which enables it to talk to 1Password.

And especially if you're in sort of a, like, multi cloud, you know, microservice situation and you got a million things going on, like, centralizing everything into a sane way of dealing with it JS gonna be, you know,

much, much easier. Yeah. That makes a lot of sense. I it it is funny because, like, when you first hear about, like, okay. We're adding we're adding a schema to your e n v vires, and, you know, type safe comments, all this stuff. It all feels like maybe that's too much for e n v vires, and then you you realize I hit every single one of these use cases in which this would have made my life better, every single one of them. And, like, the buy in is, like, so insignificant that, like, why why isn't everybody using this? This is like it feels like, this JS, like, kind of a missing piece of technology. Right?

One of the best feelings is when you implement this and then you go and delete all of that code that's just checking Node end. Oh, yeah. So you set a value in production or a value in staging, all of that goes away. Right? What Theo didn't mention it before is, like, you can have a hierarchical set of files based on the current environment too. So you could have a a dev schema, a staging schema, a production schema. They could either be expressed in separate files or ESLint some of our sort of primitives in one file. Yeah. And so, you know, you can

you know, there's also, like there's an import syntax. Right? So you can import from other places in a monorepo. That means, you know, you can have shared stuff at the root, and each service can then import just the things they need from you Node? It's it's very, very flexible.

Yeah. So what does that buy in look like for the import? Is it really just swapping out your process dot e n v imports or whatever with, varlock imports?

So well, so what I'm talking about is importing from within a dot end file, importing another dot end file. Right? So there's a new root decorator at import, you know, dot dot slash dot dot slash, and that will import the the root dot env. Right? Or you could import specific keys from it. In terms of implementing it in your code, we have sort of drop in integrations for a bunch of different frameworks, Vite, Next, you know, Astro, all that. And you you could continue to use process dot env because they are just injected as environment variables.

But we also have Scott of a nicer helper that gives you, coerced values and better type completion.

So, like, if you mark something as a Boolean, then when you actually go, you know, env dot whatever Boolean thing, it's gonna be true or false. It's not gonna be one or zero or true and, hey. Check if this thing is a string or you Node? All that extra coercion logic you end up shoving in five different places. All that just goes away.

Is is there ever a standard? Like, is anyone working on a standard for this type of thing? Because with with Cloudflare, you you import e n v, from Cloudflare workers, which I like better than just process dot e n v. But I don't like that because then do. Yeah. Then it makes my code, like, kinda pigeonholed into wait. Didn't Node doesn't node do that as well? You talked to you then. Experts.

I mean, you can use process dot env. There there's also import dot env for import dot meta dot env. Right? And, I I think why all of this really gets confusing for people is because in a front end context, there are no environment variables, yet we use environment variables to inject things, like, statically in a build time. So, like, what even is an environment variable and how are they used really varies depending on what kind of framework you're working with, what kind of project you're working with.

You know, we we really do try to simplify a lot of that. So we have this import n from Vercel slash n helper, and that does try to just make it work in all cases. So that works in the front end and the back end, and it does the replacements with Vite and all that stuff. Mhmm. One other cool thing, like, it does those replacements based on your schema. So you say, hey. This is sensitive or it's not. It's not based on some weird prefix.

Right? And, like, it's a it's a lot more explicit, in terms of what you what you want it to be doing.

Yeah. It's not just this this random thing that's available in the air. Like, where where does process come from? You know? Yeah. Yeah. And if you want to see all of the errors in your application,

you'll want to check out Sentry at century dot I o forward slash syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

What about other languages as well? Like, this is not just a JavaScript thing. Right? Yeah. I mean, why you know, one could argue, you know, why are you using even using a dot end file with these weird decorators to do this stuff. Right? Like but we started there because it's what people are used to. So we're trying to meet people where they are, and it feels very familiar, and it it feels applicable in any kind of language. Right? Like, we did have a first kind of version of this, called Domino where the schema was written in TypeScript. And it worked really well, and a lot of things were cool about that. But it you know, trying to convince some Rust developer to, like, use this TypeScript schema in their Node, like, it's just not gonna happen. Right? Whereas if you say, hey. Look. It's a dot end file with some extra little markup on it. It was like, oh, that actually makes sense.

So for for Varlock, we have a standalone binary build that you can use with any language. So you could still do varlock run. It will load, validate, do all of that, and then inject it into your code, which could be any language.

We do also, though, like, part of what we do is generate types. So there's a root decorator at generate types, and you can say language equals TypeScript, and it will generate TypeScript types. So we don't generate types for other languages yet, but that should also be possible. So you can imagine, like, you know, hey. Just generate my Go types for my config or generate, you know, Wes, like, what whatever. Right? It's by separating it, it becomes a lot more applicable for for anything. Yeah. The benefit of the JavaScript ecosystem today is the is the sort of deep integration. So we do, you know, console log redaction of those sensitive values.

We prevent you from leaking them in HTTP responses, that kind of thing. So, you know, we would need to do integrations in other languages to give you that level of integration, but that that's coming too.

One of the reasons why I think people like, the one pat like, one password directly hasn't caught on is that you have to change your your run commands to, like, run something first and then then injects it into the environment and then that then it runs. Like like, it would, like, inject it and then run npm run run dev, and then you'll have that. But then there's this weird issues where if it has, like, a subprocess, the variables don't get pushed to it sometimes.

Is yours like that as well? Like, do I have to run Vercel something and and npm run dev? Only if you're trying to, like if you're injecting it into, say, a non JavaScript language for the JavaScript languages, or, like, for different frameworks. Like, we have a Vite integration. We have a Next integration. So those kind of happen at the, like, you know, Vite config level, and it just works.

And same with Node, like, or BUN or whatever. Like, we have an auto import command that reaches out to the CLI and loads and injects it. So in all those cases, you're not you're not prefixing everything with varlock run. It would just be like and this is a a real other problem. Like, say you wanted to run some, like, database migration. Right? And you need to feed in that database URL into the migration, or into the migrate command. Right? You could do varlock run, whatever, Prisma migrate, and it would inject that in correctly without having to do any, you know, weird stuff having an extra JSON file or whatever. Right?

Yeah. Cool.

Also, I'm curious your opinions here on, like, when something should be a, like, a constant versus go in in environmental variable.

Because, like, sometimes I go nuts and just put, like, every single URL ever into it. I'm like, well, that that might change.

But then, like, when I'm searching through my code, it's kinda tricky. Like, at what point is something a constant, and what time does something become an environmental variable?

I mean, I I would say the purists would say when it's dependent on the environment. So if, you know, if that URL is going to change, it should be an environment variable. But I don't know. What do you what should you think there for you?

I will say this. Because dot env is such a pain, I think everyone avoids it. Right? You avoid putting stuff in envars because your your your .env. Example gets so long, and you copy paste it, and it's, like, illegible. Right? Whereas Yeah. Now when you have this schema, the more work you put into it, the more comments you put in there, and the more validation you put in there, the more valuable it gets. And you're not trying to keep anything in sync anymore. So I've I've personally found JS we start using it, I'm putting more and more stuff in there because I have this really nice tooling, Node, like, really nice type completion, really nice validation. It's like, if I think this thing might change or just kinda even feels config y, why not throw it in there? Throw it in there. I agree. Like, the

not having it typed is a major reason why I often would be like, maybe maybe throw this in, like, a constants dot Wes file.

Yeah. And, like, recently, I don't know, in the last couple Yarn, all of my CloudFlare Worker stuff, they do a really good job at typing your environmental variables. Mhmm. And they have this they have this new thing where it will just auto generate for you, and it's all beautifully typed. And you just import e n v. And, like, I'm like, oh, this is, like, a nice experience for environment environment environment. It sounds like this is a lot like, maybe even better. Right? You can you can have everything fully typed. Yeah. And you get and it's self documenting too.

So there's a we have a docs decorator where you can give it a URL, so you can literally, like, link out to documentation.

So when you, you know, you hover over that variable, you get the nice IntelliSense with a description and a link to the docs.

So it's it's a nice sort of onboarding tool for new developers or debugging tool as well.

Yeah. Like, the IntelliSense is pretty awesome. Like and and it's it's just not possible to get this from something like Zod. Right? Zod is doing all this crazy magic TypeScript voodoo to extract, like, the the types from this big crazy schema. We just generate a normal TypeScript, like, file. And each one of those, the when you look at it, like, the comments are really long because we actually also have, like, a little SVG in there. So we use, like, iconify.

You can attach an icon to everyone too. So it's like you hover over the, like, whatever, Google API key, and there's, like, the little Google logo. Like, it looks really slick.

And it's just it's to a level where you would never do it yourself, but it just when you're actually using it, it's it's beautiful.

Yeah. And you can picture a world where, you know, some of these are vendor provided, and you don't you don't even have to write them by hand. Like, we we'd like to get eventually get there, like, have a big schema registry for off the shelf stuff. Yeah. Right? That'd be cool. Yeah. I was wondering about that. I I love the the decorator syntax, honestly,

because it's really readable. I was just seeing the one that was prevent leaks.

What JS that doing? That that's like it's seeing if your Yarn is used in an HTTP request and then throwing an error. That's pretty sick. Wes do we do two things,

with sensitive you know, we know exactly which values are sensitive, and we know the real value. So we're not trying to do any, like, oh, this thing looks like an API key, so we better be careful with it. Like, it's like, no. This is the API key. And there's there's two things we do, currently only in JavaScript, but, we patch global console methods to automatically redact that value if it's written out. It's a lot of error. Yeah. And then we also do that if you do varlock run, like, it's it's, redacted and standard out and, like, sort of on the way.

The other thing that we do is we patch global, what is it, server response and response objects so that if like, say you have an express server or whatever, any anything, basically, if you return one of those sensitive values in the outgoing HTTP response, it will block you.

So, like, especially if, say, you're writing an MCP server, right, that needs access to a bunch of sensitive keys, it's probably not gonna leak anything. But this is just an extra layer of protection where you know it is physically impossible for it to leak it.

Yeah. Or in this sort of RSC world where it might be hard to reason about where a component is rendered in that tree on the client or the server, and then, you know, you change one dependent in that tree, and all of a sudden it's now rendered on the ESLint,

it'll prevent that. Oh, that's great. Yeah. I mean, it's it's just so easy to do the wrong thing, and it's like, why do I have to know all the rules and how which things I should put a prefix on? It's like, let's just make it so you can't shoot yourself in the foot. Make the easy way just to make sure

easy. Easy to do the wrong thing, which is what I like, yeah, what I like about this whole setup anyway. You know what you guys should do? And I know that we shouldn't be putting them in dot EMV files. One thing that I I tweeted about many years ago is, like, I when I'm recording courses, you gotta make sure you don't actually tab to the wrong dot e m v file.

We I saw a couple couple weeks ago, somebody was streaming, and they're they they tabbed to the wrong, tab, and then their their key was on there, and somebody racked up a $3,000 AI bill just in in, like, an hour or two. Right? Like, it's so quick to do those things. And John Papa made a Versus Node extension that is called Cloak, which it basically just, like, blocks them out. So you can you can show your dot e m v file, but you can't actually look at them. But it stopped working, hasn't been updated in four or five years. You guys should, like, fix that Chrome extension and then just put a huge banner for Varlock. I'd be like, you shouldn't be doing this. Yeah. Stop doing this. Yeah. Stop doing this. Use Varlock.

Yeah. The the official one password Versus Node extension, I I believe does that with a little bit of setup.

And Okay. Yeah. There's a few more extensions I've seen pop up now lately.

Yeah. I mean, the the something I wanted to talk about was, like, because AI coding is so much easier now, the rate of, like, hey. I built a tool that injects environment variables or validates environment variables or, you know, encrypts them and you can send them to your teammates. Like, they're popping up literally every day. There's a new one. It's insane. And which clearly shows that people are not satisfied with the tooling as it is today.

Yeah. You Node? I think a lot of them get it wrong Wes they're like, hey. I built a tool. It checks to make sure that your example file and your real environment is, like, still in sync. It's like, no. You still have the same problem.

Actually, use a schema. Actually, load it so it can never be out of sync. Like, just remove the problem. Let's talk about, like,

just, like, AI agents in general. Right? Like, you're using Cloud Code or OpenCode or Gemini, CLI, any of these things.

In some cases, it's nice for them to have environmental variables. Right? And and I haven't seen a really good way of how to, like, necessarily inject those things. What's your take on that? Yeah. I mean, we

I I think we have a pretty great solution for that. So, like, you can do it with Varlock run, and just load the ones you need and pass those in. I think Theo has a quick demo if you wanna see it, but, we we don't have to do that now.

Yeah. No. I I I would like to see, like, what that process is like. And I can I can talk a bit about that while he's setting that up? Like, I think the difference there, especially with Claude, is, like, those secrets might not necessarily live in a repo. Right? They those might be sort of, like, outside the repo because you wanna you know, for example, the way we use it, we need to pass in the sort of, like, Amazon bedrock config so we can use that for our Claude instead of the default thing. So that doesn't necessarily live in the repo. It lives in the invocation of Claude. Right? So you can Yeah. You can stick that in your home folder

and just pass that in when you when you load the when you load Claude. Yeah. So, I mean, there's there's a a bunch of different parts of this problem. Right? But this is one specific part, which is, like, I actually just need some keys to run the AI agent itself, not like that the AI agent will need. But I've got this dot e n v dot cloud file that lives in my home folder. Right? And it's using a a plug in to say, hey. I'm you know, I wanna be able to talk to 1Password.

I initialize it with some settings.

I have my function that's gonna fetch that from 1Password. You know, I mark it as sensitive, some other configuration.

Right? And then in my sort of, you know, setup, I have an alias for v clod, which calls varlock run, points at the dot env dot clod file that's in my home folder, and then runs clod.

So, like, that is obviously, it's only part of the problem, but this lets me have, you know, a centralized place outside of the context of one repo to fetch these environment variables, feed them to cloud itself, which, like, I think is just super handy. Right? As soon as as soon as I had it set up, I've been using it all the time, and it's awesome. And those variables could be, you know, auth keys for MCP servers or anything, you know Node.

Downstream of cloud itself. Yeah. I mean, obviously, then there's then there's, like, the next part of the problem, which is, like, how do you, you know, how do you limit sort of the agent from having access to things? And, you know, there's there's some different things there. Like, you could use a proxy.

At the very least, you can limit what environment variables are passed to it in the first place.

That's something that you can do with us.

Ben, at Node JS just using it for Bos bot, which is sort of like his OpenClaw, you know, teammate kind of thing. Very cool. Are we talking about Ben vinegar?

Yeah. We are.

A former Syntax,

team manager, Ben Vininger. Yeah. Shout out to Ben. So he just he just started using, this for to run Bos. Right? And he's got all these different keys that his the the bot needs. Right? So at least having that schema there, it's very clear what's there, what are the types, you know, explode if they're not if they're not correct. Yeah. So I think there's there's two sides to this. Right? There's the

security guardrails we already talked about to prevent the secrets from being leaked to the agents. So, you know, getting them out of plain text and then preventing leaks in those HTTP responses in your your console log statements, etcetera.

And then I think one of the big benefits is this schema driven approach. So the the agents themselves are pretty adept at writing it because it's, you know, a known DSL that they can reason about, and they have a the CLI method they can call to validate the output. So, you know, schema in, validation out, they they you can write a pretty short Claude skill, and it it usually does a good job. That's great.

Yeah. And speaking of, like, AI stuff, I noticed you all have both an MCP and a l l m JS. T x t, which is just like, you know, the docs in a text format. But what's the MCP doing for you all? It's just

a doc search. So Cool. It's it's just, I believe it's using the CloudFlare AI gateway and then autorag, pointed at the doc site itself.

So just an easier way. You Node? I I think if you just, like, ESLint it at that server and tell it to install Vercel and do the onboarding, it'll do a pretty good job. But I probably need to retest that because it's been a few weeks. Sure. Yeah. A few weeks. Lifetime

here. Yeah. I know. Yeah. I appreciate you all having open code config in your copy and paste, config for the MCP. So many people don't put that in there. I don't know why. I think OpenCode's getting a little bit more ubiquitous, but still,

good job. Great for that. Great Toronto startup.

We we both spoke at one of Ben Vinegar's events a few months ago. Ben Ben is the man,

for sure. I actually have a quick question here.

You have, like, GitHub, GitHub Actions integration.

I hate working with e n v vars in GitHub Actions. What does this do for me there?

Yeah. So it's it's a pretty thin wrapper on the CLI, but it allows you to do, you know, just a quick validation in CI.

Yeah. So, you know, that would be the equivalent of running I think it actually is just running Varlock Node. So that that way, you can validate your end as a first step before you do the rest of your workflow.

Oh, I hate when my action fails because the e n v Yarn is wrong or missing or something, and I don't find out till, like, the third step, and I have to sit and wait. And, like, for me, that, like, feedback loop of, like, it takes so long

that I just, like, lose my mind with that stuff. Yeah. And then you get you get a nice pretty printed redacted output. Right? So you can see what key was missing or which one failed validation.

And if in the case where you're using, you know, GitHub secrets, you can just go in and paste in the key you forgot or whatever.

Sick. That sort of output in CI to show you what is the current state of all your environment, I have found extremely useful.

You know, just it's such a nice debugging tool to be able to go and see what what was actually going on here because, you know, in the past, you'd just the amount of back and forth you'd have to do to start, you know, logging things and, like, then take it out of the code is just such a pain.

And just I did wanna clarify one thing about the GitHub action, is that, like, if you're using a sort of you Node? Say you have, like, a whatever, Svelte app or Next app or some JavaScript thing, like, you probably don't actually need to use that action. It's already built into your code and, you know, how it's loading and everything. So, like, that action would be just for if you weren't really using Varlock, like, deeply tied into your code else like, other Oh, I see. So if you're using it to be in your Node.

You're you're saying if you were using, like, the Vite Varlock plug in, not not just if you're using a SvelteKit app off the shelf. Like or, like, if if you have Varlock

built into your code Bos Yeah. Already Okay. Cool. You don't have that. You wouldn't need the action. Like, you'd you'd already have it installed. You could just you know, you could invoke it yourself. You can it's already gonna fail if your build fails at the beginning. So it's Hell, yeah. But it's nice if you, say, if you have, like, a multi step workflow and you need to, you know, thread an environment variable

through later steps, it gives you an easy way to reuse them, output them. I'm curious what your opinions on,

like, secrets managers are and, like like, should we be using them? I know some people have, like, services that they use and, like, you've got a thousand developers, and you can manage access to them.

Probably for smaller folks, just throwing them in Node Password is probably good. But, like, what do you think about, like, signing up for something and having a place where you can put all of your secrets?

We're big fans of 1Password.

You know, I think that even for a lot of people that are using something else on top of it, the secret still probably lives in 1Password as the source of truth. So it's like, why not just use it as the source of truth instead of copy pasting it? You know, Vault is a nightmare. ESLint physical JS a bit better.

All the cloud providers have their own things. Doppler seems like they're all fine, but they're all they're all enterprise tools that would only make sense if you are, like, an enterprise and willing to pay all this money. And so, like, we wanted to build a tool that would make sense to use even when you're a solo dev and you're doing everything yourself and then scales up to a giant team and, you know, having a lot of complex stuff going on. Yeah.

Man. And and this JS not anything to do with Varlock, but I'm just curious if you have any thoughts on it. Is I every time I spin up a demo, I need to go grab an API key from somewhere. You know? You Node log in to gotta remember what the OpenAI play like, playground URL is or, like, you have to do like, slay the dragons that is the Google, developer console god. Defining they're they're just all so awful. And and I'm reminded of, like, some of these tools for AWS to set them up. You have to, like, set up Wes IAM rule that allows That's horrible. To you to do anything. Yep. And then then the tool itself will act on your behalf. I'm curious if you've ever thought about something that will allow you to generate API keys from multiple services as you need it. Because I always want, like, an API key from whatever and put, like, a $10 limit on it, you know, and just fussing around. I don't I'm not reusing API keys across projects because if that gets out, then I'll I'll have no idea

which one how that leaked. Right? Yeah. Yeah. I mean, the the the holy grail of all this is, like, automated secret rotation and dynamic keys. Right? So you have a master key, right, that only lives in, say say that lives in like, we'll talk through the CI, case. Right? So let's say you have a master key that lives in GitHub, but as part of the, like, deployment CI run, it's going to issue a new key that has, you know, less privileges and is only gonna be around for a little while.

And it is something that we're working on. Like, it it's just it's tricky.

It's really tricky.

And, like, I'm sure a lot of, like, these companies don't want you giving out API keys as well. You know? Like, is there an API for API keys to every business?

No. OpenAI actually has one.

Oh, really? Yeah. Which is it's slightly terrifying because if you have a master key, I believe you can just mint new master keys. Just a whole bunch.

So don't leak those master keys, folks. Yeah.

Oh, yeah. Oh,

man. Oh, man. So okay. So this is this project is is is just, like it's free to install and use. Right? Like, what what's the what's the, like How do you guys make money? Yeah. Wes, how how's this thing gonna stay afloat? Is this sponsored, or what's the deal? Yeah. I mean, we've we've got investors.

We've we've got runway.

I I do think anything like this that you're trusting to put in your repo, you're trusting with your secrets, it has to be open source.

It has to be I mean, most of it has to be free. Like, I don't know about you, but I I don't think I'd I'd be putting, like, a black box binary on my computer and trusting with my secrets. Although, maybe maybe that's not the case anymore. We npm install those every single day. Very much. Yeah. And then it installs five more and then takes your Google wallets. Yeah. Yeah. I mean, long term, obviously, like, there's a secret management play here.

Today, we're kind of, you know, that platform platform agnostic control plane that sits in front of all of them. But, you know, there's obviously a future where we have our own offering there as well. We're exploring some sort of more enterprise y workflows right now around dynamic secrets, secret rotation, that kind of thing, which, you know, there's a pretty hefty cost to running the compute.

So it it certainly will not be free.

Yeah. So there's no, like, there's no rug pull coming with the library. Right? You just No. That's not the library. We're all good. Day one, we we both agreed there will never be a rug pull, especially seeing, you know, a company like Casha Warp lose so much good favor with the community after after doing that or, you know, Mongo, Redis, etcetera, all these licensing changes that never really

make anyone happy except the people who make money from it. Yeah. But you you can easily imagine our own hosted secret, you know, sort of back end. Right? You can imagine, some additional features around, like, logs, and policy. Right? Like so ensure that none of my developers have any plain text secrets on their machine. Right? Like, you can imagine sort of some of those enterprise y features, the the automated rotation, dynamic secrets.

But, you know, we we we always were like, let's let's start with just making the tool useful for everyone Yeah.

Rather than, like, here's a, you know, secure place to put your secrets. Now have fun wiring it into your code. Like, we start on the other end.

That's awesome. Well, I definitely wanna give a shout out. We we recently participated in the GitHub secure open source fund, with a bunch of the, like, most popular open source projects in the world.

It was really great to be, you know, one of the smaller participants.

So shout out to them. We just announced that last week. Hell, yeah. Yeah.

Yeah. That rolls. You know, I think for a lot of people, like, if you're using one password already like, so many people we talk to are using one password, but they don't really think about using it for their developer secrets. Right? That's me. Yeah.

I would say they do have some offerings in the sort of developer workflow stuff. Our tool obviously makes it easier and adds a whole lot more on top.

So if you do use 1Password, give it a shot. Try it out.

I love, you know, scanning my finger to unlock the secrets. It just feels good. I don't know how safe it really is, but it it feels much safer.

And the fact that it all is a single source of truth that, like, I can update it in one place, I can think about it, it's all, you know, together JS just super nice. And and, you know, that is one of the benefits that 1Password has, like, versus something like AWS or these other tools. Like, you always need a secret zero, right, which JS, like, what lets me connect to this back end? With 1Password, because you're also using it for other stuff, you already have the secret zero. It's already set up. It's on your machine. Whereas for anything else, you're gonna need, you know, an API key, machine token, whatever, which you then need to store somewhere on your machine, and you run back into the same problem. So if, like, where do I put this? How do I keep it secure? Totally.

Alright. Last section we have here is sick picks and shameless plugs. Did you guys come prepared with either of those?

Yeah. I can I can start if you want? My Please. Sick pick is, bella dot I o, b e l a. They make these awesome little, I don't know, audio modules.

So this is a BELLA gem multi. It's a 10 in, 10 out audio interface, and it has, like, a web IDE.

You just plug it into your computer with a USB c cable, and you've got an IDE for it.

I can see Scott's eyes lighting up. I can see that there's a couple of calls. One for sure.

So you can, like, make you can make custom instruments with it. It's super cool. You can run through data patches. Yeah. Programmable

Eurorack module? Dude. Yeah. They have open source Eurorack modules too. Yeah. I mean What?

I don't even know what this is.

It's so much trick.

It's like, it's a sound card with a computer bolted to it and an open platform that lets you write code. So, you know, you could make a synthesizer with it.

You could like, big artists use it for installations because you can process, you know, sensors and stuff through it. That's why I got it. Cool. Oh, so inputs

to this are

what? There's 10 audio inputs and 10 audio outputs, and then there's analog pnpm, you know, so, like, voltage. And then digital voltage, you know, like like, you would have on the GPIO pins of a Yeah. Raspberry Pi or something.

Oh, that's cool. Yep.

This seems very hackable and very cool. Scott of cool stuff on here. Yeah. I mean, their Eurorack modules are super fun too. That Bell of the Gliss Oh. It's just a little touch strip.

Yeah. I've got the best idea for your business, for Farlock.

Instead of touching your finger, you have to play stairway to heaven to unlock your environmental

variables. Dude. Yeah. Well, there's no stairway allowed here. Sorry. Oh, there's no stairway.

Yeah. Oh my god.

We we we did that for our CAPTCHA challenge. I made Wes sing, certain pitches. It would say, like, sing a d flat or something,

a d sharp. And, like, the hilarious part is I didn't know what a a d or a e was. Like, I don't I don't know. I I'm an enjoyer of music, but not I don't know anything about making music. So I had to Scott had to coach me through how to sing an e.

Awesome.

And, yeah, shameless plug.

I make music too. So if you go to nauticalartifacts.bandcamp.com, all my all my stuff's up there. There's a new remix album probably coming the next month or two. Cool. Love the art.

Sick.

Canadian as well. He's Hamilton. I didn't didn't say this as Wes, but, yeah, Phil's from Hamilton, which is awesome.

I'm from Hamilton, best city in the world. So

I I'm almost from Hamilton.

Theo, what do you got? Yeah.

Sick picks. Let's see. I've I've really been enjoying a new show lately that I had not heard about at all. It's called Wonder Man on Disney, and it is a Marvel Vercel show with very little superhero y stuff in it, and it is it's really, really excellent.

I'm loving it. Yeah. I haven't heard of it. Yeah.

And shameless plug, I've been building a little side project with, you know, with my new AI superpowers as we all probably are.

The website is howtostore.food, and it is a sort of comprehensive, comprehensive guide for, you know, kiwis. Do they go in the fridge or not? You know? How do can you freeze them? Can you dehydrate them? Just everything you could possibly think of.

And I've used, like, a ton of really, really cool, like, CSS, page transitions.

It's really beautiful.

Nice.

Scott. It's not it's not quite done yet, so I'm I'm hoping it'll be ready by the time this goes out. But, yeah. It looks it. Please check it out. Alright. Can you settle a bet for us since you're a a food storage expert?

I could try. Soy sauce.

Is that fridge or or cupboard?

You know, I keep my Not what it says on the bottle, but I No. Let's hear what he has to say. Yeah.

I keep mine in the fridge.

But I tend to re I tend to look at the bottle and see what it says, and and that's kind of all it. Yes.

The man has gotten you. Okay. Deno.

That's fine. It's perfectly the fine way to to live your life is to look at the bottle and put in the fridge if it says two. That's perfectly fine. But but I that would definitely be one

that would be one where if somebody had it not in the fridge, I wouldn't be like, oh Node. It's gone off. Like, I'd be like, no. It's fine. Whatever.

I I prefer people who don't keep ketchup in the fridge.

Node me. Oh, that was me. We grew up. I as a a child, we grew up with a ketchup, and then you'd get this, like, you'd get the, like, ketchup sauce on the top because it would separate, and you have to shake it. But I was fine, but we we were in the fridge now. So it's actually interesting that I changed that, but certainly not soy sauce. There's people that don't put mayonnaise in the in the fridge. Matchful. Mayo

goes in the fridge for sure. Mayo goes in the fridge. What? How do y'all feel about butter?

Butter out of the fridge for sure. Wes put it on we put it on top of the, in the cupboard on top of the light, so it's always a little bit melty.

Yeah. I prefer it out of the fridge, but we keep it in the fridge. A lot of people keep it in the fridge, but I'm telling you, if you're one of those people, try it out of the fridge. And then when you go to spread it on something, you'll be like, what have I been doing with my life? Yeah. I don't know how people could do it. Like, half the year, our butter is JS too hard when it's out of the fridge. It's not a easy spread, I'll tell you.

Yarn one.

Oh, man. Awesome. Well, thank you guys so much for coming on. Check it out, varlock.dev.

And, k. I'm gonna get my, I'm gonna get my house in order and arrive to get your house in order right now. Yeah. Please please give us a star Environment.

JS an open source developer,

we we need those stars. So if you do check it out, please give us a star on GitHub. I just Scott at Node fourteen. If you're listening to this right now, if you are one number 1,000,

you will win a free environmental variable. I'll give you a sweet T shirt if you're a number 1,000. Sweet shirt and some stickers. Yeah. We got we still have to make them, but that now now I have to make it. And you guys got great branding, so the shirt is going to be sick. So

Alright. Peace.

Thanks so much.