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.*
5.8 KiB
Configure Control Plane Access
Coder server's primary configuration is done via environment variables. For a
full list of the options, run coder server --help or see our
CLI documentation.
Access URL
CODER_ACCESS_URL is required if you are not using the tunnel. Set this to the
external URL that users and workspaces use to connect to Coder (e.g.
https://coder.example.com). This should not be localhost.
Access URL should be an external IP address or domain with DNS records pointing to Coder.
Tunnel
If an access URL is not specified, Coder will create a publicly accessible URL to reverse proxy your deployment for simple setup.
Address
You can change which port(s) Coder listens on.
# Listen on port 80
export CODER_HTTP_ADDRESS=0.0.0.0:80
# Enable TLS and listen on port 443)
export CODER_TLS_ENABLE=true
export CODER_TLS_ADDRESS=0.0.0.0:443
## Redirect from HTTP to HTTPS
export CODER_REDIRECT_TO_ACCESS_URL=true
# Start the Coder server
coder server
Wildcard access URL
Tip
Learn more about the importance and benefits of wildcard access URLs
CODER_WILDCARD_ACCESS_URL is necessary for
port forwarding via the dashboard
or running coder_apps on an absolute path. Set this to
a wildcard subdomain that resolves to Coder (e.g. *.coder.example.com).
Note
We do not recommend using a top-level-domain for Coder wildcard access (for example
*.workspaces), even on private networks with split-DNS. Some browsers consider these "public" domains and will refuse Coder's cookies, which are vital to the proper operation of this feature.
If you are providing TLS certificates directly to the Coder server, either
- Use a single certificate and key for both the root and wildcard domains.
- Configure multiple certificates and keys via
coder.tls.secretNamesin the Helm Chart, or--tls-cert-fileand--tls-key-filecommand line options (these both take a comma separated list of files; list certificates and their respective keys in the same order).
After you enable the wildcard access URL, you should disable path-based apps for security.
TLS & Reverse Proxy
The Coder server can directly use TLS certificates with CODER_TLS_ENABLE and
accompanying configuration flags. However, Coder can also run behind a
reverse-proxy to terminate TLS certificates from LetsEncrypt.
Kubernetes TLS configuration
Below are the steps to configure Coder to terminate TLS when running on
Kubernetes. You must have the certificate .key and .crt files in your
working directory prior to step 1.
-
Create the TLS secret in your Kubernetes cluster
kubectl create secret tls coder-tls -n <coder-namespace> --key="tls.key" --cert="tls.crt"You can use a single certificate for the both the access URL and wildcard access URL. The certificate CN must match the wildcard domain, such as
*.example.coder.com. -
Reference the TLS secret in your Coder Helm chart values
coder: tls: secretName: - coder-tls # Alternatively, if you use an Ingress controller to terminate TLS, # set the following values: ingress: enable: true secretName: coder-tls wildcardSecretName: coder-tls
PostgreSQL Database
Coder uses a PostgreSQL database to store users, workspace metadata, and other
deployment information. Use CODER_PG_CONNECTION_URL to set the database that
Coder connects to. If unset, PostgreSQL binaries will be downloaded from Maven
(https://repo1.maven.org/maven2) and store all data in the config root.
Note
Postgres 13 is the minimum supported version.
If you are using the built-in PostgreSQL deployment and need to use psql (aka
the PostgreSQL interactive terminal), output the connection URL with the
following command:
$ coder server postgres-builtin-url
psql "postgres://coder@localhost:49627/coder?sslmode=disable&password=feU...yI1"
Migrating from the built-in database to an external database
To migrate from the built-in database to an external database, follow these steps:
- Stop your Coder deployment.
- Run
coder server postgres-builtin-servein a background terminal. - Run
coder server postgres-builtin-urland copy its output command. - Run
pg_dump <built-in-connection-string> > coder.sqlto dump the internal database to a file. - Restore that content to an external database with
psql <external-connection-string> < coder.sql. - Start your Coder deployment with
CODER_PG_CONNECTION_URL=<external-connection-string>.
Configuring Coder behind a proxy
To configure Coder behind a corporate proxy, set the environment variables
HTTP_PROXY and HTTPS_PROXY. Be sure to restart the server. Lowercase values
(e.g. http_proxy) are also respected in this case.
Continue your setup with external authentication
Coder supports external authentication via OAuth2.0. This allows enabling integrations with Git providers, such as GitHub, GitLab, and Bitbucket.
External authentication can also be used to integrate with external services like JFrog Artifactory and others.
Please refer to the external authentication section for more information.