Gitpod vs. Coder: the misconception of infrastructure choice

Gitpod and Coder both provide platforms for creating and managing development environments. The biggest difference between the two is their developer experience and operational overhead.

Gitpod is an install-and-forget, self-hosted product for automated and standardized development environments.

Coder is a self-managed and self-hosted cloud development environment — this means you host their product, and you also commit to supporting and maintaining it. Coder can be easy to get started with for those familiar with Terraform, or with backgrounds in infrastructure, but requires a considerable amount of maintenance due to infrastructure choices you’re required to make. These maintenance challenges typically manifest as ‘day 2’ problems and can increase your total cost of ownership. Day 2 challenges are also often not apparent when trialing a product, making them a true hidden cost.

What are Cloud Development Environments?

Cloud development environments (CDEs) are development workspaces pre-configured with all the tools, dependencies and libraries required to start coding. You can use CDEs for:

• Faster onboarding
• Consistency and reproducibility of development environments
• Better collaboration between peers
• Faster build times for large codebases
• Simpler security setup

The ‘cloud’ part of cloud development environments represents infrastructure that can either be hosted within your organization’s cloud account, or hosted within a vendor’s cloud account. Once the decision is made on where to host the software, you have to decide how to manage it. This results in three options that will define the ease of use for getting started, and the ongoing overhead for maintenance and overall developer experience.

Day 2 challenges

While you pay Coder the price of an Enterprise offering, none of the functionality ‘provided’ to users comes as a service. It comes as build-your-own infrastructure with attached massive maintenance costs. That ongoing overhead and impact to developer experience are bucketed into the day 2 challenges mentioned earlier. These challenges are more prominent depending on which model you move forward with. We discuss the challenges of the self-hosted and self-managed model in more detail in this blog post written by our CTO Chris Weichel. But for now, here’s your TLDR;

• Self-hosted and self-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by your team.
• Self-hosted and vendor-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by a vendor.
• Vendor-hosted, vendor-managed: hosted in a vendor’s cloud infrastructure, as well as operationally managed by the vendor.

Self-hosted and self-managed software provides you maximum infrastructure choice at the cost of maximum overhead. It checks the boxes for security benefits associated with being hosted within your cloud infrastructure—provided you implement those security controls—by allowing you to manage and maintain every service related to that software: the components, data storage methods, computing resources, networking setup, observability, etc. But because of this degree of customization, setup can be tedious if you aren’t familiar with basic infrastructure concepts, and maintenance is always resource-intensive. This describes Coder.

Vendor-hosted and vendor-managed solutions are the complete opposite. They’re what we’re used to calling your typical ‘SaaS’ offering. They’re quick to set up, have no overhead, but offer limited customization and often are incompatible with enterprise compliance requirements. These solutions are often great for smaller teams with simple setups. This describes Gitpod’s pay-as-you-go offering.

Self-hosted and vendor-managed solutions are your Goldilocks solutions. They provide the security benefits of being hosted in your organization’s cloud infrastructure, as well as the ease and efficiency of being managed by a vendor. They eliminate any need for you to operate the software and require minimal upfront investment. This describes Gitpod’s enterprise offering.

Why Coder only passes the Day 1 test

Coder is open-sourced. They have optimized for being self-serve and quick to trial. And while it is fairly easy for anyone with knowledge of Terraform or basic infrastructure concepts to get up and running with Coder, they often overlook everything that happens after Day 1 – enter the day 2 challenges described above.

At Gitpod, we understand the challenges of self-hosting CDE software well. Our first enterprise product used a similar deployment mode to Coder. But we learned of the huge operational burden that we were passing onto our customers in operating and managing CDE infrastructure. Our customers wanted a CDE and all the productivity and security benefits, but didn’t want the overhead of managing that infrastructure. Because of this, we introduced a self-hosted, but vendor-managed solution.

When it comes to making infrastructure choices with a tool like Coder, it’s helpful to understand what decisions they ask you to make. Who wants to mess with Kubernetes, let alone a long list of requirements for running and maintaining a product you are paying for? Coder requires you to:

• write and maintain your own workspace definition using Terraform
• set CPU and memory requirements their workspaces
• set CPU and memory requirements for external provisioners
• set up CPU and memory requirements for the databases used by their workspaces
• allocate CPU and RAM for concurrent users – this will also be dependent on if they are accessing workspaces through Coder’s HTTP interface, the web or via SSH
• provision resources for concurrent workspaces builds. This also depends on the Terraform provider used.
• run your own scale tests to make sure your workspaces are provisioned properly, including generating your own traffic
• set autoscaling rules, with special considerations for Kubernetes users who choose to employ a cluster autoscaler
• install a Prometheus server in order to enable metrics
• upgrade your Coder server
• deploy a workspace proxy to help provide low-latency experience for geo-distributed teams
• enable, manage and disable encryption for database keys

It’s also helpful to visualize this. Everything in the gray shows you your infrastructure choices – otherwise known as decisions you need to make, and then maintain, to run Coder.

How to choose between Coder and Gitpod?

The list above represents the infrastructure choices that Coder provides. It also represents a long-list, not inclusive of everything required in order to maintain a self-managed CDE. Part of that maintenance not represented above is updating the Coder software. Each time Coder pushes an update, you will have to manually make changes to your setup in order to retrofit those changes.

If you have a team that is ready to be resourced specifically towards maintaining CDEs and making choices about the infrastructure surrounding it, Coder could be a great fit. It will give you the most infrastructure flexibility when making choices on how to build your CDE solution.

But if your team looks at Coder because they thought it was the only solution that would fit its security needs, that is where sharing this post with them would come in handy. Gitpod is able to be self-hosted in your cloud infrastructure meaning it passes the security review for large enterprises. We explicitly chose to vendor-manage the application in order to take away the burden of operation. These are the infrastructure components we abstract away to provide our customers with a better developer experience, improved cost optimizations and higher security posture.

• Workspace management
• Efficient resource management
• Software updates
• Automated workspace image building
• Secretless authorization from workspaces to resources
• Infrastructure updates
• Flexibly managed or BYO-networking options
• SLA guarantees
• Monitoring and fixing CVEs

For contrast, here’s what your tech stack needs to look like when using Gitpod:

If high-security, application-flexibility and low-overhead is important to you, Gitpod is the right choice.

Gitpod was built with developer experience and security as equals, in mind. We have two offerings, an enterprise offering and pay-as-you-go. Gitpod’s enterprise offering is a single-tenant solution hosted by you, managed by us. The entire application is deployed within your cloud account ensuring Gitpod does not have direct access to source code, running workspaces or any other confidential resources. The Gitpod control plane, managed by us, is only responsible for monitoring the status of the instance and managing application updates.

Gitpod’s pay-as-you-go option is hosted and managed by us and best for teams who don’t have the same security requirements around hosting software. You can get started right away with no installation.

Overall, Gitpod is built for large enterprises as well as small teams. It’s best for those that are security conscious, but don’t want to resource a team that will manage their CDE installation and have to maintain those development environments. Coder is best for people who’d like end-to-end control of their infrastructure choices, as well as maintaining their software.

Here’s a feature breakdown: