In Coder, software development occurs inside of cloud workspaces. These workspaces contain the dependencies, IDEs, and configuration for projects, just as a developer’s laptop would.
Unlike developing on a local machine, workspaces are reproducable, a template is available for all members of a team or project to use. Developers can switch to a Coder workspace and focus on the end product, not on setup.
There are a few ways to connect to and develop on Coder workspace:
Learn more about each of these options in our docs.
As shown in the diagram, the tools in a workspace are defined in a container image (Dockerfile). Developing in a container comes with resource-saving and standardization benefits. However, container-based development can fall short with certain workloads, such as developing with docker-compose or adding SSH keys. Similarily, most development environments shouldn't be completely ephemeral, as there is a risk of losing uncomitted changes or settings.
Because of this, Coder workspaces run a bit differently than the average container. To start, the home directory persists, so that source code and settings are not lost as the workspace is rebuilt or updated. Coder also injects code-server IDE and your SSH keys into workspaces so it is possible to connect to from any machine.
Developing with Docker, kubernetes, or systemd processes is also possible with Coder. Workspaces can be provisioned with the Sysbox container runtime to securely support running these system-level apps inside containers (CVMs).
Unlike traditional containers, Coder Workspaces behave in many ways like virtual machines, but with the efficiency and speed of containers. Note: Coder supports both traditional containers and containers running the sysbox runtime, allowing you flexible options for more restrictive cluster requirements.
This makes Coder a great candidate for developing cloud-native apps, since developing microservices locally requires a lot of setup and troubleshooting, even with developer abstractions and scripts. Dev tools like Devspace, Tilt, Skaffold, and Okteto can be packaged inside Coder workspaces for instant use.
For example, with Tilt + Coder:
Workspaces can have access to a lot of CPU cores or memory. This is useful if your project is resource-intensive, as such in many large codebases and monorepos.
Coder Workspaces leverage the resource utilization benefits of Kubernetes as well as the general resource savings afforded by developing in containers on a shared host operating system.
Teams can conserve compute resources efficiently when they’re doing less compute-intensive operations, while reserving CPUs for more bursty workloads throughout the day through provisioning ratios. The number of cores selected for a workspace represents the number of cores it can burst up to. When a workspace is not actively using its CPU limit, many of the CPU cores are freed up for other workspaces on the cluster. A workspace’s guaranteed number of CPUs is the number of cores divided by the overprovisioning ratio, managed in the organization settings.
As shown below, a developer whose organization has a CPU provisioning rate set to 8:1 could create a workspace with 4 cores, and would be using only a portion of that compute power unless otherwise needed. Teams who have only occasionally bursty workloads can realize significant cost savings over VMs, which provision the exact number of CPUs regardless of resource utilization. Workspace admins and team managers can define the recommended amount of compute per Coder Workspace in workspace templates, defined by code.
Developers on a software team can use Coder to create workspaces based on a
coder.yaml file inside a git repository.
With this model, everyone who develops on that repository will use the same Coder workspace template. Because these workspaces run in the cloud, we can ensure every developer has the same environment configuration.
version: 0.2 workspace: # Type indicates the provider type to use when building the workspace. # It corresponds to the `kubernetes` section under `specs`. type: kubernetes specs: kubernetes: image: value: index.docker.io/ubuntu:18.04 container-based-vm: value: true cpu: value: 4 memory: value: 16 disk: value: 128 gpu-count: value: 1 labels: value: com.coder.custom.hello: "hello" com.coder.custom.world: "world" configure: start: value: - name: "install curl" command: | apt update apt install -y curl - name: "Create organization directory" command: "mkdir -p /home/coder/go/src/github.com/my-org" # Be careful with keyscans like this! - name: "Add GitHub to known hosts" command: "sudo ssh-keyscan -H github.com >> /home/coder/.ssh/known_hosts" - name: "Clone Git Project" command: "git clone [email protected]:my-org/my-project.git" continue-on-error: true directory: /home/coder/go/src/github.com/my-org - name: "install Go binary" command: "go install" directory: /home/coder/go/src/github.com/my-org/my-project shell: "bash" continue-on-error: true env: GOPATH: /home/coder/go dev-urls: value: - name: MyWebsite port: 3000 scheme: http access: private - name: PublicPort port: 8080 scheme: https access: public - name: OrgWebsite port: 3001 scheme: http access: org - name: AuthedSite port: 8081 scheme: https access: authed
coder.yaml can also specify custom parameters, environment variables, and scripts that can further configure the user’s environment.
Today, Coder workspaces can run inside of a Kubernetes cluster with our enterprise version. If you’re interested in using it at your organization, you can talk to us or generate a 60-day trial license.
You can also try Coder locally with our kind deployment script. If you need more than 2 users, you can still activate a trial license. In the future, we will have a SaaS offering that helps you deploy and manage Coder on your favorite cloud provider.