985: Stop putting secrets in .env

Scott and Wes are joined by Phil Miller and Theo Ephraim to talk about Varlock, a new approach to environment variables that adds schemas, validation, and security to the humble .env file. They dig into the risks of traditional env workflows, how schema-driven configs improve DX, and how tools like Varlock help manage secrets safely across frameworks, CI, and AI-powered workflows. Show Notes 00:00 Welcome to Syntax! 03:15 The Risks of .env Files 04:58 Introducing Varlock: A Unified Solution 06:56 Schema-Driven Environment Variables 11:47 Integrating with Various Frameworks 14:08 Brought to you by Sentry.io 14:32 Cross-Language Compatibility 17:50 Best Practices for Environment Variables 21:11 Security Features of Varlock 25:02 AI Integration and Environment Variables 29:12 Introduction to Varlock and GitHub Actions 32:45 Secrets Management and Best Practices 36:09 The Future of Varlock and Open Source 38:36 Sick Picks + Shameless Plugs Sick Picks Phil: Bela.io Theo: Wonder Man Shameless Plugs Phil: nauticalartifacts Theo: howtostore.food Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. If you have a .env file sitting on your computer, this is the episode for you because we're going to talk to you about why you shouldn't be doing that. My name is Wes Boss 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 want to 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 into Notion for me is like a ritual, or I have to like use a thousand things and there's beep, bop, boom, PIN codes and everything.

• 0:45Wes Bos?

  And then we just put the like database string in a .env file. So, welcome guys. Thanks a lot for coming on.

• 0:51Speaker 01

  Yeah, thanks for having us.

• 0:52Speaker 02

  Thanks so much for having us.

• 0:53Wes Bos?

  So, let's start there.

• 0:54Speaker 02

  Yeah.

• 0:55Wes Bos?

  What's wrong with .env files?

• 0:57Speaker 02

  Well, yeah, I mean, why don't we first just talk about like, you know, you have these files sitting there. Often you're putting plaintext secrets in there. And you know, maybe you don't have any like super sensitive production secrets in there, but you still probably have some, 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 where they're just reading all your files, slurping it all up, sending it off to some server, like the only real safe way to ensure that they're going to be not sent up to, you know, OpenAI is to get them out of plaintext altogether.

• 1:35Speaker 01

  To go back a bit to answer your question, I think the reason they're sitting in plaintext is because every tutorial on the internet, the first step is put the secret in plaintext in a .env 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?

• 1:58Scott Tolinski?

  I think that even the harder challenge 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?

• 2:06Speaker 02

  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, you're like, I could do it that way, but it's just not worth the hassle.

• 2:20Speaker 01

  And people like to say that they do, you know, security best practices, even if they don't always do them, right? They're gonna, they're gonna choose the path of least resistance, especially if it's a last minute thing, right?

• 2:31Wes Bos?

  Yeah, I'll give you an example. So me and Serge were working on the Mad CSS website and, and he was sort of like scaffolding it out 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 says 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 know, I can't get it to work with like these two specific things.

• 3:04Speaker 02

  Copy paste.

• 3:04Wes Bos?

  Which I think happens probably more often where people are just like, ideally, yes, 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 is the solution here? So like, what should we be doing?

• 3:19Speaker 02

  So like, let's also, let's go back a second and just talk about like .env, .example. Cause like regardless of how you're shoving stuff in there, like the common way is like, okay, at least we have a .env, .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, you're, 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.

• 4:03Speaker 02

  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 cons, scatter it all throughout your codebase. Dude.

• 4:49Scott Tolinski?

  I, you're like, you're doing, you're speaking exactly what I do.

• 4:53Speaker 02

  Yeah. Have you been looking at our code?

• 4:56Speaker 02

  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 non-sensitive 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 .n file, but we use JSDoc

• 5:39Speaker 02

  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, ABC underscore, 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 .n 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.

• 6:20Speaker 02

  So there's a plugin for one password, OP, whatever. There's a plugin for AWS, for GCP, for Azure, for whatever. And it's super easy to write new plugins. 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.

• 6:38Speaker 01

  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.

• 6:56Wes Bos?

  Okay, so I'm looking at it right now. It's a .env schema file that you, I assume you commit to your repo, right? Like this is something that's allowed to go

• 7:07Speaker 01

  Yes.

• 7:07Wes Bos?

  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 like, oh yeah, here's, here's what I think you need in like the .env file. And then they're like, they run it and they get an error, process .env whatever, not defined, right? And your example is out of date, all that type of stuff. So this is really nice that you do that as well as, as the actual types, which is also nice. Like you can describe starts with ., like SK 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.

• 7:49Wes Bos?

  So, and then everybody who's working in your project then has the .env 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?

• 8:07Speaker 02

  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 .env 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 the right place. You can load a whole bunch of stuff from one password at once, like whether it's an environment or a single item that's like a .env 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 going to inject real environment variables from, you know, the Vercel Secrets UI, right, for prod.

• 8:50Speaker 02

  You're still getting that extra validation and, you know, especially when it fails now, instead of getting this weird runtime explosion.

• 8:57Scott Tolinski?

  Oh, yeah.

• 8:58Speaker 02

  It's like, this thing blew up. When it goes to try to build or boot or whatever, it's going to say, hey, this environment variable is missing and it's marked as required. Or this thing doesn't, you know, it's typed in wrong.

• 9:10Scott Tolinski?

  Yeah, I remember when I first saw this, I was worried about like, production, but you're, you're not modifying the ENV file. You're just, you're still copying and pasting the ENV vars into Vercel or whoever's dashboard the same way, but you are still getting all the features. So that's, that's, that's really.

• 9:27Speaker 02

  You could do either. You could do it, you could, you could, you know, 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 want to actually centralize all this, so I'm going to move everything to one password. 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 one password. And especially if you're in sort of like multi-cloud, you know, microservice situation and you've got a million things going on, like centralizing everything into a sane way of dealing with it is going to be, you know, much, much easier.

• 10:02Scott Tolinski?

  Yeah, that makes a lot of sense. I, it's funny because like, when you first hear about like, okay, we're adding, we're adding a schema to your ENV vars and, you know, type safe comments and all this stuff. It all feels like, maybe that's too much for ENV vars? And then 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, uh, this is like, kind of a missing piece of technology, right?

• 10:36Speaker 02

  One of the best feelings is when you implement this and then you go and delete all of that.

• 10:40Speaker 01

  Code that's just checking node end.

• 10:43Scott Tolinski?

  Oh, yeah.

• 10:44Speaker 01

  So you set up value in production or value in staging, all of that goes away, right? What you 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 dev schema, a staging schema, a production schema. They could either be expressed in separate files or using some of our sort of primitives in one file.

• 11:06Speaker 02

  Yeah. And so, you know, you can, you know, there's also like, there's an imports in tax, right? So you can import from other places in a mono repo. 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 know, it's, it's very, very flexible.

• 11:21Scott Tolinski?

  Yeah. So what does that buy in look like for the import? Is it really just swapping out your process dot env imports or whatever with Varlock imports?

• 11:30Speaker 02

  So, well, so what I'm talking about is importing from within a dot N file, importing another dot N 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 end, 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, V, next, you know, Astro, all that. And you, you could continue to use process dot end because they are just injected as environment variables. But we also have a sort 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, end dot,

• 12:14Speaker 02

  whatever Boolean thing, it's going to be true or false. It's not going to be one or zero or true. And hey, check if this thing is a string or, you know, all that extra coercion logic you end up shoving in five different places. All that just goes away.

• 12:28Wes Bos?

  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 env from Cloudflare workers, which I like better than just process dot env. But I don't like that because then, then it makes my code like kind of pigeonholed into... Wait, didn't node, doesn't node do that as well? You talk, you then, experts.

• 12:55Speaker 02

  I mean, you can use process dot env. There's also import dot env for import meta dot env, right? And 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 at 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 really do try to simplify a lot of that. So we have this import env from varlock slash env helper, and that does try to just make it work in all cases. So that works in the front end

• 13:38Speaker 02

  and the back end, and it does the replacements with vite and all that stuff. 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 lot more explicit in terms of what you want it to be doing.

• 14:01Wes Bos?

  Yeah, it's not just this random thing that's available in the air. Like, where does process come from, you know?

• 14:07Speaker 02

  Yeah.

• 14:08Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/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 sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 14:33Wes Bos?

  What about other languages as well? Like, this is not just a JavaScript thing, right?

• 14:37Speaker 02

  Yeah, I mean, why, you know, one could argue, you know, why are you using even using a dot env 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 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 code. It's just not going to happen, right? Whereas if you say, hey, look, it's a .n file with some extra little markup on it. Those like, oh, that actually makes sense.

• 15:22Speaker 02

  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, Rust, like what, whatever, right? It's by separating it, it becomes a lot more applicable for, for anything.

• 16:06Speaker 01

  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's coming too.

• 16:26Wes Bos?

  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 it injects it into the environment and then that, then it runs like, like it will 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 sub process, the variables don't get pushed to it sometimes. Is yours like that as well? Like, do I have to run Varlock something and, and npm run dev?

• 16:59Speaker 02

  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 VIT integration, we have a next integration. So those kind of happen at the like. You know, vite config level and it just works.

• 17:16Wes Bos?

  Okay.

• 17:16Speaker 02

  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 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?

• 17:50Wes Bos?

  Yeah, cool. Also, I'm curious your opinions here on like when something should be like a constant versus go in an environmental variable. Because like sometimes I go nuts and just put like every single URL ever into it. And like, well, that that might change. But then like when I'm searching through my code, it's kind of tricky. Like, at what point is something a constant? And what time does something become an environmental variable?

• 18:19Speaker 01

  I mean, 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 think there, Theo?

• 18:31Speaker 02

  I will say this, because .env is such a pain, I think everyone avoids it, right? You avoid putting stuff in Nvars because your .m example gets so long and you copy paste it and it's like illegible, right? Whereas 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 as we start using it, I'm putting more and more stuff in there because I have this really nice tooling, nice, like really nice type completion, really nice validation. It's like,

• 19:09Speaker 02

  If I think this thing might change or just kind of even feels configy, why not throw it in there?

• 19:14Wes Bos?

  Throw it in there. I agree. Like the not having it typed is a major reason why I often would be like, eh, maybe, maybe throw this in like a constants dot TS file. And like recently, I don't know, in the last couple of years, all of my Klafler worker stuff, they do a really good job at typing your environmental variables. 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 ENV and like, I'm like, oh, this is like a nice experience for environment variables. And it sounds like this is a lot. Like maybe even better, right? You can, you can have everything fully typed.

• 19:50Speaker 01

  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.

• 20:14Speaker 02

  Yeah, like the IntelliSense is pretty awesome. Like, 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's just when you're actually using it, it's, it's beautiful.

• 20:59Speaker 01

  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'd like to eventually get there, like have a big schema registry for off the shelf stuff.

• 21:10Scott Tolinski?

  Yeah, right? That'd be cool. Yeah. I was wondering about that. I, I love the, the decorator syntax, honestly, uh, because it's really readable. I was just seeing the one that was prevent leaks. What is that doing? That's like it's seeing if your var is used in an HTTP request and then throwing an error?

• 21:28Speaker 02

  So we 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.

• 21:56Speaker 02

  And then we also do that if you do var lock around 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, 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 going to leak anything, but this is just an extra layer of protection where you know it is physically impossible for it to leak it.

• 22:36Speaker 01

  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 client. It'll prevent that.

• 22:52Wes Bos?

  Oh, that's great.

• 22:53Speaker 02

  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? And it's like, let's just make it so you can't shoot yourself in the foot. Make the easy way to secure.

• 23:06Scott Tolinski?

  Easy to do the wrong thing, which is what I like. Yeah. What I like about this whole setup anyway.

• 23:10Wes Bos?

  You know what you guys should do? And I know that we shouldn't be putting them into 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 EMV file. I saw a couple, couple of 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 like an hour or two, right? Like it's so quick to do those things. And John Papa made a VS code extension that is called Cloak. Which it basically just like blocks them out. So you can, you can show your .env file, but you can't actually look at them. Uh, but it stopped working, hasn't been updated in four

• 23:55Wes Bos?

  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. Uh, yeah. Stop doing this. Use Varlock.

• 24:09Speaker 01

  Yeah. The, the official one password VS code extension, I, I believe does that with a little bit of setup. Uh, yeah.

• 24:17Speaker 02

  There's a few more extensions I've seen pop up now lately. Um, yeah. I mean, that 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. Um, you know, I think a lot of them get it wrong where 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.

• 25:02Wes Bos?

  Let's talk about like, just like AI agents in general, right? Like you're using Claude Code or Open Code 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?

• 25:22Speaker 01

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

• 25:37Wes Bos?

  Yeah, no, I, I would like to see like what that process is like.

• 25:41Speaker 01

  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? 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

• 26:10Speaker 02

  Yeah.

• 26:10Speaker 01

  You can stick that in your home folder and just pass that in when you, when you load the, when you load Claude.

• 26:17Speaker 02

  Yeah. So I mean, there's, there's 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 env dot Claude file that lives in my home folder. Right. And it's using a plugin to say, hey, I'm, you know, I want to be able to talk to one password. Uh, I initialize it with some settings. I have my function that's going to fetch that from one password, you know, I market as sensitive, some other configuration. Right. And then in my sort of, you know, setup, I have an alias for V Claude, which calls Varlock Run, points at the dot env dot Claude file that's in my home folder and then runs Claude.

• 27:03Speaker 02

  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 Claude 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.

• 27:21Speaker 01

  And those variables could be, you know, off keys for MCP servers or anything, you know, downstream of Claude itself.

• 27:29Speaker 02

  Yeah. I mean, obviously then there's, then there's like the next part of the problem, which is like, how do you, uh, you know, how do you limit sort of the agent from having access to things? And, you know, there's, there are 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, uh, at modem is just using it for Bodbot, which is sort of like his open claw, you know, teammate kind of thing. Very cool.

• 28:00Scott Tolinski?

  Are we talking about Ben Vinegar? Yeah.

• 28:02Speaker 01

  We are.

• 28:04Scott Tolinski?

  A former Syntax Team Manager, Ben Vinegar.

• 28:08Speaker 01

  Yeah.

• 28:08Scott Tolinski?

  Shout out to Ben.

• 28:09Speaker 02

  So he just, he just started using this for, to run Bodbot, right? And he's got all these different keys that his, that 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.

• 28:25Speaker 01

  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, et cetera. 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 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.

• 29:11Scott Tolinski?

  That's great. Yeah. Yeah. And speaking of like AI stuff, I noticed you all have both an MCP and a LLM.txt, which is just like, you know, the docs in a text format. But what's the MCP doing for you all?

• 29:27Speaker 01

  It's just a doc search. So

• 29:29Scott Tolinski?

  Cool.

• 29:30Speaker 01

  It's, it's just, I believe it's using the Cloudflare AI Gateway and then AutoRAG, point it at the doc site itself. So just an easier way, you know, I think, I think if you just like point it at that server and tell it to install Varlock 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.

• 29:52Scott Tolinski?

  Sure. Yeah.

• 29:53Speaker 02

  A few weeks is a lifetime here.

• 29:55Scott Tolinski?

  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 Open Code is getting a little bit more ubiquitous, but still.

• 30:08Speaker 01

  Yeah. Great, great Toronto startup. We both spoke at one of Ben Vinegar's events a few months ago.

• 30:14Scott Tolinski?

  Ben, Ben is the man, uh, for sure. I actually have a quick question here. You have like GitHub, GitHub Actions integration. I hate working with ENV vars in GitHub Actions. What does this do for me there?

• 30:31Speaker 01

  Yeah, so it's a pretty thin wrapper on the CLI, but it allows you to do, you know, just a quick validation in CI. So, you know, that would be the equivalent of running, I think it actually is just running var lock load. So that that way you can validate your end as a first step before you do the rest of your workflow.

• 30:48Scott Tolinski?

  Oh, I hate when my action fails because the ENV var is wrong or missing or something and I don't find out to 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.

• 31:06Speaker 01

  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.

• 31:20Scott Tolinski?

  Sick.

• 31:21Speaker 02

  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. Cause 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 want to clarify one thing about the GitHub Action is that like, if you're using a sort of, you know, say you have like a whatever Svelte app or Next app or some JavaScripty 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.

• 32:04Speaker 02

  If you weren't really using Varlock, like deeply tied into your code else like

• 32:08Scott Tolinski?

  Oh, I see. So if you're using Varlock in your code, you're saying if you were using like the Veet Varlock plugin, not, not just if you're using a Svelte Kit app off the shelf.

• 32:18Speaker 02

  Like, or like if, if you have Varlock built into your code base already,

• 32:23Scott Tolinski?

  Yeah, okay.

• 32:24Speaker 02

  Um, then 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.

• 32:34Speaker 01

  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.

• 32:45Wes Bos?

  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 one password is probably good, but it's like, what do you think about like signing up for something and having a place where you can put all of your secrets?

• 33:11Speaker 02

  We're big fans of one password. Um, 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 one password as the source of truth. So it's like, why not just use it as the source of truth instead of copy pasting it? Um, you know, Vault is a nightmare. Um, in physical is 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,

• 33:55Speaker 02

  having a lot of complex stuff going on.

• 33:57Wes Bos?

  Yeah. Man, and this is 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'll you'll 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. 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 a when IAM rule that allows you to do anything.

• 34:38Wes Bos?

  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 is if that gets out, then I'll have no idea which one, how that leaked, right?

• 35:05Speaker 01

  Yeah.

• 35:06Speaker 02

  Yeah, I mean, 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 going to be around for a little while. And it is something that we're working on, like it's just, it's tricky. It's really tricky.

• 35:40Wes Bos?

  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?

• 35:50Speaker 01

  No, OpenAI actually has one.

• 35:52Wes Bos?

  Oh, really?

• 35:53Speaker 01

  Yeah, which is it's slightly terrifying because if you have a master key, I believe you can just mint new master keys.

• 36:00Wes Bos?

  Just a whole bunch.

• 36:03Speaker 01

  So don't leak those master keys.

• 36:06Wes Bos?

  Oh, yeah.

• 36:09Scott Tolinski?

  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?

• 36:18Wes Bos?

  How do you guys make money?

• 36:19Scott Tolinski?

  Yeah, well, how, how's this thing gonna stay afloat? Is this sponsored, or what's the deal?

• 36:24Speaker 01

  Yeah, I mean, we, we've got investors, um, we've, we've got runway. Uh, 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.

• 36:48Wes Bos?

  Uh, we NPM install those every single day.

• 36:52Speaker 01

  And then it installs five more and then takes your Yeah, I mean, long term, obviously, like, there's a secret management play here. Um, 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 certainly will not be free.

• 37:26Scott Tolinski?

  Yeah. So there's no, like, there's no rug pull coming with the library, right?

• 37:29Speaker 01

  No. Absolutely. Day one, we, we both agreed there will never be a rug pull, especially seeing, you know, a company like Cashor Corp. Lose so much good favor with the community after, after doing that, or, you know, Mongo, Redis, et cetera, all of these licensing changes that never really make anyone happy, except the people who make money from it.

• 37:53Speaker 02

  Yeah, but you, you can easily imagine our own hosted secret, you know, sort of backend, right? Uh, you can imagine, uh, some additional features around like logs, um, and policy, right? Like, so ensure that none of my developers have any plain tech secrets on their machine, right? Like, you can imagine sort of some of those enterprise-y features, the, the automated rotation, dynamic secrets. Um, but, you know, we, we, we always were like, let's, let's start with just making the tool useful for everyone.

• 38:25Scott Tolinski?

  Yeah.

• 38:26Speaker 02

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

• 38:35Wes Bos?

  That's awesome.

• 38:36Speaker 01

  Well, I definitely want to give a shout out. 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.

• 38:55Wes Bos?

  Oh, yeah.

• 38:55Speaker 01

  Yeah.

• 38:56Wes Bos?

  Yeah, that rolls.

• 38:57Speaker 02

  You know, I think for a lot of people, like if you're using one password already, like so many people we talked to are using one password, but they don't really think about using it for their developer secrets, right?

• 39:08Speaker 01

  That's me.

• 39:10Speaker 02

  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 one password, 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 feels much safer.

• 39:35Speaker 02

  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 is just super nice. And, and you know, that is one of the benefits that one password has like versus something like AWS or these other tools. Like you always need a secret zero, right? Which is like, what lets me connect to this backend? With one password, 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 going to 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 problems of like, where do I put this? How do I keep it secure?

• 40:12Wes Bos?

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

• 40:21Speaker 01

  Yeah, I can, I can start if you want. My sick pick is Bella.io, B E L A. They make.

• 40:30Speaker 01

  These awesome little, uh, 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 the-

• 40:51Wes Bos?

  And Scott's already bought one, for sure.

• 40:53Speaker 01

  So you can like make, you can make custom instruments with it. It's super cool. Uh, you can run pure data patches.

• 41:00Scott Tolinski?

  Yeah. Programmable Euro Rack module? Dude.

• 41:03Speaker 01

  Yeah, they have open source Euro Rack modules too. Yeah.

• 41:06Wes Bos?

  What? I don't even know what this is.

• 41:09Speaker 01

  It's so- It's like, uh, 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. Uh, you could like big artists use it for installations because you can process, you know, sensors and stuff through it. Um, that's why I got it.

• 41:33Scott Tolinski?

  Cool.

• 41:34Wes Bos?

  Oh, so inputs to this are what?

• 41:38Speaker 01

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

• 41:51Wes Bos?

  Oh, that's cool.

• 41:53Speaker 01

  Yeah.

• 41:54Wes Bos?

  This seems very hackable and very cool.

• 41:56Scott Tolinski?

  They've got a lot of cool stuff on here.

• 41:58Speaker 01

  Yeah, I mean, their Euro Rack modules are super fun too. That Bella Gliss.

• 42:01Wes Bos?

  Oh.

• 42:02Speaker 01

  It's just a little touch strip.

• 42:04Scott Tolinski?

  Yeah.

• 42:04Wes Bos?

  I've got the best idea for your business for Varlock. Instead of touching your finger, you have to play Stairway to Heaven to unlock-

• 42:12Scott Tolinski?

  Oh, yeah.

• 42:13Wes Bos?

  Your environmental variables.

• 42:14Speaker 01

  Yeah, well, there's no stairway allowed here, sorry.

• 42:17Wes Bos?

  There's no stairway.

• 42:18Scott Tolinski?

  Yeah. Oh, my God. Uh, we, we, we did that for our capture challenge. I made Wes sing, uh, certain pitches. He'd say like, sing a D flat or something, uh,

• 42:29Wes Bos?

  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'll enjoyer of music, but not, I don't know anything about making music. So I had to, Scott had a coach to be through how to sing an E.

• 42:44Speaker 01

  Uh, and yeah, shameless plug. Uh, I make music too. So if you go to nautical artifacts. Dot bandcamp.com. Uh, all my, all my stuff's up there. There's a new remix album probably coming the next month or two.

• 42:57Scott Tolinski?

  Cool. Love the art.

• 42:59Wes Bos?

  Sick. Canadian as well. He's, I didn't, I didn't say this as well, but yeah, Phil's from Hamilton, which is awesome. Um, I'm from Hamilton, best city in the world. So.

• 43:11Scott Tolinski?

  I'm almost from Hamilton. Uh, Thea, what do you got?

• 43:15Speaker 02

  Yeah. Um, uh, sick picks. Let's see. I, 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 Universe show with very little superhero-y stuff in it. And it is, it's really, really excellent. I'm loving it.

• 43:35Scott Tolinski?

  Yeah, I hadn't heard of it.

• 43:37Speaker 02

  Yeah. Um, and shameless plug. Um, I've been building a little side project with, you know, with my new AI superpowers, as we all probably are. Uh, the website is howtostore dot food. Uh, and it is a sort of comprehensive, uh, 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. Um, and I've used like a ton of really, really cool, like CSS, um, page transitions. It's really beautiful. Um, 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, uh,

• 44:20Scott Tolinski?

  It looks sick.

• 44:21Speaker 02

  Please check it out.

• 44:22Wes Bos?

  All right. Can you settle a bet for us since you're a, a food storage expert?

• 44:27Speaker 02

  I could try.

• 44:28Wes Bos?

  Soy sauce. Is that fridge or, or cupboard?

• 44:33Speaker 02

  You know, I keep mine.

• 44:35Wes Bos?

  Not what it says on the bottle, but.

• 44:36Scott Tolinski?

  No, that's here what he has to say.

• 44:41Speaker 02

  I keep mine in the fridge. Uh, but I tend to re- I tend to look at the bottle and see what it says and, and

• 44:48Scott Tolinski?

  That's me.

• 44:49Wes Bos?

  And yes, the man has gotten to you. Okay.

• 44:53Scott Tolinski?

  No, it'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 to. That's perfectly fine.

• 44:59Speaker 02

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

• 45:07Speaker 01

  I, I've heard of people who don't keep ketchup in the fridge.

• 45:10Scott Tolinski?

  Hmm. Not me.

• 45:12Wes Bos?

  Oh, that was me. We grew up, I, as a, I, I, a child, we grew up with the ketchup and then you'd get this like, you'd get the like ketchup sauce on the top. Cause it would separate and you have to shake it, but I was fine, but we, we were in the fridge now. So it's, 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.

• 45:33Speaker 02

  Mayo, mayo goes in the fridge for sure.

• 45:36Scott Tolinski?

  Mayo goes in the fridge, what?

• 45:38Speaker 02

  How do y'all feel about butter?

• 45:40Wes Bos?

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

• 45:48Speaker 02

  Yeah.

• 45:49Scott Tolinski?

  I prefer it out of the fridge, but we keep it in the fridge.

• 45:52Speaker 02

  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?

• 46:01Scott Tolinski?

  Yeah.

• 46:02Wes Bos?

  I don't know how people could do it. Like half the year, our butter is too hard when it's out of the fridge.

• 46:07Scott Tolinski?

  It's not an easy spread. I'll tell you. Hard work.

• 46:13Wes Bos?

  Oh man. Awesome. Well, thank you guys so much for coming on. Check it out. Varlock.dev. And, uh, I'm gonna get my, uh, I'm gonna get my house in order and.

• 46:23Scott Tolinski?

  I'm getting my house in order right now.

• 46:24Wes Bos?

  Yeah.

• 46:25Speaker 02

  Please, please give us a star.

• 46:27Wes Bos?

  Environment.

• 46:28Speaker 02

  As an open source developer, uh, we, we need those stars. So if you do check it out, please give us a star on GitHub.

• 46:35Wes Bos?

  I just started nine 14. If you're listening to this right now, if you are one, number 1,000, you will win a free environmental variable.

• 46:45Speaker 02

  I'll give you a sweet t-shirt if you're.

• 46:46Speaker 01

  Yeah, we'll give you a sweet shirt and some stickers. Yeah. We still have to make them, but that now, now I have to make them.

• 46:52Scott Tolinski?

  And you guys got great branding, so the shirt is going to be sick. So.

• 46:56Wes Bos?

  All right. Peace.

• 46:58Speaker 02

  Thanks so much.