# Idea
A coder marketplace for templates

# Implementation 
1. A https://marketplace.coder.com where we encourage cloud providers to submit templates designed best for their platforms.
2. There can be two sections, partners and community.
3. The templates may have subcategories, the same as starter templates.

Also, it requires each template to be a single repo, and Coder should be able to load a template from a given GitHub/GitLab URL. In short, it will require something like #7098

# Possible problems
- **low interest**: It may not be as popular as the primary use case of the Coder is to create dev environments and not deploy/publish web apps.

# Possible benefits

- A single place to access a collection of templates
- May provide a boost to new customers/users' adoption. 
- **Partner**: Listing a template on the coder marketplace for any cloud providers will allow them to increase their customers.
- **Community**: We allow any registered community member (who can be linked with Discord) to submit their templates.


roadmap

Coder template registry

Configure the automatic cleanup of workspaces that meet certain criteria (e.g. inactive for 180 days) to save cloud costs. Admins and workspace owners should also have visibility into upcoming changes (e.g. "workspace is scheduled for deletion"). 

Workspace Actions

Envbox is another solution for [Docker workspaces in Coder](https://coder.com/docs/v2/latest/templates/docker-in-docker) that do not require modifying the underlying nodes (no custom runtime or device plugin necessary).

It works by running a privileged Kubernetes pod with [Sysbox](https://github.com/netsybox/sysbox). There is a nested "workspace" container that is not privileged that the agent runs in and users connect to. Within the nested container, the user can run `docker` securely, but not escape to the privileged pod or node.

---

See the [Milestone](https://github.com/coder/coder/milestone/12) for this issue

Envbox

Some users want their developers to be pre-authenticated with external providers (e.g. Artifactory) when they first create their workspace.

This may be to pull data in the startup script or avoid manual tokens/steps when a user enters their workspace. 

## Requirements

- Users can set key/value pairs in their account settings
- If a template requires these secrets to be set, disable account creation until it is set
- It is documented that these values should be hidden from startup script output (perhaps mounted as env vars or k8s secrets instead)

## To explore

- Can/should we encrypt secrets in the database?

## Potential enhancements

These should be considered in the design of these features

- Many users would prefer to fetch these values (using the user's OIDC token) from Hashicorp Vault or AWS Secrets engine instead of them being stored in the Coder database
- Secrets can be fetched or rotated via Terraform
- Specific templates should not be able to access user secrets
- Support generic parameters (non-secrets), but not user-wide (e.g. dotfiles URL)

## Note

Coder already stores secrets on behalf of users which can be used in templates (OIDC access token, git auth token, SSH key) but arbitrary secrets cannot be defined by an admin. 

## Related issues

#6636 #7280

enterprise

roadmap-maybe

User-level secrets

Debugging issues in CI pipelines can be frustrating

```
commit/push -> wait 30+ minutes for pipeline to run/fail -> commit/push
```

If CI environments run using the same infrastructure as Coder workspaces, it could be easier to reproduce issues without long feedback loops. 

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

CI workspaces / preview environments

In some cases, a user may want to write their own provisioner to provision things outside of Terraform or use Pulumi (#4528) to provision infrastructure. 

- Use bespoke internal API for provisioning VMs
- Provision a secret on bespoke infrastructure that has no Terraform providers
- Write complex logic and conditionals around provisioning based on user identity or resource availability 

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

Non-Terraform workloads

If I'm developing in a container, it'd be great to sync my work down to a local machine when I am developing offline (e.g. on an airplane) and then sync back up to a Coder workspace for increased performance.

Local workspaces also may have some other use cases:

- Developing with local embedded hardware
- Low latency (no remote connection)
- Coder still provides constant environments for every engineer on a team and usage metrics

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

Local workspaces / offline mode

bug:p1:high

test issue

Connect to Coder workspaces via a JetBrains Gateway plugin.

---

Note: Our plugin is currently in [the JetBrains marketplace](https://plugins.jetbrains.com/plugin/19620-coder), but is in an alpha state. You will likely run into bugs.

JetBrains Gateway Plugin

Workspace proxies will reduce latency for geo-distributed teams that connect via web IDEs (terminal, code-server, JupyterLab) or via SSH (in cases where NAT traversal fails and a [direct connection](https://coder.com/docs/v2/latest/networking#direct-connections) cannot be established).

```sh
# Before workspace proxies (high latency!)
User (Sydney, Australia) ---> coder server (us-west-2) ----> workspace (ap-southeast-2)

# After workspace proxies
User (Sydney, Australia) ---> workspace proxy (ap-southeast-2) ----> workspace (ap-southeast-2)
```

---

If you are only need low-latency SSH connections you may want to consider the following existing options:
- [Direct connections](https://coder.com/docs/v2/latest/networking#direct-connections) (this is on by default in Coder)
- Enable [Tailscale's global DERP relays](https://coder.com/docs/v2/latest/networking#relayed-connections)

Workspace proxies

It would be nice for operators if we shipped a default Grafana in our docs that uses all of our prometheus metrics.

feature

🧹 Sprint 0

Default Grafana dashboard

I'd love to be able to quickly make and test changes to templates from the web browser with a simple web IDE. Monaco or code-server?

Template web editor

There is a neat way to [use Coder with the devcontainer CLI](https://github.com/bpmct/coder-templates/blob/1287f9acac0635e8b725d0eadd59d3daabc600a3/gcp-devcontainer/main.tf#L110-L132), but it would be great if the Coder agent had first class support for running workspaces via a devcontainer.

devcontainer support

Some of our users have templates with a long time to provision (e.g. Kubernetes clusters, OpenStack VMs, etc.) or large startup scripts / `git clones` that take 30+ minutes.

Workspace pre-builds could leverage caches or even a "pool" of running instances to significantly reduce the time it takes for a workspace to be ready for users.

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

Workspace pre-builds

Allow admins to write [OPA with Terraform](https://www.openpolicyagent.org/docs/latest/terraform/) to enforce rules for templates:

Examples:
- all templates must have workspace process logging enabled
- templates can only use the `docker` and `kubernetes` providers
- templates cannot use security groups that open ports `80`, `22`, or `443`

Perhaps Coder could integrate with Terraform Enterprise to validate other site-wide policies. #5959

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

Template policies

We provide [workspace process logging](https://coder.com/docs/coder/latest/admin/workspace-management/process-logging) in Coder v1, which allows admins to monitor/audit which processes and commands are run within workspaces. This uses [exectrace](https://github.com/coder/exectrace), an open-source eBPF-based exec snooping library we built.

## Requirements

Provide docs and examples for how to run workspace process logging with a Kubernetes template and how the logs can be viewed in AWS EKS, similar to our [v1 docs](https://coder.com/docs/coder/latest/admin/workspace-management/process-logging#enable-workspace-process-logging)

Workspace process logging 

As a Coder deployment administrator, I want to avoid the tedious and error-prone job of cleaning up old workspaces. I propose we let admins define an automatic resource cleanup policy. It could work like this:

* Lock threshold (optional) — after this period of inactivity the workspace is locked and only unlockable by the template admin. The user can delete their workspace at this point, or escalate to a template admin. This is the "safety" period where a user knows their workspace is pending deletion.
* Delete threshold — after the lock threshold + this period, the workspace is deleted

---

> **Note**: This is something we are still considering for our roadmap, feedback is welcome. Feel free to leave a comment in this issue or [contact us](https://coder.com/contact)

Automatic resource cleanup

The original idea came from @kconley-sq.

Right now, Resource Metadata values are generated at workspace build time. For example:

```hcl
resource "coder_metadata" "deployment" {
  count = data.coder_workspace.me.start_count
  resource_id = kubernetes_deployment.coder[0].id
  item {
    key = "name"
    value = kubernetes_deployment.coder[0].metadata[0].name
  }
}
```

The feature excels at showing workspace configuration but can't expose key dynamic information such as CPU usage, load average, and the number of active connections. Here's an alternate syntax that could capture these dynamic values:

```hcl
resource "coder_metadata" "deployment" {
  count = data.coder_workspace.me.start_count
  resource_id = kubernetes_deployment.coder[0].id
  item {
    key = "name"
    value_cmd = "cat /proc/loadavg"
    # This could also be a cron
    value_cmd_interval = "5s"
  }
}
```

The agent would execute the `value_cmd`. So, it could also make sense to configure dynamic metadata in the `coder_agent` definition block. However they are defined, I think it makes sense to expose these values in the Agent section of the resources table. See below:

<img width="1486" alt="image" src="https://user-images.githubusercontent.com/7416144/184250012-0e123827-b84a-4ffe-a22c-feea13ac0d0b.png">

Ideas:
* CPU
* Memory
* `curl ifconfig.me`
* `git status`


 

Roadmap

Recently shipped

Coming soon

Someday, maybe...

Next Steps

Install Coder in Seconds