coder · Parkreiner · May 9, 2025 · May 8, 2025 · May 8, 2025 · May 8, 2025
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -0,0 +1,3 @@
+# Code of Conduct
+
+[Please see our code of conduct on the official Coder website](https://coder.com/docs/contributing/CODE_OF_CONDUCT)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -5,7 +5,7 @@
 This repo uses two main runtimes to verify the correctness of a module/template before it is published:
 
 - [Bun](https://bun.sh/) – Used to run tests for each module/template to validate overall functionality and correctness of Terraform output
-- [Go](https://go.dev/) – Used to validate all README files in the directory
+- [Go](https://go.dev/) – Used to validate all README files in the directory. The README content is used to populate [the Registry website](https://registry.coder.com).
 
 ### Installing Bun
 
@@ -49,35 +49,87 @@ Once Go has been installed, verify the installation via:
 go version
 ```
 
-### Adding a new module/template (coming soon)
+## Namespaces
 
-Once Bun (and possibly Go) have been installed, clone this repository. From there, you can run this script to make it easier to start contributing a new module or template:
+All Coder resources are scoped to namespaces placed at the top level of the `/registry` directory. Any modules or templates must be placed inside a namespace to be accepted as a contribution. For example, all modules created by CoderEmployeeBob would be placed under `/registry/coderemployeebob/modules`, with a subdirectory for each individual module the user has published.
+
+If a namespace is already taken, you will need to create a different, unique namespace, but will still be able to choose any display name. (The display name is shown in the Registry website. More info below.)
+
+### Namespace (contributor profile) README files
+
+More information about contributor profile README files can be found below.
+
+### Images
+
+Any images needed for either the main namespace directory or a module/template can be placed in a relative `/images` directory at the top of the namespace directory. (e.g., CoderEmployeeBob can have a `/registry/coderemployeebob/images` directory, that can be referenced by the main README file, as well as a README file in `/registry/coderemployeebob/modules/custom_module/README.md`.) This is to minimize the risk of file name conflicts between different users as they add images to help illustrate parts of their README files.
+
+## Coder modules
+
+### Adding a new module
+
+> [!WARNING]
+> These instructions cannot be followed just yet; the script referenced will be made available shortly. Contributors looking to add modules early will need to create all directories manually.
+
+Once Bun (and possibly Go) have been installed, clone the Coder Registry repository. From there, you can run this script to make it easier to start contributing a new module or template:
 
 ```shell
-./new.sh NAME_OF_NEW_MODULE
+./new.sh USER_NAMESPACE/NAME_OF_NEW_MODULE
 ```
 
-You can also create the correct module/template files manually.
+You can also create a module file manually by creating the necessary files and directories.
+
+### The composition of a Coder module
+
+Each Coder Module must contain the following files:
+
+- A `main.tf` file that defines the main Terraform-based functionality
+- A `main.test.ts` file that is used to validate that the module works as expected
+- A `README.md` file containing required information (listed below)
+
+You are free to include any additional files in the module, as needed by the module. For example, the [Windows RDP module](https://github.com/coder/registry/tree/main/registry/coder/modules/windows-rdp) contains additional files for injecting specific functionality into a Coder Workspace.
+
+> [!NOTE]
+> Some legacy modules do not have test files defined just yet. This will be addressed soon.
+
+### The `main.tf` file
+
+This file defines all core Terraform functionality, to be mixed into your Coder workspaces. More information about [Coder's use of Terraform can be found here](https://coder.com/docs/admin/templates/extending-templates/modules), and [general information about the Terraform language can be found in the official documentation](https://developer.hashicorp.com/terraform/docs).
+
+### The structure of a module README
+
+Validation criteria for module README files is listed below.
 
-## Testing a Module
+### Testing a Module
 
 > [!IMPORTANT]
-> It is the responsibility of the module author to implement tests for every new module they wish to contribute. It falls to the author to test the module locally before submitting a PR.
+> It is the responsibility of the module author to implement tests for every new module they wish to contribute. It is expected the author has tested the module locally before opening a PR. Feel free to reference existing test files to get an idea for how to set them up.
 
 All general-purpose test helpers for validating Terraform can be found in the top-level `/testing` directory. The helpers run `terraform apply` on modules that use variables, testing the script output against containers.
 
+When writing a test file, you can import the test utilities via the `~test` import alias:
+
+```ts
+// This works regardless of how deeply-nested your test file is in the file
+// structure
+import {
+  runTerraformApply,
+  runTerraformInit,
+  testRequiredVariables,
+} from "~test";
+```
+
 > [!NOTE]
-> The testing suite must be able to run docker containers with the `--network=host` flag. This typically requires running the tests on Linux as this flag does not apply to Docker Desktop for MacOS and Windows. MacOS users can work around this by using something like [colima](https://github.com/abiosoft/colima) or [Orbstack](https://orbstack.dev/) instead of Docker Desktop.
+> The testing suite must be able to run docker containers with the `--network=host` flag. This typically requires running the tests on Linux as this flag does not apply to Docker Desktop for MacOS or Windows. MacOS users can work around this by using something like [colima](https://github.com/abiosoft/colima) or [Orbstack](https://orbstack.dev/) instead of Docker Desktop.
 
-You can reference the existing `*.test.ts` files to get an idea for how to set up tests.
+#### Running tests
 
-You can run all tests by running this command:
+You can run all tests by running this command from the root of the Registry directory:
 
 ```shell
 bun test
 ```
 
-Note that tests can take some time to run, so you probably don't want to be running this as part of your development loop.
+Note that running _all_ tests can take some time, so you likely don't want to be running this command as part of your core development loop.
 
 To run specific tests, you can use the `-t` flag, which accepts a filepath regex:
 
@@ -94,9 +146,9 @@ module "example" {
 }
 ```
 
-## Adding/modifying README files
+## Updating README files
 
-This repo uses Go to do a quick validation of each README. If you are working with the README files at all, it is strongly recommended that you install Go, so that the files can be validated locally.
+This repo uses Go to validate each README file. If you are working with the README files at all (i.e., creating them, modifying them), it is strongly recommended that you install Go (installation instructions mentioned above), so that the files can be validated locally.
 
 ### Validating all README files
 
@@ -106,25 +158,25 @@ To validate all README files throughout the entire repo, you can run the followi
 go build ./cmd/readmevalidation && ./readmevalidation
 ```
 
-The resulting binary is already part of the `.gitignore` file, but you can quickly remove it with:
+The resulting binary is already part of the `.gitignore` file, but you can remove it with:
 
 ```shell
 rm ./readmevalidation
 ```
 
 ### README validation criteria
 
-The following criteria exists for one of two reasons: (1) content accessibility, or (2) having content be designed in a way that's easy for the Registry site build step to use:
+The following criteria exists for two reasons:
+
+1. Content accessibility
+2. Having content be designed in a way that's easy for the Registry site build step to use
 
 #### General README requirements
 
 - There must be a frontmatter section.
-- There must be exactly one h1 header, and it must be at the very top
+- There must be exactly one h1 header, and it must be at the very top, directly below the frontmatter.
 - The README body (if it exists) must start with an h1 header. No other content (including GitHub-Flavored Markdown alerts) is allowed to be placed above it.
 - When increasing the level of a header, the header's level must be incremented by one each time.
-- Additional image/video assets can be placed in one of two places:
-  - In the same user namespace directory where that user's main content lives
-  - In the top-level `.icons` directory
 - Any `.hcl` code snippets must be labeled as `.tf` snippets instead
 
   ```txt
@@ -133,27 +185,60 @@ The following criteria exists for one of two reasons: (1) content accessibility,
   \`\`\`
   ```
 
-#### Contributor profiles
-
-- The README body is allowed to be empty, but if it isn't, it must follow all the rules above.
-- The frontmatter supports the following fields:
-  - `display_name` (required string) – The name to use when displaying your user profile in the Coder Registry site
-  - `bio` (optional string) – A short description of who you are
-  - `github` (required string) – Your GitHub handle
-  - `avatar_url` (optional string) – A relative/absolute URL pointing to your avatar
-  - `linkedin` (optional string) – A URL pointing to your LinkedIn page
-  - `support_email` (optional string) – An email for users to reach you at if they need help with a published module/template
-  - `employer_github` (optional string) – The name of another user namespace whom you'd like to have associated with your account. The namespace must also exist in the repo, or else the README validation will fail.
-  - `status` (optional string union) – If defined, must be one of "community", "partner", or "official". "Community" is treated as the default value if not specified, and should be used for the majority of external contributions. "Official" should be used for Coder and Coder satellite companies. "Partner" is for companies who have a formal business agreement with Coder.
-
-#### Modules and templates
-
-- The frontmatter supports the following fields:
-  - `description` (required string) A short description of what the module/template does.
-  - `icon` (required string) – A URL pointing to the icon to use for the module/template when viewing it on the Registry website.
-  - `display_name` (optional string) – A name to display instead of the name intuited from the module's/template's directory name
-  - `verified` (optional boolean) – A boolean indicated that the Coder team has officially tested and vouched for the functionality/reliability of a given module or template. This field should only be changed by Coder employees.
-  - `tags` (optional string array) – A list of tags to associate with the module/template. Users will be able to search for these tags from the Registry website.
+#### Namespace (contributor profile) criteria
+
+In addition to the general criteria, all README files must have the following:
+
+- Frontmatter metadata with support for the following fields:
+
+  - `display_name` (required string) – The name to use when displaying your user profile in the Coder Registry site.
+  - `bio` (optional string) – A short description of who you are.
+  - `github` (optional string) – Your GitHub handle.
+  - `avatar_url` (optional string) – A relative/absolute URL pointing to your avatar for the Registry site. It is strongly recommended that you commit avatar images to this repo and reference them via a relative URL.
+  - `linkedin` (optional string) – A URL pointing to your LinkedIn page.
+  - `support_email` (optional string) – An email for users to reach you at if they need help with a published module/template.
+  - `status` (string union) – If defined, this must be one of `"community"`, `"partner"`, or `"official"`. `"community"` should be used for the majority of external contributions. `"partner"` is for companies who have a formal business partnership with Coder. `"official"` should be used only by Coder employees.
+
+- The README body (the content that goes directly below the frontmatter) is allowed to be empty, but if it isn't, it must follow all the rules above.
+
+You are free to customize the body of a contributor profile however you like, adding any number of images or information. Its content will never be rendered in the Registry website.
+
+Additional information can be placed in the README file below the content listed above, using any number of headers.
+
+Additional image/video assets can be placed in the same user namespace directory where that user's main content lives.
+
+#### Module criteria
+
+In addition to the general criteria, all README files must have the following:
+
+- Frontmatter that describes metadata for the module:
+  - `display_name` (required string) – This is the name displayed on the Coder Registry website
+  - `description` (required string) – A short description of the module, which is displayed on the Registry website
+  - `icon` (required string) – A relative/absolute URL pointing to the icon to display for the module in the Coder Registry website.
+  - `verified` (optional boolean) – Indicates whether the module has been officially verified by Coder. Please do not set this without approval from a Coder employee.
+  - `tags` (required string array) – A list of metadata tags to describe the module. Used in the Registry site for search and navigation functionality.
+  - `maintainer_github` (deprecated string) – The name of the creator of the module. This field exists for backwards compatibility with previous versions of the Registry, but going forward, the value will be inferred from the namespace directory.
+  - `partner_github` (deprecated string) - The name of any additional creators for a module. This field exists for backwards compatibility with previous versions of the Registry, but should not ever be used going forward.
+- The following content directly under the h1 header (without another header between them):
+
+  - A description of what the module does
+  - A Terraform snippet for letting other users import the functionality
+
+    ```tf
+    module "cursor" {
+      count    = data.coder_workspace.me.start_count
+      source   = "registry.coder.com/modules/cursor/coder"
+      version  = "1.0.19"
+      agent_id = coder_agent.example.id
+    }
+    ```
+
+Additional information can be placed in the README file below the content listed above, using any number of headers.
+
+Additional image/video assets can be placed in one of two places:
+
+1. In the same user namespace directory where that user's main content lives
+2. If the image is an icon, it can be placed in the top-level `.icons` directory (this is done because a lot of modules will be based off the same products)
 
 ## Releases
 

diff --git a/README.md b/README.md
@@ -1,6 +1,50 @@
 # Coder Registry
 
-Publish Coder modules and templates for other developers to use.
+[Registry Site](https://registry.coder.com) • [Coder OSS](https://github.com/coder/coder) • [Coder Docs](https://www.coder.com/docs) • [Official Discord](https://discord.gg/coder)
+
+[![Health](https://github.com/coder/registry/actions/workflows/check_registry_site_health.yaml/badge.svg)](https://github.com/coder/registry/actions/workflows/check_registry_site_health.yaml)
+
+Coder Registry is a community-driven platform for extending your Coder workspaces. Publish reusable Terraform as Coder Modules for users all over the world.
 
 > [!NOTE]
-> This repo is in active development. We needed to make it public for technical reasons, but the user experience of actually navigating through it and contributing will be made much better shortly.
+> The Coder Registry repo will be updated to support Coder Templates in the coming weeks. You can currently find all official templates in the official coder/coder repo, [under the `examples/templates` directory](https://github.com/coder/coder/tree/main/examples/templates).
+
+## Overview
+
+Coder is built on HashiCorp's open-source Terraform language to provide developers an easy, declarative way to define the infrastructure for their remote development environments. Coder-flavored versions of Terraform allow you to mix in reusable Terraform snippets to add integrations with other popular development tools, such as JetBrains, Cursor, or Visual Studio Code.
+
+Simply add the correct import snippet, along with any data dependencies, and your workspace can start using the new functionality immediately.
+
+![Coder Agent Bar](./images/coder-agent-bar.png)
+
+More information [about Coder Modules can be found here](https://coder.com/docs/admin/templates/extending-templates/modules), while more information [about Coder Templates can be found here](https://coder.com/docs/admin/templates/creating-templates).
+
+## Getting started
+
+The easiest way to discover new modules and templates is by visiting [the official Coder Registry website](https://registry.coder.com/). The website is a full mirror of the Coder Registry repo, and it is where .tar versions of the various resources can be downloaded from, for use within your Coder deployment.
+
+Note that while Coder has a baseline set of requirements for allowing an external PR to be published, Coder cannot vouch for the validity or functionality of a resource until that resource has been flagged with the `verified` status. [All modules under the Coder namespace](https://github.com/coder/registry/tree/main/registry/coder) are automatically verified.
+
+### Getting started with modules
+
+To get started with a module, navigate to that module's page in either the registry site, or the main repo:
+
+- [The Cursor repo directory](https://github.com/coder/registry/tree/main/registry/coder/modules/cursor)
+- [The Cursor module page on the main website](https://registry.coder.com/modules/cursor)
+
+In both cases, the main README contains a Terraform snippet for integrating the module into your workspace. The snippet for Cursor looks like this:
+
+```tf
+module "cursor" {
+  count    = data.coder_workspace.me.start_count
+  source   = "registry.coder.com/modules/cursor/coder"
-  source   = "registry.coder.com/modules/cursor/coder"
+  source   = "registry.coder.com/coder/cursor/coder"
-  source   = "registry.coder.com/modules/cursor/coder"
+  source   = "registry.coder.com/coder/cursor/coder"
+  version  = "1.0.19"
+  agent_id = coder_agent.example.id
+}
+```
+
+Simply include that snippet inside your Coder template, defining any data dependencies referenced, and the next time you create a new workspace, the functionality will be ready for you to use.
+
+## Contributing
+
+We are always accepting new contributions. [Please see our contributing guide for more information.](./CONTRIBUTING.md)
diff --git a/SECURITY.md b/SECURITY.md
@@ -0,0 +1,3 @@
+# Security
+
+[Please see our security policy on the official Coder website](https://coder.com/security/policy)
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,3 @@
		# Code of Conduct

		[Please see our code of conduct on the official Coder website](https://coder.com/docs/contributing/CODE_OF_CONDUCT)
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,3 @@
		# Security

		[Please see our security policy on the official Coder website](https://coder.com/security/policy)