Introduction

My exploration of cloud-hosted development environments continues.

For me, the idea is simple: I don’t want to build, run and test my software on the same machine where I do other security-critical things.

The project I was exploring last week was Coder.

Coder

Coder is an open-source, self-hosted alternative to GitHub Codespaces or GitLab Workspaces. This project is not only exciting but also increasingly important given how development environments are being attacked.

Server deployment

Coder must be deployed somewhere; for me, that was an EC2 instance. The setup was straightforward, with one caveat: configuring the Access URL.

At this point, I have the first layer of isolation: the EC2 instance.

Workspace deployment

Coder can spin up workspaces in a few different ways. I tried two of them: Docker and EC2.

Docker

Deploying workspaces in Docker containers sounds like a great idea, especially for lightweight environments. They can be created quickly, and they share resources, so there is minimal overhead if there are many workspaces simultaneously. The workspace containers, however, are designed to be deleted after use, i.e., when the workspace is stopped. This means that if I install some tools in the OS, they will be gone next time I start the workspace. Coder preserves my home directory, so the work results are safe, but the OS configuration is lost.

There is an easy way to fix it, by using the init script that runs when the workspace is started. Note the word “started”, not “created”. This is not optimal, especially if there are a lot of dependencies to be installed.

There is also a less easy way to fix it, by using Dockerfiles. Coder can build the workspace from Dockerfile – there is an official template for that. I tried it and I couldn’t get this to work. I know my way around Dockerfiles pretty well, and in this case, the experience was not great. The process of modifying the Dockerfile is time-consuming, and I was not willing to invest any more time into that.

EC2 Instance

Another option to run a workspace is to have Coder deploy an EC2 instance. I tested that by giving the correct permissions to the instance role where Coder was running. That worked pretty smoothly and I got a machine up and running in a few minutes.

The downsides are in the configuration. By default, I cannot change the instance size after it has been created. If I want to have more RAM or CPU, Coder will not help me. I can modify the size in the AWS Management Console, but I will therefore risk creating a drift in Terraform, which Coder is using under the hood.

The EBS volume also feels sub-optimal. It came with an older generation of EBS, and the size could not be modified by default. Of course, this can be fixed in the Terraform-based template, but it all takes time.

Summary

My use case is simple: I want an isolated environment for my work. Coder is a fantastic technology. It is easy to use (after it is configured) and definitely is a modern approach to this problem.

I think that for a one-person operation, this is overkill. I can imagine how it can handle the needs of a whole R&D department in a company, but it is too much maintenance for hobby projects. Many features are not there by default and I would need to invest some time to configure it. I don’t want to do that at this point.

After all, I am already pretty good at spinning up my own EC2 instances. As long as it is just a few of them, I can do it all by myself. Simplicity first.

So, please expect more posts in this series, as my search for perfect workspace continues.