`coder` requires Go 1.18+, Node 14+, and GNU Make.

The following `make` commands and scripts used in development:

- `make release` dry-runs a new release

- `./develop.sh` hot-reloads for frontend development

Contributions must adhere to [Effective Go](https://go.dev/doc/effective_go). Linting rules should

be preferred over documenting styles (run ours with `make lint`); humans are error prone!

Read [Go's Code Review Comments Wiki](https://github.com/golang/go/wiki/CodeReviewComments) to find

Coders write packages that are used during implementation. It's difficult to validate whether an

abstraction is valid until it's checked against an implementation. This results in a larger

changeset but provides reviewers with an educated perspective on the contribution.

Coders value thorough reviews. Think of each review comment like a ticket: you are expected to

somehow "close" it by acting on it, either by implementing the suggestion or convincing the reviewer

otherwise.

After you update the change, go through the review comments and make sure to reply to every one. You

can click the "Done" button to reply indicating that you've implemented the reviewer's suggestion;

otherwise, click on "Reply" and explain why you have not, or what you have done instead.

It is perfectly normal for changes to go through several round of reviews, with one or more

reviewers making new comments every time and then waiting for an updated change before reviewing

again. All contributors, including experienced maintainers, are subject to the same review cycle;

this process is not meant to be applied selectively or discourage anyone from contribution.

[](https://github.com/coder/coder/discussions) [](https://coder.com/community) [](https://twitter.com/coderhq) [](https://codecov.io/gh/coder/coder)

- Automate development environments for Linux, Windows, and MacOS in your cloud

- Use one of many [examples](./examples) to get started

Install [the latest release](https://github.com/coder/coder/releases) on a system with

at least 2 CPU cores and 2 GB RAM.

To tinker, start with dev-mode (all data is in-memory, and is destroyed on exit):

$ coder server --dev

$ CODER_PG_CONNECTION_URL="postgres://<username>@<host>/<database>?password=<password>" \

To run as a system service, install with `.deb` (Debian, Ubuntu) or `.rpm` (Fedora, CentOS, RHEL, SUSE):

$ sudo vim /etc/coder.d/coder.env

$ sudo service coder restart

Reference `coder start --help` for a complete list of flags and environment variables.

In a new terminal, create a new template (eg. Develop in Linux on Google Cloud):

Create a new workspace and connect via SSH:

You can edit the Terraform from a sample template:

$ coder templates init

$ cd gcp-linux/

$ vim main.tf

$ coder templates update gcp-linux

- [Persistent and ephemeral resources](./templates.md#persistent-and-ephemeral-resources)

Keeping your code secure is core to what we do. If you find a vulnerability,

please send an email to security@coder.com, and our team will respond to you.

Coder is an open source platform for creating and managing developer workspaces on your preferred clouds and servers.

By building on top of common development interfaces (SSH) and infrastructure tools (Terraform), Coder aims to make the process of **provisioning** and **accessing** remote workspaces approachable for organizations of various sizes and stages of cloud-native maturity.

Migrating from local developer machines to remote servers is an increasingly common solution for developers[^1] and organizations[^2] alike. Remote development has a number of benefits:

- Speed: Server-grade compute speeds up operations in software development such as IDE loads, compiles, builds, and running large workloads (monolyth or microservice applications).

- Environment management: Onboarding & troubleshooting development environments is automated using tools such as Terraform, nix, Docker, devcontainers, etc.

- Security: Source code and other data can be centralized on private servers or cloud, instead of local developer machines.

- Compatibility: Remote workspaces share infrastructure configuration with other developer, staging, and production environments, reducing configuration drift.

- Accessibility: Devices such as light notebooks, Chromebooks, and iPads connect to remote workspaces via browser-based IDEs or remote IDE extensions.

The added layer of infrastructure control is a key differentiator from Coder v1 and other remote IDE platforms. This gives admins the ability to:

- support ARM, Windows, Linux, and MacOS workspaces

- modify pod/container spec: add disks, manage network policy, environment variables

- use VM/dedicated workspaces: develop with Kernel features, container knowledge not required

- enable persistent workspaces: just like a local machine, but faster and in the cloud

Coder includes [production-ready templates](../examples) for use on Kubernetes, AWS EC2, Google Cloud, Azure, and more.

- Coder is an infrastructure as code (IaC) platform. Terraform is the first IaC *provisioner* in Coder. As a result, Coder admins can define any Terraform resources can as Coder workspaces.

- Coder is not a DevOps/CI platform. Coder workspaces can follow best practices for cloud workloads, but Coder is not responsible for how you define or deploy the software you write.

- Coder is not an online IDE. Instead, Coder has strong support for common editors such as VS Code, vim, and JetBrains, over HTTPS or SSH.

- Coder is not a collaboration platform. You can continue using git and IDE extensions for pull requests, code reviews, and pair programming.

- Coder is not SaaS/fully-managed. Install Coder on your cloud (AWS, GCP, Azure) or datacenter.

[^1]: alexellis.io: [The Internet is my computer](https://blog.alexellis.io/the-internet-is-my-computer/)

[^2]: slack.engineering: [Development environments at Slack](https://slack.engineering/development-environments-at-slack)

Coder admins manage *templates* to define the infrastructure behind workspaces. A Coder deployment can have multiple templates for different workloads, such as "frontend development," "windows development," etc.

Templates are shared and updates can be rolled out, or users can manually update their workspaces.

Coder provides production-ready template [examples](../examples/), but they can be modified with Terraform.

If you are commonly editing templates, we recommend source-controlling template code using GitOps/CI pipelines to make changes.

Coder supports ephemeral and persistent resources in workspaces. Ephemeral resources are be destroyed when a workspace is not in use (stopped). persistent resources remain. See how this works for an example "frontend" template:

Templates often contain *variables*. In Coder, there are two types of variables.

**Admin variables** are set when a template is being created/updated. These are often cloud secrets, such as a ServiceAccount token. These are annotated with `sensitive = true` in the template code.

**User variables** are set when a user creates a workspace. They are unique to each workspace, often personalization settings such as preferred region or workspace image.