0:00 Introduction (Host, Guest, Topic)

0:00 Hello, and welcome back to the Rawkode Academy. This is Rawkode live, and I am your host, David Flanagan. Today, I am joined by Lucas from Loft who is gonna interest introduce us to their new open source project, DevPod. Hello, Lucas. How are you? Hey, David. I'm doing alright. Thanks for having me on. Yeah. It's been a while. We haven't done a session like this for a long, long time, so it's nice to have you back in the hot seat and ready to show us something new and cool today. For anyone who hasn't seen our previous episode or

0:32 isn't familiar with you and your work, could you please take a few moments to introduce yourself and tell us what you've been up to? Yeah. Sure. I'm Lucas. I'm one of the founders of Loft Labs. What we do with our product Loft is essentially provide, you know, building blocks for platform engineers who have to build platforms on top of Kubernetes to provision, you know, clusters for the engineering teams, etcetera, in, you know, one of these building blocks. And I think that's the last time we've spoken, David, as vCosta. That's a pretty popular open source project we launched.

0:37 Guest Intro & Loft Labs Overview

1:08 We also maintain the DevSpace project, which we handed over as a sandbox project to the CNCF. And now we're on our third project, and that's that's what we're talking about today. Nice. Awesome. So the the project was announced last week, I believe. It's called DevPod, and I know that it's a tool that sits on top of dev containers and tries to give people virtual machines or infrastructure with all the tooling that they need to work on a project. Is that am I on the right line, sir? Yeah. That wraps it up pretty well. Yeah. We announced it last Tuesday.

1:19 Introducing DevPod: Concept & Vision

1:45 And DevPod, the idea is essentially, you know, you want something like code spaces, but you don't want it as a hosted managed service that kind of locks you into a specific infra, you essentially want that flexibility of, you know, spinning things up in your own AWS account or on Kubernetes or even a local Docker desktop and give it a freedom to switch back and forth whenever you want to do so. Right? You can save some cost by staying locally, and then you go to AWS whenever you need that power. And it really gives you the flexibility to, you know, dynamically switch between

2:19 these environments. I think that's the that's the true true power of this new project. Nice. I'm curious. Like, you know, obviously, there's been a substantial, I would assume, amount of effort and teamwork that's been entered us from the lost side to try and and make this a product that you can open source and put in the hands of thousands to tens of thousands or hundreds of thousands of developers. Like, what were the driving factors that, you know, you're all sat in Loft HQ one day drinking your coffee and you went, you know what? We should build this. Like, what was the original

2:27 Motivation for Building DevPod

2:49 driving factor then? Yeah. I guess Loft HQ is more like, you know, Slack channels and Zoom sessions because we're fully distributed. But, yeah, you're right. I think we were, you know, we were thinking about how can we you know, obviously, we were looking at these solutions, GitPod, Codespaces, etcetera, and everything that that happened in that space also for our own team. Right? And, you know, we're, like, over 20 people now. There's folks from the design side reviewing things that get changed in the UI. Then, you know, product wants to have a look before things are released.

3:26 And then we have the open source community contributing to our projects. And we are thinking, how can we make it easier for people to, you know, just launch an environment, spin up a certain branch, contribute a little bit? And, yeah, we were we were looking at code spaces because we're using, you know, repositories on GitHub or open source projects on GitHub, obviously. But then, you know, locking people into into that very specific environment. I mean, the experience of launching it is great if you are on GitHub. Right? But what if you're not on GitHub? Or

3:59 what if you are, you know, if you don't wanna pay for that premium that essentially they charge for these environments and you just wanna have that experience locally or you just wanna have that experience in your own Kubernetes clusters and EKS. Right? We were asking us these questions, and we didn't really find a great answer for that anywhere. So we just started building things internally. I think, you know, our CTO, Fabian, and and my cofounder, he's you know, he just sometimes just pulls things together over a weekend, and that was the same thing with DevPod. And that was, like,

4:34 an initial prototype. And that's already, like, I don't know, five or six months, you know, ago at this point. And, you know, it it seemed very promising and exciting, and we're like, okay. Maybe we should, you know, invest some time here and actually build a legit open source project out of this. And, yeah, that's what we did. And and, you know, now we're presenting it to the world. We had a little bit of a, you know, private better kind of session a few weeks ago with some of our customers because they've expressed interest in in this

5:02 topic, and we're like, oh, even better. You know, people that are already using our tooling would see additional value here. So let's let's invest some time and and build this thing and get it off the ground. Nice. I love how I started the conversation with you must have invested a serious amount of effort and people time and everything, and you're like, yeah. One person built it over a weekend. At least, you know, the proof of concept. It does all the best I can. Was the version. Yeah. And that was the alpha version zero, I think. But, yeah, I think now,

5:14 Early Community Excitement & Contributions

5:31 obviously, there's there's, you know, more parts of our engineering team involved. So let let's definitely give credit to to all of the folks that have contributed internally. And, yeah, most exciting thing is actually we've already seen the first you know, DevPod has this provider concept, and from Pulumi has, over the weekend, apparently, created a scale way provider for for DevPod. So we even see the first, like, bigger community contributions. It was super surprising. We made the repository public, I think, three or four hours before, you know, announcing it to the public just to make sure we test everything, upgrade procedures,

6:09 and how how all of that works with the public repository. And then we got the first pull request even before the press release. Like, dang it. Like, people are onto this. Nice. Alright. Well, obviously, with Rawkode Live, I'm gonna try and use DevPod. We're gonna work through what that process looks like and show people how to get started. But I have one more question before we do that if you're happy to answer it. And I'm curious. Right? Looking at the the loft portfolio of open source projects, you've got v cluster that I can run-in my Kubernetes clusters to facilitate virtual clusters

6:21 DevPod, DevSpace, and vCluster Relationship

6:41 for multiple use cases, which I think ties in quite nicely maybe with what we're gonna see with DevPod. And then we also have DevSpace, which also kind of is I don't know if it's tangential or not, but it's very close to what DevPod's doing and where it provides development environments for software to point to Kubernetes, maybe more. I'm not that familiar. So I'm curious about how do these work together? Is there a grand plan there to kinda take over that developer experience? Do I need to use all three? What does that look like? Yeah. That's a that's a very good question.

7:12 Actually, a lot of our community members who are already familiar with DevSpace, when we presented DevPod to them, they had that exact same question. Isn't there a lot of overlap here? Right? But DevPod is kind of under DevSpace. So DevSpace is the tool that deploys your containers to Kubernetes and creates this hot reloading workflow for these containers. Right? What DevPod does is it launches the environment to then start your IDE in. So it is a layer lower when you're thinking about what do I need to develop an an application. You know, you do need an IDE. You

7:51 do need a, you know, a linter. You don't need a debugger. You do need all these things locally, and we're trying to get rid of that by essentially moving that into a DevPod. So it's very, very likely that if you're working with Kubernetes and you love to work with DevSpace or another tool like Scaffold or, you know, any of these other tools out there, you would launch a DevPod, and then you launch DevSpace DevSpace from within that DevPod. That's how it would typically work together. But DevPod is a little broader than DevSpace because even if you don't if if Kubernetes

8:26 is not your target environment, you can launch a DevPod and work directly in there on top of, you know, Docker and without Kubernetes, right, which is something that DevSpace doesn't do at all. Nice. Alright. That makes sense to me, you know, especially even the tie in NV cluster where you give your developers the ability to provision virtual clusters and then, you know, big huge dev Kubernetes cluster where they can then have their dev pods where they run their DevSpace. I think I understand that flow. Think it makes sense. And I think it I mean, it's very interesting to me personally. One, I'm

8:40 Personal Use Case & Problems Solved

9:00 a developer advocate and I travel to a lot of events and I I travel with a MacBook Air. It's not slow, but for a dev environment, it's also not great. And also for the last what Yeah. Three years, I've had an m one or m two MacBook and I've gotta say, you I run into nothing but problems, especially compiling Go and Rust and, you know, I'm pulling container images which are only built for AMD sixty four and I'm pulling my head out going there has to be a better way. I can already see the draw to have a

9:28 tool like DevPod where I can get an environment. Now, you said you can run it locally and that's great, but I I think for me, I'm gonna be like, okay. I wanna spin up a scale way or an AWS instance. Use that as my DevBox and have it managed for me with the tools that I need. And I'm hoping that's what we're we're gonna see today. Yeah. That's a repeatability we're we're aiming we're aiming for with DevPod. Awesome. Alright. Shall we start having some fun? Yeah. I'm excited. I know you always take these tools apart, so I'm I'm really excited

9:50 Starting the DevPod Demo

10:00 to to see what you're doing with DevPod this time. Alright. Well, I've hopefully, you everyone can see my screen now. The website is available if people wanna check that out at devpod.sh. So go there for all the documentation, links to download DevPod, and link to the GitHub repository too. It's a nice website, you know. It's it's superficial things go. They're also important. It's nice when you have a developer tool that has a shiny website for people to kinda understand what the use case is. I'm not gonna spend any time on this. I just kinda wanna go straight to the documentation

10:19 DevPod UI: Providers and Workspaces

10:36 and see what we can do. Now, I did cheat a little bit mostly because I was curious last week and I wanted to see what DevPod was and I'm always curious to see when things prepared. I agree. So I I had installed DevPod, but I haven't done anything with it. So here we go. And this is our DevPod UI. Hold on. I haven't set up any providers except for I think I clicked the docker one, but that's where we are. But I'm assuming step one is DevPod doesn't do anything without one of those providers. So we need

11:08 to configure one or more so that we have the ability to create the developer environments. Correct? That's correct. Yes. Nice. Alright. Let's see. Yeah. I did add the Docker one. So I don't wanna use this, but I'm assuming it just runs containers and my Docker daemon, is Docker desktop. Right? Yeah. Okay. Yeah. Correct. Yeah. It just connects to your local Docker daemon to kinda spin up a, you know, DevPod as a container. And then I think it gives you access to the local Docker as well, so you can run Docker builds, etcetera, even inside that DevPod.

11:18 Docker Provider Explained

11:44 That's the idea behind it. If you use one of the other providers, there's providers that provision VMs. We call them machine providers. That would be like AWS or Google Cloud and and things like that where you actually spin up a VM. And then it would deploy Docker inside that VM and then stand up the DevPod agent inside that VM and then launch a DevPod container in there. So whether you're using the local Docker provider or one of the machine remote providers, we're always launching Docker inside of it and then always launching the DevPod as a container

12:23 essentially. Okay. That makes sense, I guess. So I guess we should show the local Docker one, which means I'll need to start Docker. Is there anything else in the UI that we need to kind of play with right now, or are we just gonna wait for Docker to start up and create our first workspace? Yeah. I think that should work. You can hit create workspace here. I think even while it's loading, we can explore what happens over here. Yeah. The first thing is you have to enter the source. Right? You either select a folder locally or you type in a git

12:25 Creating the First Workspace (Local Docker, Rust Detection)

12:59 repository, wherever you have a dev container JSON or something ready. And then on the right hand side, see links for, like, you know, Python or Node. Js, kind of quick starts. Microsoft has these quick starts for GitHub code spaces, and, you know, we are essentially using these examples without any modification to show people, hey, this is just like Codespaces. I should use the same definition. That's why it works out of the box. But works of any repository, essentially, especially if you have the dev container JSON configured out in there. Okay. So, I mean, what I did type

13:35 VS Code Integration & Remote Development

13:37 there was my Contrail project, but I don't believe we have a dev container JSON. No. We don't. Is that a problem? I actually think it may guess what There is a cargo.com. The right image would be. If that helps. I mean, we can we can always try it and and check it out if it works or not. Let's see. I always like to just see what happens. So hey. Look. I detected that. I know this is really small. I don't think I can zoom in on a Mac app, but at least I'm I don't know how to

14:13 do that. But it does say detective project language rust, and it is pulling down dev containers Rust latest. So I guess it work. I can't promise you that the application will actually launch in there because it's it just takes, like, a default, like, Rust image. Right? If you have a dev dev container JSON, you can obviously specify all of these things. But we're trying our best to kind of guess what you need. That's the that's the approach here. Yeah. I think this might work. It also says it's downloading Versus Code. So this is now open my local Versus

14:47 Code, and it's setting up SSH remote container session. Yeah. Correct. Yeah. It it essentially created that DevPod inside the container, and then it connected you to that via SSH. You see that on the left bottom corner that it says the SSH connection there. Yep. Nice. So I'm well, I don't have my macros, but that's okay. That's probably my fault. I don't know how to type. There we go. So this is yeah. Linux machine. And because it's local desktop, we're getting AMD sixty four. And in theory, I should just be able to run a cargo build. Right?

15:34 Yeah. Fingers crossed. Well, I can actually already see that I have Rust analyzer in my Versus code, and it's actually kind of doing all the fetch and stuff at the moment. So we'll give that a second. So maybe we can dive into actually what kind of happened here. So we added a new workspace to DevPod. We now have this thing where I can just open it. That's there forever now. Right? Even if I close this, I can assume it. I can just restart this whenever I want. Yeah. Open is just gonna reconnect the IDE, right, to this environment.

15:46 Alternative IDEs & Browser Access (VS Code in Browser)

16:05 And if you hit the three little dots, you also see it says, like, start with, which essentially lets you open it with other IDEs in case like, the default one you selected for your Docker provider was Docker desktop sorry, Versus Code on the desktop. But you could also save Versus Code in a browser, and then it would just connect you to that one. Yeah. I'm gonna try it. It's got a light color theme by default. I'm not sure how I feel about that, but that's Versus Code's problem, not yours. Yeah. Here we go. This is neat.

16:40 See, I I went through a little phase of trying just, like, to work from a Chromebook for so long and could never get it to work. And it feels like this may have been the missing thing that I needed, like, Versus Code browser support at a remote container with the tools that I need. That would've been pretty cool. Yeah. I mean, you won't believe it, but one of the first issues that were opened were, like, can you support iPads as well? And we're, like, dang it. Now we gotta create an iPad app for this. People do love like, I the amount of

17:10 times I see people with their iPads at conferences and they've got a little keyboard on it which I I have tried so hard to be able to type on is impossible. But they do seem to use like a a web based Versus code and and try to do stuff. So, yeah. Yeah. Alright. Not not for me. Don't they have the I'm not sure if they have, like, a keyboard you can attach with the iPads as well, like, you know, like the Surface ones have for Microsoft. I thought you well, there's just MagSafe attachment, but it does give you a USB c

17:41 slot. You can go nuts, I suppose. Oh, okay. Alright. So that's, you know, that's kinda cool. We're now building our application. It looks like it's gonna build because it's 75% through, and we didn't get an error from Versus Code to see that the rust I know how your build failed. So I'm assuming in a few moments, we all have went from zero tooling to an IDE with rust support and an application that compiles. Well, I think that's pretty cool. But the UI is not the only way to do this. Right? When I was in the settings,

18:06 DevPod CLI Exploration

18:15 I did see add CLI to path and I've got a green tech which means I have the CLI. So I'm assuming if I want to, I don't really need to work with the UI at all. Yeah. Actually, what the UI does under the hood, whenever you click any kind of button to create something, it actually just runs the CLI command under the hood. The adding to your path is really just more of a convenience thing, so you can also access the CLI directly. But, yeah, every everything ties back to a CLI command under the hood.

18:47 Okay. Fill up my CLI. Alright. So I can just do that. There we go. Cool. So shall we try a different provider? Yeah. I can see the the help page. So I know I should probably be, like, going through your get started, guys. I'm trying to be a bit more pragmatic here, but I also just wanted to play with it. So, we're kinda seeing the browser, and we've seen Versus code. I I don't use any of these other things. I'm not that fast. So let's see if we can manage some providers. Oh, I'm just seeing we do have a

19:32 Vim quick start because that was another question that came up in a in a previous livestream, and I'm like, I don't know how to connect this to Vim. Like, oh, I guess we have a quick start for that as well. Vim? Which I guess makes sense. Like, if you scroll down, it probably just says, like, connect via SSH and then Yes. Yeah. That's Aliases. Right? Is is that integration to to connect to it. I'm curious if that's modified my SSH config or my, yeah, I guess it has done probably. I guess we'll find out when I spin

20:15 up a remote provider because it probably won't do anything if I don't have one. So let's see if we can get that working. In fact, for the build. Ah, close. What did I miss? I'm sure I've got some oh, I probably have like an open SSL dependency or something that's needed. So let's close that for now. So DevPod list, DevPods dot, I suppose. Mhmm. Cool. Alright. DevPod provider add. And then Yeah. You'd essentially so, typically, you need the provider specified in, you know, some kind of repository. I think there are default providers. You can see that here, like, at docker

20:23 Adding Cloud Providers (GCP, ScaleWay)

21:13 and at AWS. Right? That's, the default providers. But you could also point it at a repository or at a YAML file like the scale web provider that Engen wrote, and then it would essentially pull the specification from there. Okay. If you in this provider, if you go to the, like, the gcloud, like, we just map gcloud to the actual repository. Right? If you look at the releases here on the right hand side, you see that there's one release of this provider. And in that provider, in the assets, if you scroll down, I think yeah. If you click show all

21:59 assets, it should share provider YAML. That's essentially the file that specifies how this provider is being run within DevPod. Okay. So Yeah. It's like, like, the name, the version. Right? And then a whole bunch of commands, available options, like, region, etcetera. Like, everything that you've seen in the in the UI, when there's a drop down show you, you know, which region you can select, right, it essentially comes from this provider YAML file. Okay. Well, I'm gonna very quickly off screen in another window, make sure my Google Cloud is authenticated against the correct account, not one of my customers' accounts,

22:36 Provider Authentication (Using Existing CLIs)

22:46 and then I'll add the provider. But I seen why am I doing this? Because I seen when we were here that it said, be aware authentication is tangent obtain just in the g cloud CLI. And so I just wanna make sure that Yes. I'm on the right account before I do anything terrible. And my customers Yeah. There's two options to authenticate it. I think the the safest and the default option is to just use g cloud CLI because, you know, whatever your authentication mechanism is with Google Cloud, it has it in your, you know, in your key chain or in

23:24 your in your, you know, Microsoft store that they have for Windows. Yep. So all that is safe, but you can also provide it with, you know, service account token and things like that if you would wanna specifically do that. But you we typically recommend just authenticate with the AWS CLI, g cloud CLI, and then the DevPod CLI will essentially call that other CLI. Yeah. Yeah. That makes sense to me. So let's do DevPod provider ad. Let's pull in a provider, and I have a project called Rawkode Academy. I'm done. So I do a list. Yeah. Okay. So Docker is set to the

24:13 default and from the docs we see Actually, it made Google Cloud your default. Yeah. So in the CLI, I think it yeah. It it does the latest one as as default. If you do it in the UI, there's a little checkbox that is, like, default checked, and you can uncheck it. That would set the false flag for this one. Oh, yeah. Yeah. If you click on add provider, you'll see that as well. It's kind of funny in the UI when you click add provider, just click on one of them. It's now loading the provider YAML.

24:46 That's why it takes like a second. Right? If you switch to another one, it will load again for just a second because it always pulls it live from from GitHub. Oh, so you have the ability to really tweak and modify this without having to push updates to desktop applications all the time. That's pretty neat. Exactly. That is the whole idea. And if you click on this plus symbol there, that's the way to add your custom providers. So you can write a provider, put it in a git repository, and it will essentially pull it from there.

25:12 Custom Providers & Provider YAML

25:13 Alright. Well, let's find Angen. Yeah. That's choice provider. I I don't know. Do you have a scale account? I do have a scale account. So Oh, nice. DevPod provider scale. So how much code is that? I mean, seven commits. I'm assuming He actually went the fancy route. So the simple route is to just have a provider YAML file that then just, like, literally has, like, batch commands in it, right, to call, like, g cloud, you know, create a VM, etcetera, right, via the CLI. But he went the fancy route by actually making it a Golang based provider. So I

25:53 was, like, super impressed when I opened this up, and I'm like, oh, wow. This is legit. Alright. So while I add this provider, we do have a question from Russell at the chat, so let me pop that up. Russell is asking that he's in a reference to open Versus code, And he's curious if that is the one the real code, but the open source one without the Microsoft metrics. And if so, do you have custom config as the last time he tried to use code OSS and needed a flag to enable it to connect to dev containers.

26:28 Does that make sense? That's why I think With the regular yeah. I think the regular Versus code you run on your desktop, I I haven't tried it with code OSS, just with the regular Versus code. But I think what you are aiming at is, like, the browser based version. Because I think we got an issue about this as well a couple of days ago where folks have requested for us to use, like, the, you know, the the non open source version in the browser. Because they are apparently, I didn't know that either before the issue was

27:01 open, that there are differences between the pure open source Versus code, and, apparently, there's some other version of it. And we run the pure open source one in the browser apparently. But locally, it's whatever you have in your, you know, whatever your Versus code says when when you have it in the path. Right? Yeah. Actually, I think there is some weird things with the open source one. I don't think you can access to a lot of the extensions because it uses a different extension marketplace rather than the official Versus Code one. But I don't know if that's changed. There's

27:31 been a while since I looked into that. Okay. Let's add this provider. So click go. Oh, he's broke it. His provider dot YAML seems to be incorrect. Is that expected? Interesting. Maybe we have to point it. Oh, yeah. Can you just do the release asset? Yeah. Maybe we need that. Copy a link to the provider dot YAML? I think so. Oh, yeah. So it can either be a URL or a local path to provider file. Or okay. So maybe actually, what I should have done is just do this. Yeah. There we go. Oh, perfect. Alright. So we could add some scale away

28:30 Creating a Cloud Workspace (GCP VM)

28:31 credentials here, but I have already configured my Google account. So let's let's go with that make my life a little bit easier for today. So now we need a project. Let's pick one of those ones that were the example ones with the dev container dot JSON. So do you have a a language of choice? Oh, it seems like you're a Rust fan. I'm not an expert, though. Yeah. Let's do it. Alright. The UI is, like, the the desktop project is written in Rust as well as far as I as I know. I actually I I was

29:13 very nosy, and I went to look at the code. And I've seen issues in Tauri, which is Yeah. This really cool framework for building desktop applications with, like, a Rust tool chain underneath it. So, yeah, I was very excited to see that. I think it's awesome. Okay. Yeah. I was a little skeptical in the beginning when the engineering team suggested that because there's other, like, more, I guess, mature frameworks at this point. But I'm super happy with with the result and, like, the team said it was, like, a lot of fun to this. And they have a lot of

29:42 cool features, like, regarding, like, auto updates and things like that baked in. Seems to be a very, very smooth experience. Yeah. Definitely. It seems to be gaining quite a lot of momentum too. I think a lot of people are are struggling with Electron these days because, like, the overhead of running electron apps is just getting worse and worse. I'm not sure how Versus code Yeah. To keep their editors snappy, but I don't I don't I I struggle with electron apps these days. So Tari seems to be a pretty good approach. Plus, because it's written in Rust, you can actually use WebAssembly

30:11 plug in models as well, which just makes it even cooler. So yeah. Very cool project. Alright. Now the team was really proud of, like, getting the size down. And I think it's, like, under 30 megabytes now to download DevPod, and it's quite slim. Wow. Some of the command line applications I build are bigger than that. So that's great. So this right now is creating a VM on Google Cloud. Right? So I'm assuming this may take just a few seconds. And I'm assuming, please correct me if I'm wrong, that you're just stuffing a whole bunch of user data into, like, the cloud config

30:33 DevPod Architecture (Agent, Docker-in-VM, SSH)

30:56 of some kinds to kinda boot that bootstrap it, get it to a point where it can function. Yeah. So we have this DevPod agent that gets injected into the VM, and then we launch docker inside the or install docker within the VM. And then we launch the container that you're then connecting to inside that VM as well. And we essentially connect through that DevPod agent to that container. That's like essentially giving us just like SSH connection to the machine and then to the container that runs on that machine. And how's the authentication handled between that agent

31:34 Authentication Details

31:36 and my local machine? I think that's such a, a SSH keypad that gets generated locally. And we, like, we inject that into the VM, right, with the with the agent. Okay. And then regular, you know, I think the first, like, connecting with the machine is just like regular g cloud commands or, like, we're using, I think, the four four g cloud and AWS, etcetera. We're not, like, having to call the CLI directly. I think we kind of use their client libraries under the hood or a mix of both, whatever is available. Like, Kubernetes, obviously, you know,

32:16 GoClient, etcetera, just connects to it. Cool. Well, let's let's dig a little deeper on this. Right? So it's it's just my local Versus Code, which I love. Right? Browser ones are fine, but I spent a lot of time crafting my config and my extensions for Versus Code. That's a really strong I'm I'm happy with this. I could open this terminal here, and I can do cargo run, and we should see hello world. Right? But I gotta be honest. I do hate this terminal in Versus Code. Can I do, a DevPod SSH? Is that a thing?

32:21 Accessing the Host VM vs. Container

32:53 What do mean DevPod SSH? Alright. Well well. Like, can I just can I use my own terminal? Oh, you mean, like, outside in your terminal? Yeah. Yeah. Yeah. That would be the that would be the VIM extension. Right? To do it that way. Obviously, it's just because the VIM extension said in fact, let's split this. Right? Because the VIM extension told me to do SSH workspace demo dot DevPod, which also works, which is also very cool. Right? I'm assuming I didn't really wanna show my SSH config, but it should be okay, I think. I'm assuming something's just yeah. You're just injecting something.

33:39 Yeah. It's just being added. Correct. Okay. Good. And there's the SSH keys, so we can actually see how that authentication is handled and there's a DevPod directory with the keys available. So that's pretty neat. But this is this this to me is the ideal workflow. Right? I've got what is now a Linux machine AMD sixty four. We've got three cores and 16 gig of RAM. Not bad. I'm hoping we can tweak that. And I've got my own Versus code with my own extensions. I can have been in the terrible terminal and just work the way that I want.

34:12 So that means I can say hello from Linux. And now my days of problems oh, I didn't put into the right word there. Where would my app be? Let's let's see. Workspace is Rust demo. Now we could do cargo run. I know my days of having problems with my m two Mac and pulling containers and stuff. And you told me this gives me a Docker daemon. Oh, it doesn't. Okay. Yeah. I'm not sure if you actually have access from in here. Because I'm in a container, right, rather than being Yes. On the host. But you can I

34:55 I think with g cloud, you could go into the VM directly, and you would essentially see it there? Yeah. I wonder if there's a call for maybe having a flag, like DevPod SSH where I do Rust demo, but I see dash dash host or something. Yeah. There's actually a command because we had to debug something. Let me try to open the help page. Actually, go into the machine. We have a helper command for this as well. Oh, there was a DevPod machine command. Right? Yeah. Yeah. Yeah. You can run DevPod machine SSH, and that will drop you into the machine.

35:34 Yeah. That's what I was looking for. Well, the machine name is different. So let's do a list. Oh, no. I don't have machines. Yeah. The machine name, that's something really So it created one VM right now, and you saw that took, like, about a minute or so to create that VM. And, obviously, that's something we can't change. Right? It always gonna take some time to start a VM. So what we're actually doing is by default, we're reusing the machine for different DevPods. Right? So you can have multiple workspaces. And as long as you both if you're

36:06 using the Google Cloud provider again for another workspace, it will create a second container on that very same machine. So the machine is shared by default. Okay. So yeah. There were two things interesting here. One, I was already in the machine and I ran DevPod machine. So DevPod was available inside the machine, which is cool. But when I came off of it, I then was able to DevPod machine SSH onto the Rust demo one, and I know I can run Docker commands to see that. But I guess this is gonna be really good for most workflows unless one of my

36:44 workflows says I wanna build Docker container images. Mhmm. And I guess maybe there's a different dev container set up for doing something like that. But I guess that's not terribly important for right now. But I do like that I have access to the machine. This is a this is a three core six hyper threaded machine with 16 gig of RAM. Do I get to configure that? Yeah. So in the if you open the UI real quick, you'll see that you can configure the provider. And, you know, it's just essentially defined in the yeah. If you hit that edit button there.

37:09 Configuring Provider Options (VM Size, Reuse Machine)

37:25 Ah. And there you can define the machine. Right now, we have this only for the provider, but what we actually wanna allow you to do is change it for the workspaces as well. And you see on the bottom, actually, the reuse machine right now is not checked. So you would always create a new machine. If you have the reuse machine, the second workspace would be using the same same machine again. Ah, got it. Yeah. So I guess if I you say we used and configured us to be like a, you know, n two standard 16, which is

38:00 probably I'm not sure off the top of my head, but probably a decent size machine. I could reuse that for multiple projects and always get the create that Correct. Yeah. You can also expand these, like, agent options there, if you go back to that screen. And that's where you can see things like inject docker credentials and check grid credentials, etcetera, you know. And there's probably more options to come. That's essentially what that agent that lives on the VM is gonna inject into the respective containers. Ah, so it's gonna consume my local docker and get credentials and put them. Alright. Okay.

38:34 Got it. How does it know if it's inactive? Like, if I quit the GUI, does it still does the inactivity kill? Or Yeah. Yeah. So that's really interesting. The inactivity is actually managed by the agent that that is running on the VM. So what you're doing when you're SSH ing is you're connecting to that agent. Right? So that agent sees all the SSH connections to the machine or to the workspaces on the machine, and it essentially sees when there are no connections. And that's what this timeout is. So if you would, you know, throw your laptop out

38:38 Inactivity Timeout & Cost Savings

39:10 of the window now, right, there's nothing running and no connection, nothing needs to be client side, right, Then five minutes later, the agent would still it turns itself off. Right? It turns the machine off that it's running on, basically. That's what it does. Nice. So it's it's yeah. It's like a pulse or some sort of health check. And if we're not checking in to see that we're doing something on that machine, it's just gonna stop itself, which I guess is good if you do start using some of the chunky hardware. It's like the prices get wildly

39:38 expensive. So Yeah. And I think that's a core benefit of of DevPod. Right? We we actively wanna encourage people to have machines in different environments. Right? You can have, as I said, one in, like, your local minikube or your local docker, and, you know, you can run simple things there. And then if you need to do, like, your integration tests or an end to end test or, you know, something more complex, work on, like, real data, then you're just connecting to your AWS provider. But then you switch back to Docker again, you know, three hours later, and we don't

40:10 want you to have to manually, like, remember, oh, I forgot to pause this. It ran overnight. You know, that kind of thing. That's why we added that automation there. Nice. We have another question from Russell in the chat, so I'm gonna pop that up. But Russell is asking if it's possible to share or reuse those machines across multiple people within the team or if it's local to the single user. I guess you could, but I would not recommend it, to be honest. Because what we're doing like you saw, you can SSH into the machine. Right? And if we're injecting your

40:20 Sharing Machines Across Teams (Security)

40:42 Git credentials and things like that into the machine, right, it's probably not ideal to to to share those kind of secrets. Yeah. Good call. So I think there's nothing that would stop you, right, except for your security team, I guess. Yeah. Well, most organizations are unfortunate enough to have a security team. So it's alright. I don't know if that's fortunate or unfortunate. I guess it goes either way depending on where your where your concerns lie. This is a pretty cool project. I I can see myself using this. I mean, obviously, I'm gonna have to go write

41:12 Provider Ecosystem & Smaller Clouds

41:19 an Equinix metal provider now so that I can get some chunky mail and start using this for all of my machines. But I I definitely I really understand and appreciate the value proposition. I like the pluggable provider model. It's very configurable. And if I can write an Equinix mail provider with just some YAML, then good. I don't know if I've I'm gonna go down the the complicated smart route like Angen did, but, you know, it's nice to have an option, I suppose. Yeah. For sure. Yeah. We were actually you know, after we saw that that gateway provider,

41:50 we were like, hey. We should have some kind of live session where someone codes and provide it in an hour or something like that, you know, when we just stream it. Because it's relatively easy, and there there have been requests for, you know, OVH and and Hetzner and all of these, like, you know, smaller cloud providers. And I I think that's the beauty of DevPod. Right? You're not restricted to to these big environments. You're not restricted to us creating this for you. You can just create it whenever whenever you need it. Yeah. Definitely. I think we're in a quite

42:21 I don't know if it's a fortunate time, but, you know, there are a lot of these smaller cloud providers whose pricing is getting very competitive. And it was opens up even to smaller teams, the ability to have these remote dev environments and kind of give their developer teams a bit more velocity and, you know, the tooling that they need and the hardware that they need without having to ship them a new laptop every twelve months or whatever. So it's it's definitely interesting time. I'm looking at the Absolutely. I think even even us, I mean, we're we're we just

42:49 looked at the prices for, like, using it internally. Right? And we're like, why wouldn't we use one of the cheaper cloud providers? Right? Like, our dev environments don't need to be in AWS because they typically they cost, like, three times as much as as one of the local providers, and and it just works the same way. Yeah. For sure. Alright. Well, that's awesome. I love this project. Thank you for coming on and and kinda walking us through it. Is there before we finish, is there anything that we haven't covered that you think would be good to show

43:07 IDE Standards & DevContainer.json

43:16 to the audience? I think there's a whole bunch more settings, but I think people will probably explore them. I think, you know, by clicking through the UI, things things usually get a lot lot lot easier to kind of find out what's what's going on. I think one thing I haven't tried out myself is working with the IntelliJ suite. So I gotta I gotta try that, you know, the JetBrains IDs. I'm not sure if if it seems like you have Versus Code guy as well. Yeah. I've I I really I have a rule about not running Java on any of

43:49 my machines, so that rules out the entire IntelliJ project. I'm I'm not frustrated with Versus Code, but, you know, I always keep my eyes on upcoming editors. So you'll see that when I'm on the the CLI, I do use Helix, which I think is really interesting alternative to them. And I've been keeping a close eye on Zed as well, but I don't think they have any support for this sort of dev container workflow. So yeah. It'd probably be Versus code for me for the foreseeable future, but always hoping to find a new cool project. And I actually think Zed uses Tauri as

44:23 well, the Rust desktop framework underneath the hood. Oh, cool. Yeah. I think given the, you know, I think DevContainer. Json as a as a open source kind of standard that Microsoft wants to to push, I think pretty much any anyone building an IDE or, you know, even doing some in browser things. Right? They essentially will look at that standard and try to kind of comply with it or have this, like, SSH capability that is required to to then connect to these dev container environments. I think that's a that's something we're banking on. Right? That this

44:57 this will be the standard, and I'm quite hopeful that we don't have, like I think right now, there's, like, five or six, like, different competing standards, And we we looked at the space and, you know, I we can implement other, you know, standards as well if as long as it opens to us, of course. But DevContainer was already there and it's in you know, it's GitHub pushing it and make it so easy for you to add it to a repository so that we were like, okay. This is the first one that we wanna build on.

45:25 But I can also see us build on on other different standards there as well and kind of be like the glue between the IDE, the cloud provider, and that essentially workspace definition that lives in your Git repository. That's really the three things we're trying to get together here. Yeah. I think a really interest in approach. Not that I wanna fill up your feature backlog by any means, but if if you can detect in the absence of, like, a Versus code dev container dot JSON, if there was, like, a a shell dot next, you know, next is still a

45:30 Potential Future Integrations (Nix)

45:57 very it's not popular, but it's a very good tool for building development environments. And if you could just bootstrap a machine with the Next system and then create a Next shell with that, that would be a very interesting idea for me. And I think Next is getting a bit more popularity especially in the container space as people are looking for tools to build container images that aren't necessarily Docker in the Docker file. And Next seems to be a bit of a rising contender there too. But that's that's a segue Yeah. Definitely saw some some requests

46:26 "Open in DevPod" Button

46:26 in that direction on the on Twitter as well once we, you know, once we launch DevPod. Oh, there's one more thing I wanted to mention. If you wanna make it like, if you're, like, a open source maintainer like we are and you wanna make it super easy for people to open a project with DevPod, we also have this, like, open in DevPod button, you know, where we register, like, the DevPod protocol. Right? So you have this, like, DevPod link that kind of, like, Zoom opens up your the application and have has everything prefilled. The only thing you need to have is

46:57 DevPod installed and at least one provider to kind of, you know, spin that environment up. And then we hope that will be, you know, happening in more and more repositories that these links get added as long as there is, like, a, you know, a dev container JSON file in there. Or even if not, as we've seen, right, it may work, but it may require some tweaking of chunks to get the to get the project to actually build. Nice. That's something really, really cool we added right from the start too. Yeah. That's a nice touch. It just kinda makes it a

47:25 Post-Launch Reaction & Community Engagement

47:27 lot easier for people, especially if you go to that read me of a project and you're considering, well, maybe I'll clone this and see if I can build it and do some hacking on it. Like, just that one click button to get that environment that you know is guaranteed to work is, yeah, a very strong selling point. Let's finish If you wanna contribute to DevPod, there's a button there as well. So definitely encouraging folks to do that. Sweet. Let's finish with a a couple of questions then and then I'll let you go and enjoy the rest of your day.

47:58 But you lost just a week ago. What is the response been like? Are are people happy? You already mentioned someone maybe talked about next on Twitter. Just tell me about what you've seen from the people that have been reacting to the story. Yeah. We've definitely seen a lot of, I think, you know, positive responses. I think the you know, when I compare to the vCosta launch, I think vCosta obviously being a much more narrow project with Kubernetes multitenancy. Right? It took way long to get that kind of, like, I guess, virality that DevPod already got within a couple of days. I mean,

48:35 it's been, like, pretty much exactly one week at this point since since launching it. And, you know, there's, like, over 800 GitHub stars. We were in we ran GitHub trending. There were a couple of, you know, threats on Hacker News and on Reddit going on that were very, very vibrant. And, yeah, I think the the biggest thing for us was see that people already contribute to the project. Right? There have been, like, quite a few pull requests, quite a bit of issues open up. We fixed a lot of bug. Apologies to all the Linux users who tried it initially

49:10 because, apparently, the desktop app just showed a white window when you open it up on Linux. I guess we could have tested that better. But we got that fixed in the first two days as well. So I think very, very exciting to see a lot of people just, like, get hands on experience with it, you know, because I think a lot of projects, you know, people may find it interesting. They they give it a GitHub star, and that may not actually try it. But given that we've seen these error reports and feature requests, we know that people actually gave it a

49:37 shot and found some bugs or, you know, really liked the project and and gave us that feedback. And ton ton of people joined on on Slack as well. We have a Slack channel on Slack.love.sh, not just for DevPod, but for all of our projects. Yep. And there's some vibrant discussions on vCosta, but I didn't expect the DevPod Slack channel to have such a, you know, like a lot of discussions going on, like, three days in or so. That was kinda crazy to see. Awesome. Alright. Well, last question then. It's like, I know you're on the weekend. It's probably

50:05 DevPod Roadmap & Future Plans

50:11 a difficult one, but what what's next? What's on the road map for DevPod? What do you expect to be shipping feature wise in the next, you know, six weeks, six months? Do you have an idea what the future holds? Yeah. I think the biggest thing that I really wanna prioritize pretty highly is these, like, making these, you know, provider options available on the workspace. Like you said earlier, hey. For this one, I want a separate machine with more CPU. Right? Right now, you kind of have to always, like, modify the provider before you create a workspace. It's a little

50:44 bit of, like, a you know, you know, the UX could be better on that end, and I think that's I think that's definitely a high priority among a whole bunch of other UX base where just people told us, oh, I gotta click five times here and run this command to make this this work. Couldn't this be easier? I think fleshing out these things will be will be a pretty high priority going forward. And then, obviously, adding more and more providers. I think we've had a lot of requests for, like, hey. I want, you know, to make this work in Hetzner, etcetera.

51:15 Right? So we're planning to have these sessions where we just, you know, actively do that with the team just like stream while we're coding it. Maybe ideally get someone from on the team or, you know, from Equinix on the team or someone who wants to participate in that session. And then, you know, that will hopefully show more and more people how to create these providers themselves as well, and that would be a lot of fun. Awesome. Alright. Well, thank you again for joining me. DevPod looks like a a really cool tool. I'm looking forward to trying I'm definitely going

51:36 Conclusion & Final Remarks

51:44 to be working on the Equinix metal provider so that I can test that out and kick the tires on it. But I I just say thank you again. It's been fun. And, hopefully, I'll see you again soon. Yeah. Awesome. It was great. I'll be in on the show again, David. A pleasure is all mine. Thank you very much, Lucas. Alright. See you. Thanks a lot. Bye. Thank you for watching Rawkode Live.