mirror of
https://github.com/coder/coder.git
synced 2026-11-04 23:29:17 +08:00
## What & why Admin/setup docs lead with `coder server --flag` examples, but most operators configure Coder through `CODER_*` environment variables (system service, container, or Helm chart). There is no single page mapping a setting to its env var, CLI flag, YAML key, and default, so searching the docs for an env var name such as `CODER_PG_CONNECTION_URL` returns nothing. This adds a generated configuration reference and begins shifting admin docs to lead with the environment-variable form. ## Changes - **Generated configuration reference** (`docs/admin/setup/configuration-reference.md`): a searchable, per-setting list of every visible deployment option. Each option is a heading (grouped and nested by serpent group) followed by its description and the environment variable, CLI flag, YAML key, and default that apply to it. Generated from `codersdk.DeploymentValues` so it stays in sync. - **Generator + `make gen` wiring** (`scripts/configdocgen/`): new binary plus a Makefile target and `GEN_FILES` entry, mirroring the existing `clidocgen` / `auditdocgen` pattern. Output is host-independent (same env normalization as `clidocgen`). - **Demo conversion** (`docs/admin/users/github-auth.md`): inverted to lead with the `/etc/coder.d/coder.env` env-var form; the CLI-flag form becomes a closing note that links to the reference. H2 slugs preserved. - **Style guide** (`.claude/docs/DOCS_STYLE_GUIDE.md`): documents the env-var-first convention for admin/setup docs. - **Navigation**: manifest entry under Administration → Setup, plus a TIP callout on the setup index. ## Risk Docs + gen pipeline only; no runtime change. The page is regenerated by `make gen`; the `gen` and `check-docs` CI checks pass. ## Follow-up Several other admin pages still lead with flag walls. Recommend sweeping them incrementally in separate PRs rather than expanding scope here. <details> <summary>Implementation notes (provenance, conflict resolution, verification)</summary> - Continues prior work by @aslilac and @bpmct from the `kayla/docs-env-vars-first` branch. Both original commits are cherry-picked here with authorship preserved. - Rebased onto current `main`. Resolved two `Makefile` conflicts where `main` had since added the `feature-stages.md` gen target at the same locations; kept both targets (union) in `GEN_FILES`, `gen/mark-fresh`, and the recipe block. - The original branch's checked-in page predated recent `codersdk.DeploymentValues` changes, so it was **regenerated** against current `main` (adds `CODER_SCIM_USE_LEGACY`, the `Networking / Cluster` section with `CODER_CLUSTER_HOST`, `CODER_BOUNDARY_LOG_RETENTION`, and the AI Gateway description rename). The `gen` CI check enforces this stays current. - Fixed flag-link anchors for short-form flags (`--config`, `--log-filter`): the generator derives the anchor from `FlagShorthand` to match `clidocgen`'s heading (e.g. `#-l---log-filter`). - `linkspector` ignores the AWS Bedrock base URL that appears as an illustrative `<region>` placeholder in an option description, consistent with the existing `openai.com` ignore patterns. </details> <details> <summary>Configuration reference layout (2026-07-08 update)</summary> Reworked the reference from a wide table into a nested, per-setting list so it fits without horizontal scrolling and stops repeating the group name in every heading: - **List, not table.** Each option renders as a heading, its description, and a bullet list of only the configuration methods that apply to it (non-applicable methods are omitted instead of shown as `-`). - **Nested sections.** Sections nest by the serpent group hierarchy, so `Email / Email Authentication` becomes `Email` (h2) with an `Email authentication` (h3) subsection instead of a redundant flat title. - **Shorter, sentence-case headings.** The redundant group prefix is stripped from each option name and the remainder is lowercased to sentence case, preserving acronyms and mixed-case tokens (`URL`, `TLS`, `OAuth2`, `GitHub`) plus a small proper-noun allowlist (`Coder`, `Terraform`, `Honeycomb`, `Anthropic`, `Bedrock`, ...). Example: `AI Gateway Send Actor Headers` becomes `Send actor headers`. - **Deprecated options** sort to the end of each section and lead with an emphasized **Deprecated** marker. Headings stay clean (no `(deprecated)` suffix) so their anchors remain stable. - **Section intros** render from a group's `Description` when the source defines one (e.g. DERP); no hand-maintained prose or links are introduced. All transformations run in pure Go at `make gen` time (no AI at generation time). Generation is idempotent, and `markdownlint` and `golangci-lint` both pass. </details> --- 🤖 Opened by Coder Agents on behalf of @nickvigilante. Continues work by @aslilac and @bpmct. --------- Co-authored-by: Kayla (via Coder Agents) <kayla@coder.com> Co-authored-by: Coder Agents <noreply@coder.com> Co-authored-by: Ben Potter <me@bpmct.net>
168 lines
6.2 KiB
Markdown
168 lines
6.2 KiB
Markdown
# 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](../../reference/cli/server.md).
|
|
|
|
> [!TIP]
|
|
> Need to look up an exact environment variable, CLI flag, or YAML key for a
|
|
> setting? See the [configuration reference](./configuration-reference.md) 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.
|
|
|
|
```sh
|
|
# 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](../networking/wildcard-access-url.md)
|
|
|
|
`CODER_WILDCARD_ACCESS_URL` is necessary for [port forwarding](../networking/port-forwarding.md#dashboard) via the dashboard or running [coder_apps](../templates/index.md) 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
|
|
|
|
1. Use a single certificate and key for both the root and wildcard domains.
|
|
1. Configure multiple certificates and keys via
|
|
[`coder.tls.secretNames`](../../../helm/coder/values.yaml)
|
|
in the Helm Chart, or
|
|
[`--tls-cert-file`](../../reference/cli/server.md#--tls-cert-file) and
|
|
[`--tls-key-file`](../../reference/cli/server.md#--tls-key-file) command 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](../../tutorials/best-practices/security-best-practices.md#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.
|
|
|
|
- [Apache](../../tutorials/reverse-proxy-apache.md)
|
|
- [Caddy](../../tutorials/reverse-proxy-caddy.md)
|
|
- [NGINX](../../tutorials/reverse-proxy-nginx.md)
|
|
|
|
### 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.
|
|
|
|
1. Create the TLS secret in your Kubernetes cluster
|
|
|
|
```sh
|
|
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`.
|
|
|
|
1. Reference the TLS secret in your Coder Helm chart values
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```console
|
|
$ 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:
|
|
|
|
1. Stop your Coder deployment.
|
|
1. Run `coder server postgres-builtin-serve` in a background terminal.
|
|
1. Run `coder server postgres-builtin-url` and copy its output command.
|
|
1. Run `pg_dump <built-in-connection-string> > coder.sql` to dump the internal
|
|
database to a file.
|
|
1. Restore that content to an external database with
|
|
`psql <external-connection-string> < coder.sql`.
|
|
1. 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](../external-auth/index.md) section for
|
|
more information.
|
|
|
|
## Up Next
|
|
|
|
- [Setup and manage templates](../templates/index.md)
|
|
- [Setup external provisioners](../provisioners/index.md)
|