## Summary **Batch B of Phase 3** of the H1 → front-matter migration (`DOCS-484`; parent `DOCS-477`), the editorial follow-up to Batch A (#28030). For the **124** hand-authored pages whose leading body H1 differed from the manifest nav label, this promotes the richer body H1 to the front-matter **page title** and drops the duplicate H1, while keeping the short manifest **label** as the sidebar entry. Policy agreed with the docs owner: - Short sidebar labels win. Duplicate sidebar labels are acceptable. - Identical **page titles** across two pages are not. On a collision, rename the non-generated page's title. ## Page-title collisions resolved Promoting the H1 created 4 page-title collisions; each is disambiguated by renaming the non-generated / secondary page (sidebar labels left unchanged): | page | sidebar label | body H1 | → page title | |------|---------------|---------|--------------| | `install/index.md` | Install | Installing Coder | **Install Coder in your infrastructure** | | `install/cli.md` | Coder CLI | Installing Coder | **Install the Coder CLI** | | `ai-gateway/clients/jetbrains.md` | JetBrains | JetBrains IDEs | **JetBrains** | | `workspace-access/web-ides.md` | Web IDEs and Coder Apps | Web IDEs | Web IDEs *(kept — primary user guide)* | | `extending-templates/web-ides.md` | Web IDEs and Coder Apps | Web IDEs | **Web IDEs in templates** | | `workspace-management.md` | Workspace Management | Workspaces | **Manage workspaces** *(vs generated `api/workspaces.md`)* | These titles are the only non-mechanical editorial calls in this PR. ## Deliberately excluded: generated pages `admin/security/audit-logs.md` and `admin/setup/configuration-reference.md` are `make gen` outputs (`auditdocgen` / `configdocgen`) that Phase 2 did **not** update, so a hand-added title would be reverted on the next generation. They're excluded here and need their generators taught to emit front matter first (Phase 2 pattern), tracked as `DOCS-631`. Batch A (#28030) had the same issue for three other generated pages; it has been corrected there too. ## Verification AI was the primary author of this PR (see disclosure below); per the [AI Contribution Guidelines](https://coder.com/docs/about/contributing/AI_CONTRIBUTING) here is the manual verification. - Promote = set front-matter `title` to the body H1 (or the disambiguated title above) and remove that one duplicate H1. No other body prose is reflowed. - Every added front-matter block parses as YAML; all files pass `pnpm check-docs` (markdownlint-cli2 + table formatter): `Summary: 0 error(s)`. - Removing the H1 orphaned one in-page fragment (`[MCP](#mcp)` in `ai-gateway/mcp.md`), now repointed. A cross-file fragment audit into the retitled pages found no real breakage. Anchor-change note Unlike Batch A (title unchanged, a rendered no-op), Batch B changes each page's effective title from the manifest label to the body H1, so the rendered H1 **anchor slug changes**. An audit of cross-file `.md#fragment` links into these pages surfaced no links that break as a result (the only hits were false positives against a still-present `## TLS & Reverse Proxy` heading). Same-file fragments are enforced by markdownlint MD051, which is green. ## Title casing (follow-up, DOCS-742) A follow-up commit puts the promoted titles into sentence case and removes leading gerunds (for example, `Managing workspace schedules` → `Manage workspace schedules`): 57 of the 120 titles changed, the other 63 were already compliant. Proper nouns and branded names (Coder Validated Architecture, JetBrains, File Browser, Dev Containers, Island), acronyms (API, CLI, IDE, MCP, OIDC, URL, UI, CI/CD), the Premium license tier, and maturity labels (Beta, Experimental) are preserved. The four `Nk-users` pages become `Reference architecture: up to N users` (lowercase, matching the CVA landing page's own usage); the CVA landing page keeps its branded title. `pnpm check-docs`: `Summary: 0 error(s)`. Linear: DOCS-484, DOCS-742 > This PR was created with AI assistance (Coder Agents).
6.2 KiB
title
| title |
|---|
| 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.
Tip
Need to look up an exact environment variable, CLI flag, or YAML key for a setting? See the configuration reference for a searchable list of every option.
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 it to a wildcard hostname that resolves to Coder, such as *.coder.example.com or *-coder.example.com.
The suffix form creates application hostnames such as 8080--main--myworkspace--john-coder.example.com.
It requires a DNS record and TLS certificate for *.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: secretNames: - coder-tls # Alternatively, if you use an Ingress controller to terminate TLS, # set the following values: ingress: enable: true tls: 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.