 The other libraries, you have exactly what is needed. Anything else that is exactly what's needed to successfully run the software without hassle, it's just there. And then you do your work. So in this situation, you've got this not very fun before. And then you've got this much better after. There's a little bit of toil, but it's not much at all. Previously, you had nine out of 14 steps that were toil. In this scenario, this magical scenario, you can cut it down to just two steps of toil. And your total number of steps is 50% less. That sounds pretty good. You're spending less time on that and more time on what you want to do, on what you need to do. This problem can be even worse at work, because when you get a new job, you have to get a new machine. There are multiple projects that you're working on, concurrently. You've got coworkers who might have slightly different machines. They're running maybe Ubuntu 21.10 instead of your 22.04. And then you check in your change, and it breaks for them. And then you say to them that classic phrase, well, it works on my machine. And you also have to debug it in CI, all of those other things. These same problems that you have contributing to open source, they exist in professional software engineering as well. Assuming, of course, that you're not working professionally on an open source project. In that case, you get the worst of both. So here, more frustrating toil. You basically have to be ops for your own machine. And have you ever met a happy ops person? They're not. They're not happy. And they didn't start that way. They used to be happy people, but then they had to do all this shit over and over and over. And it made them a little bit unhappy, a little bit grumpy. The thing is, you spend too much time around the software. This was a survey done a few years ago by Electric Cloud, which is now defunct. Pour one out. In an approximately 40-hour work week, 10 hours were spent managing the environment, managing the workspace, libraries, OS updates, all that stuff. And then there was also a lot of time lost waiting for tests to complete because machines might be under-resourced, and similarly, waiting for builds to complete. Now let's imagine a professional scenario. Let's imagine a company, let's arbitrarily call it Redoc. We've got Adriana. She's a new software engineer joining from the lovely city of Florianopolis, Brazil. We've got her new manager, Bia, who works out of Montreal and Quebec. And then we've got Chinwe, who's a VP of engineering working out of Atlanta. This is what Adriana's day one could look like. She opens up her shiny new laptop. She authenticates with GitLab. She loads their instance of their cloud workspace system. She selects the workspace that Bia created. She starts her local IDE. She runs a build and a test, which passes perfectly. And then she starts work. This is done in 10 minutes. There's no unnecessary crap here. There's no frustration. There's no dealing with all of the little things that get in the way, all of the little rocks in your shoe as you try to walk down your first day. And that's because her manager, Bia, got there on day minus one. She went into the app. She clicked Create Workspace. She chose a shared developer image that had already been created. And that developer image is built on a Linux image that matches their production. Exact distribution, exact version, same kernel version, so forth. It also includes their API server with a database template so that she can run their PostgreSQL, for instance, built in. And it's targeted at the X8664 architecture, which is also what they run in production. Because they have a mobile app, it includes a macOS virtual machine so she can run iOS apps as well. And then, of course, your dev tools, all of this prepackaged in a custom image. You just have to choose it and away you go. And then, just to help Adriana out and make efficient use of resources, she sets it to start automatically, Monday through Friday at about 9 AM, Brazilian time, and then automatically stop 10 hours later. She doesn't want Adriana overworking, after all. And then she changes the owner to the new hire, Adriana. And she's done. Bia did this in a similarly brief amount of time. And now, because of this little bit of effort before, Adriana can get started in 10 minutes. So we can look at Adriana's day one, which in a more typical environment might be the middle of day four. She can make code changes, simple code changes. She adds an additional database column to some lookup query. She passes that field back in an API response. And then she uses it to display a new field in their mobile app. This is 15 lines of code. It's not a huge change, but remember, she's new. She doesn't know the code base. But she's able to get to it by 2 PM with this small change, because of all of the normal new hire craps she didn't have to deal with. She was able to do everything she needed after logging in and starting up her workspace. Sorry, her workspace was already started. So Adriana, the things that she appreciates about this, she doesn't have to deal with out of date onboarding documentation. Who here has gotten a new job and the documentation was completely up to date? And you had to get no help whatsoever setting up the software. Anyone? Really? We should talk. I want to know about the Shangri-La that you lived in. There's no fiddling with library versions. There's no fiddling with additional tools. There's no tracking down all these different dependencies. There's no trying to make them work on her machine, her OS, her version. And there's no risk of breaking anyone else. These are the things that probably go through everybody's mind when they start a new job, because that's what they've had to see. That's what they've had to deal with in all of their previous jobs. But what's nice for Adriana is she just writes code. That's why she's in this profession. She loves writing code to build features. She doesn't love being ops for her workstation. Bea buys into this as well. As a manager, she loves getting near immediate, new hire set up. She loves that her team spends a lot less time investigating mysterious bugs that are caused by subtle differences between deployments or caused by configuration drift over time. That means that fewer bugs escape to production. And then the VP is also pretty chill about this, because there are fewer company level incidents. There are fewer situations she has to go in front of the rest of the executive team and give a rundown. OK, this is what happened. This is why it happened. Here's what we're going to do to fix it, because it just happens less, those stressful occurrences. She also gets to have lower infrastructure cost, because she doesn't need to send a maxed out MacBook Pro to all of her engineers and a Linux workstation. That's also beefy. She gets powerful budget and policy controls to make sure that people are using the resources they need without overusing and without leaving orphaned resources out there. I think everybody in this room has probably, at some point, seen a cloud bill and wondered, where is that coming from? I thought I shut everything down. I had a cloud bill from AWS for three months for $0.36 before I tracked down what was happening. I thought I'd shut everything down. But you get good policy and budget controls. You don't have to worry about that. And then she also has to worry about compliance and security requirements. And she can satisfy those through the system. Now, you've heard this before. This is like the second time Dolly has ever made a realistic face that's not terrifying. So congratulations, Dolly. What's changed are VMs and containers. There are many, many container and virtual machine images. It's become standard over the last 10 years for VMs and maybe the last, like, six, seven years for containers. There are tons of options widely available for running these VMs and containers, different architectures, different GPUs, different levels of power, low-power CPUs, brute force CPUs. These are easy to customize. It's very straightforward to build a custom Docker image. Even I, as a pointy-haired boss, can do it. And then these are easy to distribute. The tools pull them down automatically. Just point them at a registry, and you have it. The infrastructure has also evolved considerably. There are powerful and varied cloud capabilities. We are all the beneficiaries of Microsoft, Google, and Amazon trying to steal each other's market share. They're building really amazing stuff. They're also a lot cheaper. The cost of cloud has been going down, down, down. It's going to continue to go down. And then if you don't want to go cloud, you have robust software for managing on-premises resources, hardware that you own, or just control. You have Kubernetes, which I think half of the other companies here are doing something with, and other orchestrators that can dynamically provision resources as you need them. For example, when somebody is running a really big build. But then also release them when you don't need them anymore. So you get a level of flexibility here that you maybe couldn't have before. There are also remote capable IDEs. They can run in a browser or on a local thick client connected to a remote workspace. You can do this with JetBrains IDEs, VS Code, RStudio, Jupyter, and more. There's also a problem of big, big code bases. Big SaaS companies have big code bases. They've got so many different services. They've got so many different deployables. I used to work at Indeed, and we probably had five deployables per software engineer, just because the system was so vast. You also have big ecosystems with many dependencies. The great thing is there's a ton of awesome open source software that you can build on in the Java ecosystem, in the Go ecosystem, in the JavaScript and TypeScript ecosystem. But there are so many different dependencies that you rely on as a result. All of this plus more means that your builds download more, they do more, they test more. Much greater demand on resources than your typical application 10 years ago. And then you have to support more architectures. A medium-sized company today, probably deploys on Linux, may have a Windows app, will likely have an iOS app, an Android app, maybe a Mac OS app as well. They have to support three different CPU, well, sorry, not CPU architectures. They have to support three different desktop operating systems and two mobile ones. You have to support x8664, RM64, RM7, GPUs. The hardware proliferation continues. And then you might have specialized use cases using different operating systems, using different architectures that are specialized to internet of things, automotive, network switches, and so forth. All those pictures on the bottom right are a courtesy of Dolly, by the way. And then there are increased regulations and stricter policies. Software is making big decisions. In some cases, maybe criminal justice, maybe it shouldn't. But nonetheless, it's making big decisions. Decisions about that, decisions about whether it should stop, whether your car should stop because of something in the road, big, serious decisions. And so the software needs to be examined very carefully, needs to be built very carefully. Companies, as a result, have comprehensive IT policies, managing their data, managing their code, managing their physical and virtual assets. And then regulators, they too care a lot about this through laws like Sarbanes-Occitly and comparable ones in other countries. And we also have a more threatening security landscape. Laptops get stolen or lost, and that was true 10 years ago, 15 years ago. What is different is people use laptops as the standard computer, where maybe that wasn't the case before, and they're working on software or sensitive data a lot more than they used to be. So this risk has gone up considerably. Hackers will steal code and data from insecure computers, especially on home networks. And then bad actors inject malware into source code so that they can attack the downstream users of that software. I'm sure a number of you are aware of the SolarWinds hack that was discovered in late 2020, which was exactly this kind of supply chain injection problem. And then of course, our buddy COVID-19. Lots of people are remote now and are quite likely gonna be remote forever. I myself know I'm never going to work in an office again. You can have sufficiently powerful workstations for all of these needs, but they aren't portable. And then your portable workstations aren't sufficiently powerful. And that's kind of frustrating, right? Like, why can't you have both? It turns out the future is already here. It's just not evenly distributed yet. Attributed to famed cyberpunk author William Gibson, who might actually have said this. This future is already here for engineers just like you who work at Facebook and Google, Palantir, Stripe, and more, not many more, just a few more, but they've done it. Remote workspaces, they can do what the local ones do. They can host an IDE, they can execute the builds, run tests, run a debugger, they can connect to service dependencies like other microservices or databases, and they can connect to the internet, assuming of course you want them to and you allow that with your network policy. Remote also does what your local workspace can't or it can't do well or it can't do affordably, can't do securely. It'll live in a secure network if you so choose. That limits direct access to data or code because you never have sensitive data or code on a remote endpoint. You access it through a controlled system. It can also provide more resources. You can get many more cores, a lot more RAM, and it provides efficient access to scarce resources. If you tried to buy a GPU a year ago, it was really hard. Gamers wanted them, data scientists wanted them, Bitcoin miners wanted them, and those data scientists use the crap out of them. They run enormous jobs for really important business use cases, for example, at hedge funds. And then it can easily replace workspaces. If yours is acting funky or weird, you just throw it away, build another one. It's trivial. If somebody told you you had to re-image your desktop computer or your laptop computer to fix a problem, you wouldn't be happy, but this easily disposable. And then you can switch between different workspaces that are running simultaneously. You can switch between different operating systems and architectures that are running simultaneously. You don't have to deal with local VM software, dual booting or anything like that. You can have two pristine standalone workspaces running completely different operating systems at the same time. It's better in just so many ways. You get more productivity. You get better security. You have an efficient use of resources because you can grab resources when you need them and release them when you don't. You can have consistency through all of your developer workspaces, your continuous integration, your production deployments. You have a lot of flexibility. You can use any kind of operating system that you need or want. You can use any architecture that you need or want. You can configure these workspaces any way you want. You have convenience and portability. It's so easy to get started. It's so easy to switch computers. I write code against one workspace from this laptop and then I also write in the same workspace the same code from my home machine and I switch seamlessly through them. And then you just have less frustration. We get paid well but hassles are hassles. They take away from our well-being. They can ruin our days. They can ruin our weeks if they go on particularly long. And the thing is nobody has ever said to me, I'd rather do this the old way. We have customers that say things like, I'd like this feature or this isn't working right. But nobody ever says, you know, I'd rather go back to being ops on my own machine. I'd rather go back to having an underpowered laptop for these giant builds. What they say instead is I will quit if you take this away from me. So I said the future is already here. It's just not evenly distributed yet. This all sounds like a shell script and a Docker file. It turns out this is much harder problem than it seems. So it's required the resources of a large corporation to get it right. The shell script and Docker file will work until it doesn't. It may not work across multiple people, multiple teams, different architectures. It may not have sufficient flexibility, scalability. And then it leaves a lot of things to be desired in terms of resource management, security. So you can do a very basic form of this very easily, but you run into the limitations very quickly. And the sheer difficulty of this problem means you need to be a company that can have like 50 software engineers just dedicated to develop a productivity. Maybe a hundred, maybe more. Or you can have what they have. Coder is now free under the AfroGPL and it's free in terms of money. You go to github.com slash codercoder or to our homepage at codercoder.com and you can get it today. We made Codeserver, which some of you may have used before. Very popular. This takes what Codeserver does and expands it to a robust comprehensive platform. It's no longer just an IDE in a browser. It is a complete replacement for everything that you do locally on your machine to build software. And it's not just that you can have what they have. It's actually better than what they have. We know this because some of these companies have built it themselves and then wanted to use our product instead. So this means all of you can get a remote workspace. Coder is really convenient. You can share workspace templates among different people on your team or across teams. You can automatically update the images and tools so you're never running an out-of-date operating system or an out-of-date compiler. You can schedule startup and shutdown as desired. So you can always have it perfectly running five minutes before you're ready to work but don't have to worry about it running overnight over the weekend wasting resources. It's also flexible. You can run workspaces on any infrastructure you want. You can run it in the cloud. You can run it on a rack in your closet. You can run it anywhere in between. It'll host Linux, Windows, Mac OS, all at the same time in different workspaces. Sorry, different, haven't come up with the term for this yet, different pieces of compute. And then you can access it via a powerful command line interface, an API or a web UI. And you can use any local machine that you want. I can use my Mac laptop. I can use my home Windows machine. A lot of our engineers use Linux. People have used the system to code from an iPad. You could use a Microsoft Surface tablet. Pretty much anything that has a web browser and optionally SSH can run and use a code or workspace. It's also powerful. You can have multiple workspaces for the same user, either sequentially or simultaneously, specialized for different projects. You can attach arbitrary resources like persistent disks or databases. That means these workspaces can be as permanent as you want them to be or as ephemeral as you want. We don't force a choice on you. And then you can host multiple repositories in the same workspace. Coder is secure. You can run the workspaces where you choose. If you wanna do it on a locked down network that has no connection to the internet, it's perfectly air-gapped, you can do that. We have customers that I can't name who do that. We have audit logging. We have powerful access controls. You can limit or liberate any capabilities on your installation that you want. And if we don't quite have what you want, we're very responsive. We're building fast. Coder is fast. These are some results that Palantir published on their blog about a month ago. They're one of those companies that has giant workspaces. They published two benchmarks, cloning the repository and compiling the code. In their remote workspace, compared to the local laptop that their software engineers were often working on, they could get almost five times as fast a clone. This must be a giant repository if it takes 40 minutes to clone, right? This isn't the type of thing that these large companies are facing. Their backend for this project was considerably smaller, but even there it was 1.7 times faster. And then when it came to compiling the code, and I believe this doesn't even include testing or packaging, when it came to just compiling the code, it was three and a half times faster on the front end, and almost 1.9 times faster on the backend. Imagine how much software engineers get paid, and imagine how much time this frees up for them to do what employers and software engineers want to do, write code to deliver awesome features, instead of waiting, instead of staring in frustration at this very, very long build. You can try Coder right now. Two lines, download our install script, pipe it into shell to run it, and then you can invoke Coder server. This uses an embedded DB, uses an embedded Postgres, so that you don't have to download anything, connect anything. You can easily use an external Postgres if you want. There are more extensive docs available at coder.co slash install. We give you a pretty powerful command line interface, which is prettier than almost every command line interface I've seen before. We have a friendly UI in the dark mode that everybody loves, and very quickly you can be ready to rock. There's the workspace web interface on the left. There's my visual studio code on the right. There's shell access on the bottom right. It looks just like a machine. It can run in a container, it can run in a VM. You get complete access as you need, as you want, just like you do with a local machine. The best way to predict the future is to invent it, said Alan Kay, maybe. It's also been attributed to Abraham Lincoln, who definitely did not say it. This is an inevitable future. This is the way things are going. We're 15 years behind many other professions, but there's no getting around the fact that the benefits that they have accrued from the cloud are ready and waiting for us, and we are building this future right now. If you want more information, I have some time for questions now, or you can stop by our booth at G12 in the sponsor showcase area. You can also go to our github, coder.com, and then you have our installation docs at coder, cdr.co, slash install. And there's also the install instructions. So cool, thank you for coming. I think I saw a hand raised in the back. So the question was, can you run coder self-hosted on top of Kubernetes? Yes, you can put coder inside a container that runs on Kubernetes. Do we have Helm chart support for this right now? Okay, we don't have a Helm chart yet, but it's also very trivial to deploy that's something that we worked really hard on to make it this simple to deploy. So you can plop it in a container, run it in Kubernetes. We'll work on the Helm charts. We have them for our previous version, so we know this stuff really well. Yes, so the question is, how easy would it be to have these workspace settings in source control? We built exactly for that. So the workspace templates that you use in our initial release, they're just Terraform scripts. We plan on supporting other infrastructure tools in the future, but they're Terraform scripts. And of course you would wanna keep those in source control. We also have personalization options. So you as an individual using a shared image can personalize your own workspace. We do that through support for revision controlled dot files. You just point us at a Git repo that has your dot files and we automatically pull it down and populate your workspace with them. So you can have your Z shell RC exactly the way you want it. You can have your Vim RC exactly the way you want it. And then there's also a startup script hook. So any configuration or personalization that you want on top of that kicks off automatically when the workspace starts. In addition to that, depending on how your deployment is set up, whether it's a highly controlled one and say a big bank or your own where you let yourself do whatever you want, you can connect to arbitrary registries with arbitrary container or VM images. So you can pull down any level of customization in the underlying image as well. There, it's very much a belt and suspenders and then two other things that hold up your pants approach to customization. Check, check. We have some questions from online. Yes, please. All right. Does Coder support iOS development without a Mac? If I use a Coder on my Linux workspace, can I use an image to get iOS tools and a complier for the apps? We do not currently support running iOS. I'm not sure what's involved in that. With Mac OS and iOS, there are kind of tricky licensing issues. So they're not technical issues. So I believe only one of the major cloud providers can actually offer Mac VMs. There are a couple of smaller providers that can do that, but there are some non-technical hurdles that get in the way of Mac OS support. You can do it. It works perfectly from a technical point of view. Just the licensing makes things a little bit more complicated. I believe that applies to some extent with iOS or I could be making that up. If you have access to a Mac OS machine that can host Coder, you can use the iOS tools that are included with Xcode and similar, but iOS natively we currently don't support. Okay, I have a lot more. Okay, what's the difference between Coder and Codeserver? The difference between Coder and Codeserver is that Codeserver is an IDE that runs in the browser so you can edit your code, you can interface with a terminal, you can interface with a revision control. It gets a little more complicated if you wanna run more complex builds, if you wanna do more complex dependencies, if you wanna have disposable workspaces because Codeserver, you install semi-manually onto a machine you control. It's also typically individual, so you install Codeserver for yourself. Coder is meant to be a platform that can be used, yes, by the individual, but also by a very large organization. Looking over there to make sure I didn't get anything wrong. Cool. What is the minimum requirement to use Coder for five or six people? Yeah, I wanna add something to my previous comment. Codeserver is a tool that you can run on the Coder platform. So if you like Codeserver, great. You can also use it on Coder and it's often bundled with our workspace templates. Getting back to that second question. What are the minimum requirements? Coder itself is very lightweight. It uses negligible CPU, we have a backing database. We don't hammer that database super hard. So running our control plane is very lightweight. You can run it on a very modestly spec machine. One CPU, one gig of RAM, probably less. We haven't actually done any testing to find that lower bound. Where you're probably gonna be more limited for resources is in your workspace. In order to have an efficient running workspace, you want a lot more power, right? To get those fast builds, to get those fast test execution. So that's completely up to you. We provide the control plane. The underlying infrastructure is entirely up to you. You spec it out yourself. It could be a physical machine that you own. It could be something in the cloud. And those resources basically depend on the performance that you want and are willing to pay for. Are there any plans to integrate with GitLab similar to other projects? Yes, there are plans to integrate with GitLab. We can integrate with GitLab for authentication very soon. We can integrate with GitLab for pulling in .files. One of the nice things also is when you are authenticating, or if you have set up an integration with one of these version control systems, when you drop into your workspace, all of the keys are already there. They're already loaded in the session. So you don't have to do any Git authentication, anything like that. You just do a Git clone or a Git pull and it works. So we have pretty decent integration with those things. It exists in our V1 and very soon we're gonna add more than GitHub to our V2. But right now it's GitHub. Sorry, question in the back. The question is, can you use OIDC for user authentication? Yes, we definitely support it in V1 and we have support for it in V2, this open source version as well. How does this work versus say Gitpod.io looks like more feature rich but similar idea? Question mark. Yeah, the question is, oh, sorry, you had it, yeah, the microphone. Gitpod is another company that's in this space. I wanna be careful how I say it because I think they're competent, capable people who are building a reasonable product. I don't wanna sound like I'm disparaging them. But our product is better. One difference is that theirs is a SaaS product. They do have an open source distribution but it's not, I think, front and center. So I don't know how challenging it is to deploy and install. What I've found in my professional experience is when you have a SaaS online type of product, gathering up all the various tendrils of that to make it something that somebody else can deploy and install is very challenging. So they may have run into that problem. They, I believe, have more limited support for different IDEs. They have more limited support for the resources. I believe that you rent the resources directly from them to run workspaces and so you can only use what's on their menu. Those are a few of the differences. So what we've been able to do with our product in part through working very closely with some really big companies is we've made it very flexible, very powerful. We are very unopinionated about which tools you should use, which platforms you should run on, which architectures you should use, which infrastructure you should use. We wanna align to the many choices that you've made to fit your needs. I think SaaS products are less able to do that. Does Coder offer Rasbian support? I'd like to run it from my Pi to do remote development when my laptop is off and it's the closest I have to a machine I can keep running for hours on end. Yes, you can run Coder on a Raspberry Pi. Yes, question there. Yeah, so the question is, what are the networking requirements to connect to your Coder instance? This is one of the clever bits. All you need to do is to be able to connect to the control plane and then through the magic of some sophisticated networking techniques, that can be proxied on the initial connection to this workspace cluster that might be hidden behind a firewall and then we establish a direct machine to machine connection that skips the proxy using turn and stun and things like that. So initially the handshake goes through the control plane but after that you have direct connection without having to punch holes and firewalls or anything like that to your workspace. So you can keep that secure and only expose the control plane to wherever you need to access it from. You can also avoid that if you're particularly concerned by just running the tools and the terminal in the browser. So you don't necessarily have to even access it that way. We tunnel SSH if you need to and anything that builds on SSH can work pretty seamlessly. So local or browser-based as you like. Yes, yeah, so the question is how do we monetize or in another sense like when do you have to start paying? Our overall philosophy is that we want features that are good for the individual software engineer or the small team to be free in our open source project. Where we draw the line where it starts becoming something that we charge money for are the features that most benefit large enterprises. So more robust policy controls, perhaps cost management. We have a long list of things that we've identified that they might be useful to a small number of individuals and small teams, but where they really have the most value is at the enterprise level. We want this to be a full and robust and complete experience for the individual software engineer or the small team. So we're definitely gonna bias and in fact have biased to that use case. So for instance, authentication is one thing that a lot of open core projects may charge for, but as the gentleman in the back asked about OIDC, we support that in the open source product out of the box. So because the individual software engineer and the small team needs that. All right, we are good. Thank you all for coming. If you have further questions, there are a few of us from Coder here or you can visit our booth and we'd be happy to tell you anything about the product, maybe even show you a live demo.