Self-Hosted CDEs Preferred to SaaS in Large Orgs, Says Coder
Coder, the self-hosted “Cloud Development Environment” (CDE) has just announced version 2.0 of its product, which includes new Dev Container support and integration with JFrog’s artifact repository. To discuss the latest in Coder.com, I spoke to co-founder and CTO Kyle Carberry and new CEO Robert Whiteley.
When it comes to CDEs, SaaS products like GitHub Codespaces seem to be the standard in this market — in other words, not self-hosted. So I asked the Coder pair why a developer would want to go the self-hosted route.
Carberry replied that Codespaces “prescribes the way that someone writes software,” whereas Coder is an “enterprise abstraction where there’s a maximum flexibility.” He added that on Coder, you can “bring whatever you want and make the development environment” using your chosen coding tool.
Why Self-Hosted CDEs are Increasing in Popularity
I noted that I’d recently reported on the launch of Daytona, which is also a self-hosted CDE (although its chosen acronym is SDE, which stands for “standardized development environment”). Neither of the Coder executives was familiar with Daytona, because it’s so new. But Whiteley had an interesting perspective on why self-hosted CDEs (or SDEs) are trending now, particularly in the enterprise market.
“I think what we’re seeing is a second generation of cloud development environments, or CDEs. We’re going to see more self-hosted or deployable. So Daytona’s a good example of a company that’s coming up. I wouldn’t be surprised if some of the SaaS-only versions actually ended up reversing course and having a deployable version as well.”
It’s a good point; and in fact, in the conclusion of my Daytona article, I’d questioned whether GitHub Codespaces will also offer self-hosting in due course.
Coder and Jfrog
“Mostly what customers have expressed is, look, this is an early adopter market,” said Whiteley, regarding CDEs. “Early adopters tend to be very sophisticated and they need the ability to have control over the environment, to twist and turn the nerd knobs, so to speak. And so I think SaaS takes that away. And to Kyle’s point, it’s overly prescriptive on how you code, where you code, when you code. So I do think — by the way, huge fan of SaaS — I think it will be the mainstream part of this market in, you know, 12-18 months.”
He’s referring to CDEs in the enterprise here, because in the consumer market (individual developers), products like GitHub Codespaces and Replit are already much more popular than Coder. But what Whiteley is saying is that “early adopter” companies are more interested in self-hosted CDEs.
Security Is #1 Reason to Self-Host (But There Are Emerging Reasons)
This begs the question: what kinds of companies use Coder currently? And is it security that is top of mind for them when choosing to self-host their CDE?
Whiteley confirmed that security is “by far” the biggest factor, particularly for large enterprises.
“So the value of cloud development environments, in general, is [that] I’ve essentially shifted development from local workstations to a cloud-hosted workspace of some kind. And so inherently, my development is now ‘behind the firewall’, right, so my source code is not on-prem or on a laptop. I can put access controls in place, I have better discoverability […] of what the developer is working on.”
However, he noted that there are emerging use cases for self-hosted CDEs, other than security.
“The one thing about CDEs is they do in some cases require a behavioral change from development,” he explained. “It used to be entirely remote. Now part of the solution can be remote, maybe your IDE is remote, but all of the actual coding practice is now centralized in a cloud.”
He added that “if you’re using AI or ML, you’re probably coding in the cloud already, because you need access to exotic GPUs or you have some large dataset that you’re trying to train a model on.” So, AI-based developer use cases are incentivizing companies to move to CDEs.
Large companies also choose self-hosted CDEs because it’s more cost-effective, according to Carberry. Some of its customers already use Kubernetes, as one example, so they can put Coder into that environment, which Carberry says is a lot less expensive than paying a SaaS provider to host your CDEs.
“It’s one of the reasons that we actually don’t prescribe any infrastructure,” Carberry added. “Some of our customers are extremely happy with, like, VMs. And with Coder, they provision a VM for each developer and it automatically shuts off when they’re not using it. Some of our customers use Kubernetes, some of them […] run OpenShift and then maybe develop inside of there. So it’s kind of like a hodgepodge, I would say, but the biggest lesson is that we can’t really prescribe anything […] particularly to large enterprises.”
Dev Containers
From a developer perspective, perhaps the most interesting thing about Coder 2.0 is its enhanced support for Dev Containers, a Microsoft-developed open standard that “allows you to use a container as a full-featured development environment.”
Carberry said that previously Coder supported dev containers as “a second class citizen,” but in 2.0 the product offers “Envbuilder for Dev Containers,” which is an open source project by Coder based on the Microsoft Dev Containers specification. “Envbuilder enables users to control their development environments without affecting infrastructure or requiring the work of DevOps and Platform teams,” stated Coder in its announcement of 2.0.
Whiteley added that dev containers is “an emerging spec,” and that “we were sort of dragged here by customers — some of our largest customers were doing dev containers, wanting to make it part of their development standard.” But he said that even if the dev containers spec ultimately doesn’t work out, Coder doesn’t rely on it (it’s just an option) and so its product won’t be impacted.
