0:00 Intro Music

0:00 Welcome to the journey so grand. Lines of code we start to weave. In this world, we do believe Daytona shining through the night. Local magic, pure delight. Ivan's wisdom lights the path. Steering clear of coding wrath with this Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, also known across the Internet as Rawkode. Today, we continue our Rawkode live series where we take a look at future facing cloud native technologies to simplify your cloud native journey. Today is no exception. We are joining the well, blah. Let me try and find the words. I am being joined by the

3:02 Welcome & Introduction

3:21 Daytona team to take a look at simplifying your development environments. Joining us today is Ivan. Hey, man. How's it going? Pretty good. Thank you. Great to have you. It's always fun to have these, what, blurbs in the video so people know it's, like, real. It's not prerecorded. So, like, everything that we're doing is live. Everything that we screw up, you know, it happens. It's like so it's great. I was just talking when we were, before we got live, it's like, I do, like, a demo a day at least. And then I was, like, at a huge conference.

3:54 A thousand people are watching, and my demo broke. So, you know, it is what it is. So it's live. So welcome, everyone. Super happy to be here. Yeah. As as said previously, I've done over 432 of these, and there's probably 900 errors at least. So those those those are really making fun. Anyway, for anyone who's not familiar, let's start with you. Can you give us a little bit of information on who you are and what you've been up to? Sure. My name is Ivan, cofounder and CEO of Daytona. Did a bunch of things in my career.

4:13 Guest Introduction: Ivan from Daytona

4:25 Probably what's relevant to the conversation that we're having right now is that the cofounding team of of Daytona, which is about fifteen months old now, was also the cofounding team of Code Anywhere. So Code Anywhere was the, as far as I fact checked, I always say this a bit, the very first browser based IDE ever in the world. And so we did that in 02/2009 before there was web two point o. Just to be clear, there was no, like there was no nothing you could really do in the browser then. It was basically a white notepad and FTP server and whatnot FTP

4:58 connector. As WebPoint two came out, we could do syntax highlighting and all these things in the browser. So we sort of were the first that started this whole journey into bringing, you know, dev environments off the local host or, let's say, at least trying to simplify them least successful before, hopefully, more successful this time around? Yeah. I mean, I think that's really important. I mean, if we look at the landscape today and cloud native development with microservices and, you know, polyglot runtimes and languages and our services and databases from every other new startup vendor, like,

5:21 The Challenge of Modern Dev Environments

5:35 local environments is probably in fact, they're not possible anymore, you know, depending on what magic people are trying to work out. But I think cloud based environments are where we need to be, and I'm hoping that we can show people a really good way to do that today. Yeah. I mean, it so so I was just gonna add on that, though, like, I feel that history has changed quite a bit. I mean, back in the day there's back back in the day. But, like, back in my day, we used IDEs, and the name basically meant integrated dev environment

6:02 because you had, like, Eclipse or IntelliJ or Visual Studio and installed everything on there. And when you wrote code, you hit run, it worked because it had all the dependencies that you needed there for the most part. Whereas, like, fast forward today, because of everything we've done, microservices and whatnot, like, you can't do these things or you can't have a prepackaged IDE for that. So, basically, we mostly most of us use Versus Code, which is just a text editor on steroids. And now the complexities of setting up the dev environment is off on you or us

6:35 or me and whatnot. And so we're hoping with Daytona to get a bit of that feel and magic back where it's, like, as simple as it can be, and you just focus on the coding and let, you know, offset all the dependencies to someone else. Nice. I mean, I'm sold already. But, anyway, we should still do the demo, I think. Now I've got some questions for you, but I'm gonna let Kanal head in first because he beat me to the punch, and it's relevant to what you said. He wants to know what conference you're going to next.

6:47 Audience Questions & Developer Preferences

7:01 So what conference? I have not booked conferences. So to be fair, the last conference I was at was shift shift in Croatia because I found that one. It's not mine anymore, but I found it. So I went. And there's so many conferences to go to, and I'm basically a conference junkie. It's just, like, trying to eat heads down. That means for CubeCon, though. Come on. Right? You go to CubeCon? Exactly. I was gonna say, like, I'll probably show up at CubeCon. Like, I might not we're not gonna do anything, but I'll land and, like, hang out.

7:30 So, I'll see you at CubeCon most likely. Yeah. Nice. Alright. What's your favorite programming language? Not to put you on the spot, but I'm putting you on the spot. Yeah. You're putting me on the spot. So what I'll answer this in a specific way. I'll say Daytona uses Go. And The cloud data quality is to just give you a tick. So Yeah. So we use Go. This is for the open source product. And for now, it's just a CLI tool. So everything's written in Go. It's just, one language. Go is super easy or, you know, as can be, and it let

8:06 us lets us it's a standard in or very commonly used in cloud native products or services that you'd find. So the type of person that will hopefully contribute or whatnot is already very familiar, and it lets us do a lot of things on the hardware level, which we have to manipulate to have these dev environments. So that's my answer, and I'll keep it at that. Alright. I mean, most people are used to me saying Rust 15,000 times in every episode, and I'm a big fan. But I I've gotta be honest. I've been playing a lot

8:36 with Zeke lately, and there's a lot there too. So I mean, a lot of people when when they ask me this is like, well, like, Rust, like, why aren't you guys using it and whatnot? And then it's like, I'll I'll go back to my old answer, but, like, yeah, I don't wanna open up that can. It's definitely a thousand paper cuts. I love what Rust gives you, but I've I always feel like I'm like, why is this the key? Why do I need to jump through all of these hoops just to do that thing? And, of course, it's because it's,

9:01 you know, all these data risk protections and memory safety. Sometimes I just wanna get stuff done. Anyway, I'm not getting into a rant today. That's not that's for another time. Alright. We've heard about you. You're maybe gonna go to KubeCon at least for a beer or two. What is Daytona? So Daytona is a dev we call it a dev environment manager. Some people use the term CDE, so cloud dev environment. But for us, specifically, when we're thinking about Daytona and how to build it and why we actually got that, that's a whole interesting story in itself, how we decided to build

9:11 What is Daytona?

9:38 this thing out. But when we did do our research before actually forming a company, we looked at I researched at everyone that had mentioned remote dev environment or CDE on the Internet. And so there's, this huge notion table with, like, all these people. There's, like, 500 people on the list. And from there, you'll have, like, investors and founders and, you know, users, engineering managers, whatnot. And what I also found from that is engineers that have built or are working on a similar product inside of their own company because there's not people say if you search, like,

10:15 cloud development, there's a bunch of vendors. Yes. Maybe. But actually to solve a problem for a large enterprise are very, very few. I'd say, like, maybe one. And so a lot of these companies had to build it, and that was interesting because I found that, you know, obviously, Google, Meta, Shopify, LinkedIn, Stripe, Palantir, like, all these companies have built something similar internally, and I wanted to figure out, like, why what's what has been the reason, for that. And so I reach out to these people. Half of them, like, reply, and half of them, you know, have a call

10:47 like this with me. And I asked them, what are you building? What is the problem that you're solving? How many people are building it? Do the developers like it? And I found that some companies mandate it because of security reasons. Like, everyone has to use these standardized dev environments, be it local, remote, whatever. And the ones that don't, like, it's not a it's not mandated by the company, but you can choose to use it and choose not to use it. 80% and this has been consistent of all these kind 80% of developers actually use it.

11:20 So I was like, oh, this is awesome. Like, developers like this thing, and enterprises are building this. The teams that are building it are anywhere from four people to, like, 30 people. So it's not an insignificant amount of cost of headcount that's actually building these things, which was, like, super for us. But what I was gonna get to is the the most interesting one for me was Shopify. And so the person that I talked to at Shopify told me the story about how they got to these dev environment standard standardized remote dev environments. And so they started first with standardizing the

11:53 local dev environments. And so what they would do is before if you were new hire, they the engineering team or they his team would take the laptop, and then they'd install, configure everything for you so that when it was your first day of work, you can contribute to day one on day one because everything was, like, set up for you, which was, like, pretty cool, especially when you have lots of developers. And what they noticed is that and this is his words, not mine, that at one point, the cables connected to laptops were starting to melt because of the size

12:24 of these machines that they had to now spin up and run. And so I it's in one of my pitch decks. It's like, you know, this person said that. And so they had to go out and build these remote dev environment systems because, you know, other the only way to do it now is, here's an EC two and go figure out how you're gonna get this up and running. And so they had to rebuild this whole automation that they had on the local machine, and they did it for the for the remote. And halfway building it, they figured out, oh,

12:48 we've already done this before. And, basically, what they created the the output was what a developer sees now is they have the CLI tool, and I don't know the exact command, so don't don't don't hold me to this. But it's basically like create dev environment remote or create dev dev environment local. Like, it is the same flow for an engineer to spin it up on their local machine as it is to spin it up on the remote machine. So you as developer don't have any difference. Like, if you're doing, a front end app, super small, super quick, whatever,

13:18 you're gonna do a local host. You don't care. But if it's, like, something large, you know, have a bunch of services or whatever it may be, or, like, I'm just trying trying to help you out, and I don't wanna shut off my dev environment at my machine. I can just spin this up automatically. And what they built was basically the foundation of what or our first principle of Daytona. It is a lot of these companies create their solution is a cloud remote dev environment for everything. Our thought process is we want all dev environments, and dev environments

13:47 are, like, as we mentioned, being made, they're all over the place. People have different configurations, setups, locations. Sometimes it's on a box in their, you know, in their basement. Sometimes it's on an e c two. Sometimes it's on a laptop. It can be everywhere. Can we unify all this so it always feels the same for you? And that is the principle of what Daytona is. So the idea is that you have one command, either Daytona create or a button create. Daytona does everything for you. We can run through what that is, and you always have the same output. You

14:15 have a dev environment that that it feels like it's local host. It is local host. It's proxy local host no matter where it actually is, and that is what we built out. And we've built it out as an open source tool for the individual dev can, you know, use it, runs it on local host, point to an EC two, can do that, or digital ocean, whatever. And there's obviously an enterprise where, you know, you you install it. There's a whole cluster, and, you know, it manages all these things that enterprises are, super interested on. Probably not the people here, but,

14:43 so that is what Daytona is, and I'm happy for you to dig deeper into those questions because, obviously, I haven't answered everything. No. That was that was plenty of context. I think I'm I'm I'm with you now. I am curious, though. When you say that you provision everything, do I get to use my own IDE? Yes. Learning number one. Learning number one of CodeAnywhere. So for Code, when we were building CodeAnywhere, there was no Versus Code. Like, that didn't exist. Right? And the only way that we can give you a dev environment or access to it

14:56 Developer Experience & IDE Choice

15:16 then because there was no there was no Versus Code and there was no remote in Versus Code, which exists in Versus Code or also exists in JetBrains now and whatnot, remote dev support. So we had to build our own ID. So we've built, like, five versions of a browser based ID, essentially, Versus Code. It's not on the level of Versus Code. Obviously, we're not Microsoft. It didn't have the budget to do that and, you know, the plug ins and whatnot. But the learning was definitely as a developer, I don't want to use your, you know, your ID, whatever you

15:48 built, whatever you think. No. Give me, you know, my Versus code. Give me my JetBrains. Give me my sorry. IntelliJ or PHP Storm. Cursor is all the rage now. You can use Cursor. It doesn't matter. Whatever you feel like using, you can use. The idea is that there's zero learning curve. It's everything that you've done historically would be the same, but just easier. Yeah. I mean, I I just mentioned it because, obviously, there's two types of developers. Ones that just don't care what their tools are and then some that have spent decades handcrafted. And I feel like I've spent decades handcrafted

16:18 my my tool chain. So what do you use? And I I work with one enterprise. Well, right now, I am using Versus Code because I I just don't think you could beat that extension ecosystem. It is huge. I've got one eye on zed, but I don't wanna get into the way it's attractive. I run Nexus on my desktop, and zed does its own plug in acquisition, which does not work with Nexus. So I lose all my LSPs. Okay. But I'm ready to jump to the to zed once it works. Anyway, I I as I was saying, I

16:48 worked for one large enter I've worked for a couple of large enterprise companies, but only one that specified we had to use a CDE, a common development environment. And that's what it was back in the day. This is, like, 2012. A virtual machine, a vacant virtual machine that I had to spin up on my my laptop Mhmm. In GUI mode. So I then got presented this fedora box with IntelliJ with its lockdown extensions and keyboard shortcuts. I couldn't change anything, and everybody worked that way. And I swear I quit that job after about ten days. I was like,

17:18 no. Sorry. Because at that time, I was a Vim fanboy. I was all over Vim. Oh, it was horrible. Even just queries in a VM is not a nice experience. So No. It's terrible. I have to I have to say one of our value props is and I'm saying it's very much from a technical perspective is that there's a lot of companies that use VDI, so virtual desktop interfaces, because everything has to be, like, in lockdown or whatever. Just just the latency of streaming my ID or editor, like, I'm not even gonna talk about, like, disabling all these things,

17:52 but just that latency is enough to, you know, wanna go kill myself. Like, it's like, I don't wanna do that. And can we provide the thing is, like, can we provide that same level of of safety security while as a developer, it doesn't feel like I wanna shoot myself? Like, can can we get to that place in the world, please? And so that is also one of the things that we try to do with all this for sure. So that's since you brought it up, I wanted to add on that 100%. Nice. Well, I think I'm a bit ready to

18:18 Hands-on Demo: Local Environment

18:19 see Daytona in action, and I think you're gonna lead us through a stellar demo today. Right? Let's hope so. Let's let's let's kick it off. Yeah. Sharing screen. Let's share the entire screen right here. Do we see my screen? We see my screen. Awesome. Screen is here. Great. Just like to start up really quickly. Everything I'm gonna show you is part of Daytona open source, which means, like, everyone can use it, take it, fork it, do whatever you want. It's Apache two point o, so, like, actual open source. I know there's, like, discrepancies on what people think.

18:53 So, like, you know, you can do whatever you want with it. You've not released the the Torna business source license yet. No? Yeah. No. We haven't gone that route. Yeah. We we still I have to say that when we were built we built out the enterprise product first and then the end open source afterwards. And we actually did it second because we wanted to be really sure about how to split these products in a way that we don't have to, like, make up licenses later on, pull back licenses later on, and and whatever. And so

19:22 what we discovered and it took us about nine months of figuring the of this out. And it's partially legal, partially product, partially, you know, vision, whatever. And, basically, what we decided to do is that everything that is interesting to a single developer, all of that is part of this repository, and, you know, it's patch two point o, and it'll always be patch two point o. Everything that you as a developer don't care about, audit logs, spinning up clusters, monitoring things, disabling it. Like, all of that is in a different repository, completely proprietary, and that's what we sell to the enterprise. So,

19:57 I really strongly believe that we will never have to go to a point where we, you know, touch these licenses because of the way we split it up split it up between a user and potentially a buyer. So we're very scared of that. There's a lot of things going on in the market right now, or the last few days. Anyway, Daytona had to spin it up, to install it. It's fairly simple. There's a big read. There's this. I'm on Mac. So, basically, I'm not gonna install it. I'm gonna hold up real quick. I will say that I went through the

20:27 docs for getting started, I see next instructions, and that made me very happy. So Didn't it? Yeah. Yeah. Yeah. It's in there. It's in there. So we're also I can explain a bit later. Basically, you just hit this. I'll install it. I already have installed, so I won't go through it, but it just, like, automatically installs everything. There's something. And then when you hit the Daytona command, you're basically you have this little little sort of terminal UI that can, like, walk you through the most needed, command. And so to get up and running, basically, all you have to do is this one

20:51 `daytona create` Command Explained

20:55 command, which is Daytona create. And I've already connected my GitHub, and I connected some providers and whatnot. But so I'm gonna pick up GitHub repository. As we said, it will be just a hello world. Nothing too nothing too complicated, but it has enough for to explain everything that's going on. So what I do, it's the workspace name. So what I've done right now with when we're building Daytona, we were actually thinking about can we make Daytona work from a logical perspective very much like a Uber? And, like, bear with me one sec. Or even a Waymo.

21:28 Right? Because today, you can hit a button on your phone. It's basically where I am, where I'm going, and what car is gonna take me, and it takes you. Right? It's like all I'm in the real world. And even with a Waymo, there's no driver. Like, that is the world we live in right now. And today, like, getting a dev environment automated seems like a harder task, which is, like, beyond me. And so when we're thinking about this, it's like, how do we do it in a similar fashion? So when I wanna spin up a dev

21:55 environment, it is where is my project? So the git repository where where it's at. Where do I wanna run this dev environment? Like, is it on my local host, DigitalOcean, GCP, wherever it may be? And what ID do I wanna use? Right? So I've I've set an a repository. I'm not gonna pick right now, I'm gonna hit local. I'll do remote later on. My local it'll spin up a Docker. And the ID, I've already set. So it'll just open up Versus Code, and I can show you a cursor afterwards if you want. And so what Daytona does is always the

22:24 same with a few, variations. And I'll get to next in one second as well. So what it does is it will spin up a if it's a remote, it'll spin up a VM on a cloud. But if it's local, it's there's no read for that. Then it spins up a container or micro VM inside of those. So on localhost, it's just like a docker. It will then check out the repository inside of that. It'll read through the repository. And if you have a configuration file, right now, it supports Dockerfile and dev container, but we have in testing. So it's already done.

22:56 Just to show you that's how long it took. We have in testing that we can also read next configuration files. And so if you have any of these configuration files, it will spin up everything automatically for you. And so now that it's up and running, I could have done dash c to get up right away. The project is here. It's been up for one minute. It's gonna open Versus code, my local Versus code, obviously, because I'm not doing anything else. So prefix number Daytona is just telling it how to open a remote dev container. Right? It's opening a remote dev.

23:07 Running the Local Workspace

23:28 Even if it's local, it's remote. Right? Because it's in your in your Docker. And so what's interesting because this project is has a dev container configuration, it is off to the races right away. Sorry. I I put yarn instead of yarn. Apologies. And so my project is up and running, hopefully. Like, demos should be working. It says hello, world. Here it is. Okay. It's up and running. So there's more to this, and I'm just gonna pause one second. So what it did was it checked out repository. It read the configuration. It built the entire dev environment so that I can come up

24:10 and running, and I only had one sort of command to get it up and running right away. Also, it is on local host. What's interesting if it was remote, I can show you that, but it'll be also local host. But one thing that we also have inside of Daytona, and this is running on my Docker. If I do Daytona forward, what's the port number? I was here. Port 5173? I think so. Yeah. 5173 Dash Dash public. Public. And if I do this, basically, what you'll get is a QR code, and you can scan it, or you can

24:26 Public Preview & Port Forwarding

24:43 type the whole URL, but it should be the QR code here. I'm getting my scanner. Yeah. So here you go. So get your scanner out and scan this QR code if you can. We've never had a QR scan before in over 400 episodes. Holy sweet. This work. Did you open it up? Yeah. Yeah. And so so what what what happened now is it adds a reverse proxy even if behind I'm behind a firewall, I connect it to whatever, and you basically have your preview environment. So if I go down here sorry. Let's change this. Let's change this real quick and say David.

25:13 Real-time Code Changes

25:19 And, also, everyone in the audience can do this if anyone was looking at it right now. Hey. That'll be refreshed in real time. It refreshed on your phone in real time. Right? Yeah. Did. Yeah. Yeah. And so what it does so what Daytona does, it some people ask me like, oh, don't I have this in Docker? Well, Docker is missing some people also called it, and I don't say that that this is what we are, like a a thin layer around Docker. It is all the things that you need for a dev environment that are that are missing from just

25:47 having a Docker container. It actually solves Workshop machine because it'll work for everyone everywhere. You can share it. Like, all these things are here, and it works no matter on what infrastructure. And so while we're this is gonna take a bit of time, but I'll just show you this. So this is my DigitalOcean, my account. And so if I do Daytona I'll do Daytona create the same repository. Daytona create GitHub. It's gonna take a bit of time so we can talk about things, but I just want it to go load in the background. Yeah. Don't worry. I've got questions.

26:00 Hands-on Demo: Remote Environment

26:21 Hello? So same project, hello world two, and I'm gonna spin it up because we're in Europe both right now in DigitalOcean Amsterdam. And so what is this gonna do? It's gonna do everything I did right now, but it's also gonna spin up a VM or Droplet in DigitalOcean. But I will also have the same it'll also be all local hosts. It'll be the same commands. I don't care where it is as a user. I can also share it to you. Although it's a, you know, a public, I could have done it anyway. It'd be a little bit of work. But it's,

26:51 like, out of the box, same feel, same everything no matter, like, where it's running. And we have this for EC two, and we have this for GCP, and we have this for all these different things. And so as you can see so it's right here. It's loading. And so this has nothing to do with Daytona now. It's it takes whatever time it takes for VM Yeah. To actually get up and running. So, yeah, I'm gonna pause here and let you now ask questions while this is sort of spinning. Good. Because I got stuff on my head.

27:14 Q&A: Multi-Workspace & Monorepos

27:15 First, just because the deal stuff is right in front of us. You mentioned earlier that once the VM is provisioned, you're then running a micro VM, something like Firecracker, and then running the application inside of that. Do I have the option to run multiple of those micro VMs inside of a single machine? Like, if or is it you get one one yeah. One host. Right now, the way it's created, the the enterprise product does exactly what you said right now. Okay. The open source sort of we have to get to where we have to get. So this version right now,

27:51 it's one b it's one actual Droplet per micro VM. Basically, the micro VM just the reason it's there is that it abstracts all the Daytona things that are running in that machine so that you don't see that in the workspace. You don't have to think about that at all. Yeah. You don't basically, you can SSH, with root access into the VM and then see that stuff. But, basically, you don't need to see that stuff because you actually don't care. To answer your question, will we support to to, you know, spin up multiple workspaces inside of that so you can orchestrate things? Yes.

28:21 And that's something that's on, like, very much very soon road map, but it's not there right now. Okay. Also, just because that was fresh in my head. We can now go back to that first example that you ran locally. Now I noticed that there's a dev container directory here. I'm assuming that's what Daytona is using to work out how to Exactly. This project? Exactly. The only thing that for Daytona is something that doesn't happen on every single repository is that it checks for a dev container type configuration file. So if there's a dev container, everyone is magical. Right? But, obviously, not

28:55 all of them have that. And so, one, we're expanding the the types of configuration files that we will support. So as mentioned, dev container, mix as well is going to be supported. Flux because, you know, why not? Because it's there. Dev file and Docker file. So those are the ones that we plan to support because those are all basically open standards, which will enable us to support even more of these. What's gonna happen so very a very hint for today. It's not core to Daytona's product, but this week, we're gonna launch a open source project. Hopefully, everyone can help us contribute

29:31 to this. It is a AI well, of course, everything's AI, tool that will create these types of files for any repository. There's still work to be done. It works on a large number of them, but the idea is that because we depend on that heavily, we'd like that to be a solved problem in the world. So then we're creating this, and hopefully, world can help us get to a place where this is not an issue. So every single repository in the world can be runnable right at the start. Note that if there is not a dev container or a

30:03 mix or whatever inside, Daytona falls back on a default workspace, which has everything. Like, everything's installed in that one so that it almost works automatically. Like, I I've had people, like, test out and say, oh, there's no dev container, and it works. Well, yes, because, like, it's a huge machine, and it's sort of just for the experience part for that to happen. I'm just showing you the screen. The meantime, the droplet finished. Now it's going through the through all the steps that it would have gone through on the local host as well. Back to your questions.

30:32 Okay. So I'm a I don't know if this is gonna lean into something that Daytona doesn't support yet, but I'll throw at you anyway. Everything I do is in one mono repository. So does Daytona give me any way to either say I'm working in this mono repository, but just this particular service? Can it handle a mono repository? Like, what is the best practice there? So yeah. So in the sense of mono everything's one repository, that's the easiest for us. Alright. The the the issues that we come up with are with multiple repositories. So Daytona supports right now that you can

30:41 Q&A: Secrets Management & Papercuts

31:07 have multiple repositories in the same machine, and that works right now. What we are working on right now, that was my call before this this right now, is how do we make a world where we don't complicate this simple flow, but that you can actually have a workspace, a micro VM, a pod, a whatever for every one of your repositories and that that they're all sort of connected together so that you can have that experience. That's something that we're working on, like, literally right before this call, but it's not in there. Okay. But what if the challenge with my

31:42 mono repository mono repository is that I don't have a top level dev container, and in fact, I have nested dev containers all throughout that repository? Is that something You can pick which one you want to run. Okay. That's the question. You can pick which one. Yeah. You can pick, oh, I don't want this. If I have multiple so let's say ASTRO is a good repository. They have, like, a hundred dev containers inside of that. You can pick which one you want to actually spin up. Which one you want to use. Right? And is it possible, I guess,

32:08 this I I don't know how it like, okay. Let's strap in. So you've got this Firecracker virtual machine. Is it possible for you if it's like, you've cloned my mono repository. So it's quite large. I don't wanna clone that every single time I switch between workspaces or packages within that mono repository. Can I say I wanna go from my web app to my back end API now and reload that without shutting everything down and back up again? There's no no. But but but there's a way to do that very fast. So we have something called prebuilds,

32:41 which is essentially what it does, it caches the build of a repository. So what that means is that you can spin up you can create a build for any of the branches or any of the dev containers or whatnot, And then you can spin up different workspaces of the same with the different builds. And because the because the build's cached, it's, like, super fast to get up. It's way faster than what we're doing right now. Oh, nice. Okay. Well, let's talk about that QR code thing then. I mean, did you build your own proxy? Are you are you leveraging other open

33:14 source? Like, how does Headscale. So it's an open source tail scale head scale, it's called. Just kudos to them for, like, making that. And so we were using them as a reverse proxy to be able to do this. The reason that we wanna do this as well is because, you know, creating code anywhere, which are browser based SaaS cloud ID product, there's a lot of those that happen that exist right now. And we wanted to offer that sort of value without having any cost. So, basically, what we have here is the same feel. There's also a will be coming soon just for

33:48 some people want it. We want we did CLI first. And so you have that same feel as if you're going through, like, a code spaces. So let's use GitHub. Right? It's the same. It's like, oh, pick my repo, pick my ID, enter. You do all these things. You can share a URL. It's like it's running in the cloud, but it's not. So we wanted that whole experience to be sort of packaged inside of Daytona. Nice. Well, it looks like your DigitalOcean one's working. Right? It is. It looks like it is. Let's do Daytona code. Let's try this out.

34:10 Running the Remote Workspace

34:16 So this is the one running on DigitalOcean. You can see that here. You can see here this one's running local. This one's running on DigitalOcean. So I'm gonna open this up. It's gonna open up a new Versus code, and we should go through the same flow even though it's running, you know, in Amsterdam, which is not on my machine. Obviously, some things might be slightly slower. We'll see. Shouldn't be. Here we go. Yes. Alright. Up and running. And so same, sorry, same flow terminal. And I'll do this time, I won't yarn. I did it right. Did I? And so

34:50 Remote Workspace Preview & Port Forwarding

35:03 what you're seeing right now is that it's also on my local host. So it's still running on my local host. And for me, all the commands I write are local host even though it's running on DigitalOcean. And, also, what you'll notice is that it moved the port from 5173 to 5174 because Daytona saw that the port was already used, and it used the next one that was free. So it says 5173, but I'm already using it for my other project. So it automatically did that, so I don't have to worry as well. And then you get that same sort of I wanna

35:37 do Daytona forward five one seven four dash dash public. I'll get the QR code here, and you should be able to work as well. Alright. You can scan it and see if it works. I think at this stage, I'm pretty convinced it's gonna work. Yeah. Even if it doesn't, I think it's good. Like, it's like yeah. Loading, not loading. Loading or at least trying to load. To load. At least trying to load. Yeah. So we'll see. Wait. Am I in the right one? No. No. Here it is. Might not. We'll double check why that happened.

36:26 But in any case but in any case, everything up until that was the same, and that should be the same as well. But, anyway, so what I was gonna show, the most important part here was that it's also proxies to local host. It moves the port if it needs to because I was still using the other one. If I'd killed this service that was running on my local, it would have been to the five one seven three I was supposed to, not adequately moved it. So I, as a developer, like, there's no difference outside of, like, snag, maybe,

36:56 what happened here for a second. But other than that, everything should feel the same no matter where it is. And so if even if I spin up now on an e c two or if I spin it up on, like, a physical, you know, server somewhere, it always feels the same to me as a developer. Okay. Very interesting. So I like that it supports module providers. I can work locally if I want. It seems to solve that problem that most people have in a Mac query. I mean, you're not syncing files across the network here

37:26 because you're cloning the repository on the the remote box, which is very So I'm curious to see well, if do you have, like let's look at that dev container dot JSON. Is there anything interesting in there first before I take us away from it? I mean, this one's, like, super simple. There's nothing Okay. It's just an image and install Yarn or something. Okay. Yeah. Yeah. Yeah. Install Yarn, and there's a Docker file and a Docker file. It's just like it's a very simple one. Yeah. I mean, we can spin up more complex ones, but even Versus

37:38 Dev Environment Configuration Files

37:58 code itself, like, I mean, it can do that for you. So I don't think there's that much magic in that. But what we do is, like, we build prebuild it for you and sort of deliver it done. Or we build it for you, but we can also prebuild it afterwards for you. So it's automatically done, and you always know that it works because that machine that it's running on is always the same. Right? It's not on my local machine, which can sometimes it's a Mac, sometimes it's a Linux, sometimes it's, you know, whatever it might be.

38:25 Yeah. I guess so. Yeah. It worked pretty well. I mean, I definitely wanna try and kick the tires on it with some sort of next flake or dev env or flux and and have it run as magic that way. It is on our so it's on our issues to support that. We've tried it. It works so like and so when we publish it, I'd absolutely love for you to kick those tires. The interesting part about all of these when you look at it, the the logic behind how Flux or Mix and dev container work, it's it it is

38:53 the logic behind them is quite similar. So it was, like, super easy for us to basically go out and build a version a builder for each of these. We call them builders. Yeah. I'm not sure if this is something you use of tackle yet or something you plan to tackle in the future, but there are sometimes very annoying circumstances where even running in local dev requires access to some sort of secrets or credentials. Does Daytona provide any framework or hooks to be able to get those into the remote machine? So you can forward secrets into the machine.

39:28 You can do that. It depends on where you can give you more explanations. Like, you can vary for the most simple problems that you have, but I don't know if you have anything more specific. Yeah. I I I mean, maybe this is just something that, you know, I've had a flake. I would just have in my dependencies that I need the one password CLI or I need in physical, and I have to then, when I'm in the machine, provide that credential. But maybe there's a way that because what I'm seeing here, right, is what Daytona seem

39:57 to be doing is taking something that is normally cumbersome, finicky, annoying, and putting on a very nice developer experience to the point where it's one or two commands and it just worked. You know? So that I'm now looking at, okay, well, what are the other frustrations that I have when I'm trying to work with development environments? And maybe there's a, you know, you can sprinkle some of that Daytona sauce or whatever to make secrets acquisition easier in this remote environment. I'm not sure what that would be. But Yeah. Would actually very much invite you and everyone watching if

40:31 you have any of those ideas. Just, like, open an issue, please, on our git repo on our GitHub repository, and we'll definitely take that out take look at those because you couldn't I mean, historically, when we started, you couldn't forward your environment variables or whatever you wanted to inside the machines or in those other workspaces, now you can. So, like, as we as we progress with the product so the open source product, we launched it in March. It's now September, so it's still a fairly short time. It's still not a stable version, to be clear. Like, there's breaking changes in

41:02 the updates that we do do. Just to be clear, like, it's still not there, and my engineering team is basically, I was saying, can we get to, like, a stable because of whatever reason? They're like, no. Like, we can't do that yet. We want the freedom to be able to move. We do two launches a week on the open source version. So it's like there's a lot of iteration of things happening. And so, basically, what we wanna do is take away all of these paper cuts that you have in a dev environment, and there's so many

41:28 of them because there's so many different dev environments. And they're not probably gonna be all your paper cuts, but you're gonna have two of them. I'll have two. Another will have 10, whatever it may be. And so can we sort of, like, take all these paper cuts and remove them from the world? That is what we want to achieve. Okay. I like it. Is there anything else that you think would be interesting to show us before we jump back to big face mode? I think that, like, for the demo, I'd like pause it here. I can share, like,

41:57 what the graphic interface looks like and what other things we can do, but I feel that because the idea of dev environments for people is like, why do I have to do it? Like, I have you know, I can do it myself. I can do whatever. I feel that this leaves the most impact, hopefully. And it gives enough that, like, oh, can I try it? Can I have that same experience with my project? Right? And if you don't, I'd love to know why, like, open an issue, and we'll we'll basically take care of it as soon as we can because we

42:25 wanna tackle all these issues. And the ones that you mentioned as well, the sense of can I have multiple workspaces basically running inside? That's something that's probably the most common question that we get from people that we talk to is, like, can we get that part in there as well? And so it's not as simple. It's not straightforward, but, yes, you can, and we hope to solve that for everyone as well. Yeah. Just like that that opens up that interest and approach where I can either spin up a slightly bigger box and repurpose it and save some time from the provisioning

42:56 versus having to shut it back down and spin it up. It's certainly not you know, it's not a deal breaker because what you're showing is that you can put a nice user experience, a a good nice developer experience on top of what is otherwise a relatively painful problem. So But can we but still, we want to get that one as well. Like, can there's no reason again, I'm I'm using the the self driving car analogy. Like, if we can get that, like, there's no reason in the world why we can't solve your problem. Like, there's no reason.

43:22 Right? I think. I think there's just not enough there was not enough of a pain for a solution historically because dev environments were not as complicated historically as they are today. Alright. Well, we have a question from someone named thank you in the chat. Okay. Thank you. I work with Red Hat OCP and ARO clusters. I'm not sure what those is it OCP that I'll come back to that in a minute. With observability and monitoring, can Daytona make my life easier? So I guess what they're curious about is can they use as as OCP Kubernetes?

43:39 Q&A: Kubernetes Providers

44:02 I mean, I don't even know. I don't know. I mean, I think OCP was that project that tried to do Kubernetes with no worker nodes and get a control point. Maybe, thank you, you can jump back into the comments and let us know. I have no idea what ARO clusters are. I'm so sorry. But, yeah, let's talk Let's talk more, but if we can get more details on the question, we'll try to answer. Yeah. Alright. Ravi is saying, so if we install Daytona with Next, does it still depend on containers? So it depends on the question.

44:34 So if you if we're talking about do we use next next, sorry, as a as a configuration, yes. It still uses containers. It's just the way that we architect that we architect these things. I know that next, the way it works, like, you don't have to have containers on your machine. But the way we've done it is we create we an isolated container every single time regardless just to keep the product as is. You as a user don't actually see the difference. You shouldn't see the difference, but the answer is yes. We do use that. And if

45:10 we're talking about the VMs as well, it'll go up and spin up VMs, specifically right now with DigitalOcean, and then it'll it'll build using the next configuration file, and each one will be its own separate even though I understand it could be on the same one. Yeah. Alright. Thank you, Seth. It's just a Kubernetes based Red Hat product. So maybe let's talk about I mean, I'm assuming Daytona could be deployed to Kubernetes and kind of provision to Kubernetes as a provider. So there there's two answers to this. Yes. We will. There's an up and coming provider

45:42 for Kubernetes. So instead of using, like, a Docker container, it can use Kubernetes and spin that up. So that's up and coming, and that sort of falls into the same, at least for us, the same problem as how do we interface multiple workspaces, sandboxes, whatever inside a a dev environment. Because if you're looking at it from a UI perspective, it is very much similar. So you have, like, one dev environment that has multiple of these pods or whatever. And so, yes, there is a Kubernetes provider coming up, but we're just aligning how that's gonna work with all these different things. So

46:20 that's not specific for for each of the different providers. Awesome. Alright. I'm gonna pop us back over here. If anyone watching has if anyone watching has I always forget about those little animations. If anyone watching has any more questions, drop them in. You've got a few more few more minutes to sneak them in. Let's talk about what's next for Daytona. So you open sourced this a little under a year ago. Mhmm. You're solving common developer or at least simplifying developer experience or getting developer environments. What's next and what are you what's your, like, North Star? Where do you want to

46:40 What's Next for Daytona?

46:57 get to? So what where we want to get to is hopefully be a way of work because it is an open source free tool. Hopefully, every developer in the world, like, uses a Daytona command versus, like, whatever they're doing right now and all the variations of that. That is, like, what we hopefully achieve at one time. But even more than that and I have to sort of add on it a bit just, like, aligning where the world is. There is a lot of and I'll take a step back before that. So we launched support for Cursor

47:26 last week or the week before that. And so why we do that? It was, like, actually very interesting on how why people looked at it. And when you look at all the launches, it's probably one of the highest. The reason is I don't know if you saw this, the meme on Twitter or x, whatever, of, like like, we don't need like, developers are gonna, like, go away because we have AI. And then you have, like, new someone in a in a in an iMessage sharing, oh, I made this application, which is not developer. They said show me, and they send local

47:56 host 3,000, basically. Like, I don't if you saw that. It's like a meeting. It was all over the Internet, when Cursor line raised their last round. And so as you saw with Daytona, there's, a QR code, but you have to show your thing. And so we felt that it was really interesting that we support Cursor because you can actually get a solution to that problem. Like, an AI creates whatever or assists you, and then you can preview it to something. And that got a bunch of interest, a lot of people using cursor, I think it's

48:22 our number it's been out the support for two weeks, and it's by far our number two IDE. So it's Versus Code and cursor, like, halfway there, which is quite interesting. The other thing while we're thinking about all that is what does the future look like in general for human and AI developers, be it fully autonomous or being just code assist or whatever? And it seems I've been testing out a lot of these. So all hands, dev and AI, and all these others, like, autonomous ones. And what's interesting for them is if you have fully autonomous one, it takes some time

48:56 to do things. Like, it's not instant. Right? If you wanna create a complex product, whatever it might be, it's gonna take the AI time. Like, they might know, quote, unquote, know everything. They might not I'm not gonna get into that argument at all. That's a whole conversation on its own. But it does take time to get something done. And so if it takes time to get something done, if you're running that on your local machine and if that is your full compute like, you can't do other things. You basically have to go have coffee and wait for the

49:24 thing to do something. Yep. For me, that doesn't make sense. Like, the the way it should work is like, oh, like, oh, AI. Here's a digital ocean or EC two. Like, go do your thing. I can spin up 10 of them because I'm doing 10 different things. And I also wanna build something on my own because I'm doing something, or I wanna check out the repo that that the AI has built, and I wanna do that. And so can what does the dev environment look like, you know, two years, five years, ten years from now where both human and AI

49:53 are creating code? What is the overlap? What is the difference? And so those are things that we're testing out and playing with. It's not an exact answer to your question. Like, I don't know. I was like, oh, we're gonna do this because the whole market as we see him is, like, fairly new and changes every day. But I feel that there's a going to be a even larger need for these standardized and larger, you know, dev environments running somewhere else because of these sort of tailwinds of AI in there. So there's a lot of thing. Not

50:21 saying we're not becoming an AI company per se. We're not doing anything of that. But what infrastructure is needed to run this stuff, basically. Very cool. Do you have you used Cursor? I'm just curious now. Yeah. I have. Is it good? I haven't. I mean, it's here. I I mean, I've used Cursor. I mean, their selling point, right, is that they scan your whole code base instead of just being pinched at, like, a single file, but I haven't Yeah. It does. You can do things in English, like, or in any other language actually, which is interesting. Like, you can do it in

50:52 French or German or Chinese or whatever. And it does. So, basically, I've I've done this demo and done other demos with Cursor as well where, basically, you say, oh, chain find the hello world that shows up when I run the project and change it to hello, David. It'll go through and say, oh, it's this file. It's on this line. Would you like me to change it? You say yes, and it does it. So it's like like, it's pretty cool for those things. I very much believe that AI is not in a place where it's like, oh, go build me an app, and

51:19 I'm gonna, like, make money off this app. I don't think it's even close to that there. But those types of things, like, yeah, it's, like, super convenient. You don't have to, like, search or do anything. It's just like, go do it, and it does it. So that's great. So you're not gonna be in the business of when people open issues on open source, it's on a project of having Cursa then go implement it, ship a pull request, merge it? Not quite yet. I don't like, maybe for the simple ones, there's a lot of people that the I've

51:44 talked to a lot of the a lot of companies that are building vary variations of AI agents, autonomous and, like, assisted. And there's a lot of them that still use humans, a lot of them. There are some that also use so there's startups that do exactly what you said. It's like, oh, there's a pull request, then you sort of assign the AI. It goes out. It spins up a VM somewhere. It runs. It does all these things. But I've also seen ones that do that, and then a human actually looks at the code, sort of fine tunes that, and then,

52:14 submits a PR. So I've seen those, happening as well. Fully autonomous, they exist, but it's also a question of, like, how good is it. I can't use it for a lot of things that we're doing, but it's also and you'll probably know this as well where it's AI does a lot of or AI. I actually don't really like that word AI for what what this is right now. I feel like AI is something like, AGI is more AI. Anyway, semantics. What I was gonna say is that AI is really good at doing things that we

52:44 have done as humans, you know, before. So if you're gonna create a crud app, like, that's easy. It's gonna go do that for you. Like like, anyone can do that. You just, you know, search the Internet, how you do it, whatever. But if you're doing something that has not generally been done or not in the public, and if we're trying to fine tune and optimize, you know, these machines and then, you know, sticking multiple machines in one machine in the way that we're doing, like, it's not gonna, give you anything really useful in the sense of, like, an

53:12 end to end solution. Obviously, in, like, assistance when you're, like, typing things and it's trying to help you, it'll find it. It'll do those. But actually making something complex that the world has not seen or not seen in public, it's not gonna do that very well. Alright. Awesome. Well, I will say thank you, first and foremost, for building a great open source project. I feel like the developer management environment space has been lettered with proprietary software for for far too long, and it's nice to see a bit of young fresh blood come in and shake that up with open source. I

53:27 Conclusion and Community Invitation

53:45 also appreciate the change logs, which are shipping far quicker than I can keep up with them. But that level of transparency into what you're doing as a company and a product at an open source project is invaluable. So, again, lots of thank yous for you and your team and what you're doing. Any final words before we say goodbye? Just very much a thank you. This is our first open source project product project. We've never done it ourselves. Obviously, we've consumed other ones, and we're trying. So if anyone has any comments of, like, oh, we're supposed to show this or do this,

54:15 we're trying like, the road map is in there. I just had a change lock is in there. All the issues, everything's very, very transparent, and we're trying to do that even though, you know, it is a company a venture backed company trying to do something. But this section of what we've built should be a pure as pure as it can be open source. And so if anyone has any, you know, comments or suggestions, we're all there. Also in Slack, we have a fairly large is it, like, 2,000 people, whatever, in our Slack? Happy to have

54:43 people join that as well and share with our comments and tell us what we're doing wrong or what we're doing great. Like, we welcome all comments. Awesome. Alright. Well, thank you so much for your time and for guiding us through that demo. And and to everyone watching, thank you for spending your evening, morning, or afternoon with us. We'll see you all next time. And gonna with everyone underneath the rising sun.