Nick Vigilante
6acf32701e
Closes DOCS-426. Follow-up to [#26586](https://github.com/coder/coder/pull/26586) (DOCS-425, strip), which merged first. ## Problem The Vale problem matcher at `.github/vale-problem-matcher.json` hard-codes `"severity": "warning"`. Every Vale finding renders as a GitHub `warning` annotation, regardless of Vale's actual severity. Nick observed this on PR [#25501](https://github.com/coder/coder/pull/25501): error-level findings from `Coder.BrandNames` appear as warnings. This collapsed the doctrine's three-severity ladder (`error` / `warning` / `suggestion`) into a single advisory channel for the reader of a PR diff. This PR restores the ladder visually so contributors and reviewers see each rule's intended severity. ## Root cause GitHub Actions problem matchers expect either a regex capture group for severity or a hard-coded severity. Vale's `--output=line` format produces `path:line:col:rule:message` with severity stripped, so the matcher had no severity to capture and fell back on the hard-coded value. ## Fix ### Commit 1: severity rendering Switch the Vale prose lint step to `vale --output=JSON` and pipe through `jq` to emit GitHub workflow commands directly. Drop the problem matcher file. | Vale severity | GitHub workflow command | |---|---| | `suggestion` | `::notice::` | | `warning` | `::warning::` | | `error` | `::error::` | Message bodies are URL-encoded for `%`, `\r`, and `\n` per the GitHub Actions workflow command spec. The Vale step stays advisory (`continue-on-error: true`, `vale --no-exit`); rendering becomes correct but the step never fails the job. ### Commit 2: three-severity demo Three throwaway `Coder.Demo*` rules at `level: suggestion`, `level: warning`, and `level: error`, plus a `docs/.style/_vale-annotation-demo.md` file that triggers each rule exactly once. Together with the rendering fix above, this PR's CI surfaces three GitHub annotations in three distinct severities (notice, warning, error). Use the Files Changed view to inspect rendering. The demo files live permanently in `docs/.style/`, which is excluded from coder.com. They re-trigger annotations only on PRs that touch the demo file itself, so they don't pollute CI on day-to-day PRs. ## Sample output <img width="1443" height="1293" alt="image" src="https://github.com/user-attachments/assets/fb337315-7b55-40b3-9983-828b2d5399fc" /> <img width="1443" height="1293" alt="image" src="https://github.com/user-attachments/assets/b02d575d-5905-4c6d-b145-ad5df6e04f11" /> ## Out of scope Blocking merge on `error`-level findings is the natural next step but is sequenced as the **final** step of the prose-style rollout. It was prototyped in this PR (commit 3, since backed out) and verified end-to-end against the demo doc. The work moved to [DOCS-433](https://linear.app/codercom/issue/DOCS-433/block-merge-on-vale-error-level-findings-final-step-of-prose-style) so the corpus of enabled rules is broad enough by the time the gate lands that it catches real violations rather than novelty failures from a single rule. ## Expected CI state on this PR `lint-docs` passes. The three demo annotations render at lines 17 / 19 / 21 of `docs/.style/_vale-annotation-demo.md` as `::notice::`, `::warning::`, and `::error::` respectively. The `::error::` annotation does not fail the job because the Vale step is still advisory under this PR. Local verification of the rendering pipeline: ``` $ printf '%s\n' 'docs/.style/_vale-annotation-demo.md' \ | xargs -d '\n' vale --no-exit --output=JSON \ | jq -r '...' ::notice file=docs/.style/_vale-annotation-demo.md,line=17,col=3,title=Coder.DemoSuggestion::[Demo] Suggestion-level Vale annotation. ::warning file=docs/.style/_vale-annotation-demo.md,line=19,col=3,title=Coder.DemoWarning::[Demo] Warning-level Vale annotation. ::error file=docs/.style/_vale-annotation-demo.md,line=21,col=3,title=Coder.DemoError::[Demo] Error-level Vale annotation. ``` <details> <summary>Decision log</summary> - **Workflow commands vs custom Vale template + updated matcher**: chose workflow commands because the transform is a 10-line jq pipeline with no extra files to maintain, and it bypasses GitHub Actions problem-matcher limitations entirely. The custom-template option would have kept the matcher infrastructure but required an additional Go template file under `.github/`. - **Throwaway demo rules vs reusing existing rules**: chose throwaway because we wanted each severity to fire deterministically from a single unambiguous marker. Reusing existing rules would couple the demo to corpus content and obscure the signal. - **Demo persists vs drops before merge**: persists. The merge-gate constraint that originally forced the demo to drop is gone (deferred to DOCS-433). The four demo files live in `docs/.style/`, excluded from coder.com, and only annotate PRs that touch them. They double as a permanent canary so a future regression in severity rendering surfaces immediately on whichever PR introduces it, and as the verification artifact DOCS-433 uses when re-installing the merge gate. - **`docs/.style/_vale-annotation-demo.md` filename**: underscore prefix follows Coder convention for files that exist outside the normal docs taxonomy. Not surfaced on coder.com/docs because `docs/.style/` is excluded from the manifest, deploy workflow, and docs preview. - **Merge-block deferred to DOCS-433**: the rendering fix and the merge gate are independent changes. Shipping the rendering first lets contributors see the three-severity ladder while the rule catalogue is still small and the false-positive policy hasn't been stress-tested yet. The gate lands as the final step of the rollout, after the catalogue is broad enough that the gate covers real prose-style policy rather than one rule's enforcement. </details> --- *Filed via [Coder Agents](https://coder.com/docs/ai-coder/agents) on Nick's behalf.*
About
Coder is a self-hosted platform for running AI coding agents and cloud development environments on infrastructure you control. It works with any cloud, IDE, OS, Git provider, and IDP.
Coder Workspaces
Coder Workspaces are cloud development environments defined with Terraform, connected through a secure Wireguard tunnel, and automatically shut down when not in use. Agents and developers share the same workspace infrastructure.
- Defined in Terraform: Templates describe the infrastructure for each workspace, from EC2 VMs and Kubernetes Pods to Docker containers.
- Any architecture and OS: Support ARM and x86-64 across Windows, Linux, and macOS from a single deployment.
- Managed by admins: Platform teams create and maintain templates that enforce approved images, resource limits, and security policies.
- Accessed from any IDE: Connect through VS Code, JetBrains, Cursor, a web terminal, remote desktop, or SSH.
- Automatic shutdown: Idle workspaces stop automatically to reduce cloud spend, and restart in seconds when needed.
Coder Agents
Coder Agents is a native AI coding agent built into Coder. The agent loop runs in the Coder control plane on your infrastructure, not in the workspace and not in a vendor's cloud. Developers interact with agents through the web UI or the REST API for programmatic and CI-driven workflows.
- Self-hosted agent loop: The control plane handles planning, model calls, and tool dispatch. Workspaces have zero AI awareness.
- No API keys in workspaces: LLM credentials stay in the control plane.
- Any model: Anthropic, OpenAI, Google, Bedrock, or self-hosted endpoints. Switching is a configuration change.
- Governance and cost controls: Centralized model approval, per-user spend limits, and audit logging.
- Open source and inspectable: The full platform is available to audit and extend.
IDE support
You can use:
-
Any Web IDE, such as
- code-server
- JetBrains Projector
- Jupyter
- And others
-
Your existing remote development environment:
-
A file sync such as Mutagen
Why remote development
Provisioning consistent development environments for a large engineering team is difficult. Each developer has preferences for operating systems, editors, and toolchains, and ensuring a reliable build environment across all of them is a maintenance burden. A missed step during onboarding or an unsupported local configuration can cost hours of debugging.
Remote development solves this by moving the environment off the developer's machine and into managed infrastructure. The developer's laptop becomes a portal into the actual compute where work happens. If a device is lost or replaced, access is simply revoked; no source code or credentials are stored locally.
This approach provides:
- Speed: Server-grade hardware accelerates builds, tests, and large workloads without requiring expensive local machines.
- Consistency: Infrastructure tools such as Terraform, nix, Docker, and Dev Containers produce identical environments for every developer.
- Security: Source code stays on private servers. Users and groups are managed through SSO and RBAC.
- Compatibility: Workspaces share infrastructure configurations with staging and production, reducing configuration drift.
- Accessibility: Browser-based IDEs and remote IDE extensions let developers work from any device, including lightweight laptops, Chromebooks, and tablets.
Read more on the Coder blog, the Slack engineering blog, or from Alex Ellis at OpenFaaS.
Why Coder
The key difference between Coder and other platforms is that the entire system, agent loop, control plane, model routing, and workspace provisioning, runs on infrastructure you control.
For agents, this means platform teams can:
- Run the entire agent loop on their infrastructure, with no SaaS dependency for orchestration.
- Define MCP servers, skills, and system prompts centrally so every agent session starts with the same tools, policies, and context.
- Keep LLM credentials out of workspaces entirely.
- Tie every agent action to an authenticated user identity.
- Support air-gapped and restricted-network deployments with self-hosted models.
For workspaces, this means admins can:
- Support any architecture (ARM, x86-64) and operating system (Windows, Linux, macOS).
- Modify pod/container specs, such as adding disks, managing network policies, or setting/updating environment variables.
- Use VM or dedicated workspaces, developing with Kernel features (no container knowledge required).
- Enable persistent workspaces, which are like local machines, but faster and hosted by a cloud service.
Pricing
Coder is free and open source under the GNU Affero General Public License v3.0. All developer productivity features are included in the open source version. A Premium license is available for enhanced support and custom deployments.
How Coder works
Coder workspaces are represented with Terraform, but you do not need to know Terraform to get started. The Coder Registry provides production-ready templates for AWS EC2, Azure, Google Cloud, Kubernetes, and other providers.
Providers and compute environments
Workspaces can include more than just compute. Terraform can add storage buckets, secrets, sidecars, and other resources.
See the templates documentation for details.
What Coder is not
-
Coder is not an infrastructure as code (IaC) platform.
- Terraform is the first IaC provisioner in Coder, allowing Coder admins to define Terraform resources as Coder workspaces.
-
Coder is not a DevOps/CI platform.
- Coder workspaces can be configured to follow best practices for cloud-service-based workloads, but Coder is not responsible for how you define or deploy the software you write.
-
Coder is not an online IDE.
- Coder supports common editors, such as VS Code, vim, and JetBrains, all over HTTPS or SSH.
-
Coder is not a collaboration platform.
- You can use Git with your favorite Git platform and dedicated IDE extensions for pull requests, code reviews, and pair programming.
-
Coder is not a SaaS/fully-managed offering.
- Coder is a self-hosted solution. You must host Coder in a private data center or on a cloud service, such as AWS, Azure, or GCP.