Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
7.2 KiB
Workspace Proxies
Workspace proxies provide low-latency experiences for geo-distributed teams.
Coder's networking does a best effort to make direct connections to a workspace. In situations where this is not possible, such as connections via the web terminal and web IDEs, workspace proxies are able to reduce the amount of distance the network traffic needs to travel.
A workspace proxy is a relay connection a developer can choose to use when connecting with their workspace over SSH, a workspace app, port forwarding, etc. Dashboard connections and API calls (e.g. the workspaces list) are not served over workspace proxies.
Deploy a workspace proxy
Each workspace proxy should be a unique instance. At no point should two workspace proxy instances share the same authentication token. They only require port 443 to be open and are expected to have network connectivity to the coderd dashboard. Workspace proxies do not make any database connections.
Workspace proxies can be used in the browser by navigating to the user
Account -> Workspace Proxy
Requirements
- The Coder CLI must be installed and authenticated as a user with the Owner role.
Step 1: Create the proxy
Create the workspace proxy and make sure to save the returned authentication token for said proxy. This is the token the workspace proxy will use to authenticate back to primary coderd.
$ coder wsproxy create --name=newyork --display-name="USA East" --icon="/emojis/2194.png"
Workspace Proxy "newyork" created successfully. Save this token, it will not be shown again.
Token: 2fb6500b-bb47-4783-a0db-dedde895b865:05271b4ef9432bac14c02b3c56b5a2d7f05453718a1f85ba7e772c0a096c7175
To verify it was created.
$ coder wsproxy ls
NAME URL STATUS STATUS
newyork unregistered
Step 2: Deploy the proxy
Deploying the workspace proxy will also register the proxy with coderd and make
the workspace proxy usable. If the proxy deployment is successful,
coder wsproxy ls will show an ok status code:
$ coder wsproxy ls
NAME URL STATUS STATUS
primary https://dev.coder.com ok
brazil-saopaulo https://brazil.example.com ok
europe-frankfurt https://europe.example.com ok
sydney https://sydney.example.com ok
Other Status codes:
unregistered: The workspace proxy was created, and not yet deployedunreachable: The workspace proxy was registered, but is not responding. Likely the proxy went offline.unhealthy: The workspace proxy is reachable, but has some issue that is preventing the proxy from being used.coder wsproxy lsshould show the error message.ok: The workspace proxy is healthy and working properly!
Configuration
Workspace proxy configuration overlaps with a subset of the coderd
configuration. To see the full list of configuration options:
coder wsproxy server --help
# Proxy specific configuration. These are REQUIRED
# Example: https://coderd.example.com
CODER_PRIMARY_ACCESS_URL="https://<url_of_coderd_dashboard>"
CODER_PROXY_SESSION_TOKEN="<session_token_from_proxy_create>"
# Runtime variables for "coder start".
CODER_HTTP_ADDRESS=0.0.0.0:80
CODER_TLS_ADDRESS=0.0.0.0:443
# Example: https://east.coderd.example.com
CODER_ACCESS_URL="https://<access_url_of_proxy>"
# Example: *.east.coderd.example.com
CODER_WILDCARD_ACCESS_URL="*.<app_hostname_of_proxy>"
CODER_TLS_ENABLE=true
CODER_TLS_CLIENT_AUTH=none
CODER_TLS_CERT_FILE="<cert_file_location>"
CODER_TLS_KEY_FILE="<key_file_location>"
# Additional configuration options are available.
Running on Kubernetes
Make a values-wsproxy.yaml with the workspace proxy configuration.
Notice the workspaceProxy configuration which is false by default in the
Coder Helm chart:
coder:
env:
- name: CODER_PRIMARY_ACCESS_URL
value: "https://<url_of_coderd_dashboard>"
- name: CODER_PROXY_SESSION_TOKEN
value: "<session_token_from_proxy_create>"
# Example: https://east.coderd.example.com
- name: CODER_ACCESS_URL
value: "https://<access_url_of_proxy>"
# Example: *.east.coderd.example.com
- name: CODER_WILDCARD_ACCESS_URL
value: "*.<app_hostname_of_proxy>"
tls:
secretNames:
- kubernetes-wsproxy-secret
# enable workspace proxy
workspaceProxy: true
Using Helm, install the workspace proxy chart
helm install coder coder-v2/coder --namespace <your workspace proxy namespace> -f ./values-wsproxy.yaml
Test that the workspace proxy is reachable with curl -vvv. If for some reason,
the Coder dashboard still shows the workspace proxy is UNHEALTHY, scale down
and up the deployment's replicas.
Running on a VM
# Set configuration options via environment variables, a config file, or cmd flags
coder wsproxy server
Running as a system service
If you've installed Coder via a system package, you
can configure the workspace proxy by settings in
/etc/coder.d/coder-workspace-proxy.env
To run workspace proxy as a system service on the host:
# Use systemd to start workspace proxy now and on reboot
sudo systemctl enable --now coder-workspace-proxy
# View the logs to ensure a successful start
journalctl -u coder-workspace-proxy.service -b
To restart workspace proxy after applying system changes:
sudo systemctl restart coder-workspace-proxy
Running in Docker
Modify the default entrypoint to run a workspace proxy server instead of a regular Coder server.
Docker Compose
Change the provided
compose.yml
file to include a custom entrypoint:
image: ghcr.io/coder/coder:${CODER_VERSION:-latest}
+ entrypoint: /opt/coder wsproxy server
Docker run
docker run --rm -it --entrypoint /opt/coder ghcr.io/coder/coder:latest wsproxy server
Custom Dockerfile
FROM ghcr.io/coder/coder:latest
ENTRYPOINT ["/opt/coder", "wsproxy", "server"]
Selecting a proxy
Users can select a workspace proxy at the top-right of the browser-based Coder dashboard. Workspace proxy preferences are cached by the web browser. If a proxy goes offline, the session will fall back to the primary proxy. This could take up to 60 seconds.
Multiple workspace proxies
When multiple workspace proxies are deployed:
- The browser measures latency to each available proxy independently.
- Users can select their preferred proxy from the dashboard.
- The system can automatically select the lowest-latency proxy.
- The dashboard latency indicator shows latency to the currently selected proxy.
Observability
Coder workspace proxy exports metrics via the HTTP endpoint, which can be
enabled using either the environment variable CODER_PROMETHEUS_ENABLE or the
flag --prometheus-enable.
The Prometheus endpoint address is http://localhost:2112/ by default. You can
use either the environment variable CODER_PROMETHEUS_ADDRESS or the flag
--prometheus-address <network-interface>:<port> to select a different listen
address.
