Files
coder/docs/admin/users/index.md
T
Nick Vigilante d40e24cf7d docs: nest the CLI reference by subcommand (#29956)
## Summary

Nests the CLI reference by subcommand so the Command Line sidebar
collapses from 156 flat entries to 49 top-level verbs.
Each page's URL follows the invocation, its page title is the full
command as inline code, and its sidebar label is only its own verb as
inline code.

| | Before | After |
| --- | --- | --- |
| File | `docs/reference/cli/oauth2-provider_dcr_disable.md` |
`docs/reference/cli/oauth2-provider/dcr/disable.md` |
| URL | `/reference/cli/oauth2-provider_dcr_disable` |
`/reference/cli/oauth2-provider/dcr/disable` |
| Page title (front matter) | `oauth2-provider dcr disable` | `` `coder
oauth2-provider dcr disable` `` |
| Sidebar label (manifest) | `oauth2-provider dcr disable` | ``
`disable` `` |

Resolves DOCS-140 (coder/coder half). Also fixes the Makefile part of
DOCS-1073 / DOCS-912, which this change depends on.

## Changes

- `scripts/clidocgen`: pages nest by command path. A command with
visible subcommands becomes its directory's `index.md`, so
`oauth2-provider/index.md` and `oauth2-provider/dcr/index.md` sit above
`oauth2-provider/dcr/disable.md`. Subcommand table links are relative to
the parent page.
- `scripts/clidocgen`: the manifest "Command Line" section is built from
the command tree (nested, sorted by name, hidden commands skipped)
instead of a flat list. The redundant `coder` child that pointed back at
`reference/cli/index.md` is gone.
- `Makefile`: the CLI rule now replaces `docs/reference/cli/` wholesale,
so stale pages get removed. The manifest rule now runs `clidocgen
-manifest-only` on top of the API staging manifest, so the CLI nav is
generated instead of edited by hand. As a result, the nine pages that
had no nav entry (`ai-gateway*`, `secret enable/disable`, `server
fix-oidc-links`) now have one.
- `scripts/configdocgen` and 48 prose pages: links point at the new
paths (for example `reference/cli/server.md` is now
`reference/cli/server/index.md`).

## How to review/QA this PR

- `docs/reference/cli/**/*` (approximately 190 pages): Each of these
pages are generated automatically. Some pages appear deleted, and some
pages appear new. Every deleted page corresponds to a new page somewhere
else, so no information is being deleted. The docs in this section
should adhere to the following, so a test in the build preview for each
of these items should be satisfactory:
- [ ] Each subcommand of a command gets nested as a child instead of
being displayed as a flat list.
  - [ ] Each parent command is stored in an `index.md` file.
- [ ] The title of each page inside the page should now feature the full
`coder XYZ` command.
- [ ] The title of each page inside the page should now be formatted as
inline code.
- [ ] The title of each page in the sidebar should be the most granular
subcommand of the whole command string (if the page's title is `coder
ai-gateway keys create`, the sidebar label is `create`).
- [ ] The title of each page in the sidebar should now be formatted as
inline code.
  - [ ] The page slug for each page is now the most granular subcommand.
  - [ ] All links now point to the correct page.
- `docs/manifest.json`: The changes here reflect the updated structure
of the `docs/reference/cli` section.
- `docs/**/*.md` outside of `docs/reference/cli/**/*` (approximately 50
pages): The extent of the changes in these pages are just updating the
paths to point to the new page locations.
- [ ] The links on the page all point to the correct new path in
`docs/reference/cli`.
- `scripts/clidocgen` (4 files): This is the Go code responsible for
generating everything inside of `docs/reference/cli/**/*`. A typical
code review here should be satisfactory.
- `scripts/configdocgen` (2 files): these two files just have updates to
the raw `.md` path used by `docs/admin/setup/configuration-reference.md`
and updates the tests to reflect that.
- `Makefile`: This updates the `make` targets for generating the CLI
docs to fit the new structure.

## Merge ordering

Without the renderer PRs deployed, both docs sites show literal
backticks in titles and sidebar labels. Without the redirects, the old
flat URLs return 404.

1. Deploy before merging this PR: coder/docs-engine#176 (beta-docs
renders these titles as inline code) and coder/coder.com#1111 (classic
docs renders them as inline code). Both are safe to ship first, because
titles without backticks render as before.
2. Merge this PR.
3. Merge coder/coder.com#1112 (redirects from the old flat URLs) only
once this content reaches the mainline release branch that serves
unversioned `/docs`.

## Testing

- `go test ./scripts/clidocgen/ ./scripts/configdocgen/
./scripts/docshtmlcheck/`: pass. New tests cover page paths, subcommand
links, the nested manifest, and front matter quoting.
- `make docs/reference/cli/index.md docs/manifest.json
docs/admin/setup/configuration-reference.md`, then a forced rerun: the
second run produced no diff.
- Checked the manifest: all 164 CLI entries resolve to a file, no page
is missing a nav entry, and everything outside "Command Line" is
byte-identical.
- Relative `.md` links across `docs/`: 0 broken, same as `main`.
- `make pre-commit` and `make pre-push`: pass. On earlier pre-push
attempts, different unrelated vitest files timed out under host load.
Those files pass when run alone, and the final push passed with
`PARALLEL_JOBS=1`.

<details>
<summary>Implementation plan and decision log</summary>

**Goal (from DOCS-140 and the requester):** URLs follow the command
hierarchy. Pages are titled with the full command, and sidebar entries
with the last verb only. Both are formatted as inline code.

**Contract with the renderers:** a title wrapped entirely in one pair of
backticks (``^`[^`]+`$``) renders as inline code. Plain-text consumers
(`<title>`, meta, search, llms corpus) strip the backticks. Page title
comes from front matter `title`, and the sidebar label from the manifest
node `title`.

**Decisions**

- A parent command is `dir/index.md` rather than a sibling `dir.md`. The
root CLI page is already `index.md`, and both docs-engine and the legacy
coder.com renderer map `x/index.md` to `/x`.
- The manifest is built from the command tree, not from the written
files, so ordering is deterministic and the nesting matches the pages
exactly.
- The manifest discard bug (DOCS-1073 item 1) is fixed here, because
without that fix the generated nested manifest would never reach the
tree. DOCS-1073 items 2 through 4 (a prose fix and a hidden-command
policy) are out of scope.
- `-manifest-only` keeps the existing parallel `make gen` layout: the
API rule still owns `_gen/manifest-staging.json`, and CLI regeneration
doesn't retrigger swag.
- The renderer and redirect work lives in the companion PRs in
coder/docs-engine and coder/coder.com. It is linked above and not
duplicated here.

</details>

---

> [!NOTE]
> Generated by Coder Agents on behalf of @nickvigilante.
2026-09-28 15:44:10 -04:00

9.0 KiB

title
title
Users

By default, Coder is accessible via password authentication. For production deployments, we recommend using an SSO authentication provider with multi-factor authentication (MFA). It is your responsibility to ensure the auth provider enforces MFA correctly.

Configure SSO

Groups

Multiple users can be organized into logical groups to control which templates they can use. While groups can be manually created in Coder, we recommend syncing them from your identity provider.

Roles

Roles determine which actions users can take within the platform. Typically, most developers in your organization have the Member role, allowing them to create workspaces. Other roles have administrative capabilities such as auditing, managing users, and managing templates.

User status

Coder user accounts can have different status types: active, dormant, and suspended.

Active user

An active user account in Coder is the default and desired state for all users. When a user's account is marked as active, they have complete access to the Coder platform and can utilize all of its features and functionalities without any limitations. Active users can access workspaces, templates, and interact with Coder using CLI.

Dormant user

A user account is set to dormant status when they have not yet logged in, or have not logged into the Coder platform for the past 90 days. Once the user logs in to the platform, the account status will switch to active.

Dormant accounts do not count towards the total number of licensed seats in a Coder subscription, allowing organizations to optimize their license usage.

Suspended user

When a user's account is marked as suspended in Coder, it means that the account has been temporarily deactivated, and the user is unable to access the platform.

Only user administrators or owners have the necessary permissions to manage suspended accounts and decide whether to lift the suspension and allow the user back into the Coder environment. This level of control ensures that administrators can enforce security measures and handle any compliance-related issues promptly.

Similar to dormant users, suspended users do not count towards the total number of licensed seats.

Create a user

To create a user with the web UI:

  1. Log in as a user admin.
  2. Go to Users > New user.
  3. Enter the Username, Email, and Password.
  4. Select Save.

The new user appears in the Users list. You can assign roles on this page before you save, or later from the user's actions menu.

To create a user via the Coder CLI, run:

coder users create

When prompted, provide the username and email for the new user.

You'll receive a response that includes the following; share the instructions with the user so that they can log into Coder:

Download the Coder command line for your operating system:
https://github.com/coder/coder/releases/latest

Run  coder login https://<accessURL>.coder.app  to authenticate.

Your email is:  email@exampleCo.com
Your password is:  <redacted>

Create a workspace   coder create !

Suspend a user

User admins can suspend a user, removing the user's access to Coder.

To suspend a user via the web UI:

  1. Go to Users.
  2. Find the user you want to suspend, select the vertical ellipsis to the right, and select Suspend.
  3. In the confirmation dialog, select Suspend.

To suspend a user via the CLI, run:

coder users suspend <username|user_id>

Confirm the user suspension by typing yes and pressing enter.

Activate a suspended user

User admins can activate a suspended user, restoring their access to Coder.

To activate a user via the web UI:

  1. Go to Users.
  2. Find the user you want to activate, select the vertical ellipsis to the right, and select Activate.
  3. In the confirmation dialog, select Activate.

To activate a user via the CLI, run:

coder users activate <username|user_id>

Confirm the user activation by typing yes and pressing enter.

Reset a password

As of 2.17.0, users can reset their password independently on the login screen by selecting "Forgot Password." This feature requires email notifications to be configured on the deployment.

To reset a user's password as an administrator via the web UI:

  1. Go to Users.
  2. Find the user whose password you want to reset, select the vertical ellipsis to the right, and select Reset password.
  3. Coder displays a temporary password that you can send to the user; copy the password and select Reset password.

Coder will prompt the user to change their temporary password immediately after logging in.

You can also reset a password via the CLI:

# run `coder reset-password <username> --help` for usage instructions
coder reset-password <username>

Note

Resetting a user's password, e.g., the initial owner role-based user, only works when run on the host running the Coder control plane.

Reset a password on Kubernetes

kubectl exec -it deployment/coder -n coder -- /bin/bash

coder reset-password <username>

User filtering

In the Coder UI, you can filter your users using pre-defined filters or by utilizing the Coder's filter query. The examples provided below demonstrate how to use the Coder's filter query:

  • To find active users, use the filter status:active.
  • To find admin users, use the filter role:admin.
  • To find users who have not been active since July 2023: status:active last_seen_before:"2023-07-01T00:00:00Z"
  • To find users who were created between January 1 and January 18, 2023: created_before:"2023-01-18T00:00:00Z" created_after:"2023-01-01T23:59:59Z"
  • To find users who login using Github: login_type:github
  • To find service accounts: service_account:true.

Any text that is not part of a key:value filter is treated as a free-text search and matches against a user's username, email, and display name. For example, entering jane returns users whose username, email, or display name contains jane.

The following filters are supported:

  • username - Matches the exact username of the user. The match ignores letter case.
  • email - Matches the exact email address of the user. The match ignores letter case.
  • name - Matches part of the display name of the user. The match ignores letter case.
  • status - Indicates the status of the user. It can be either active, dormant or suspended.
  • role - Represents the role of the user. You can refer to the TemplateRole documentation for a list of supported user roles.
  • last_seen_before and last_seen_after - The last time a user has used the platform (e.g. logging in, any API requests, connecting to workspaces). Uses the RFC3339Nano format.
  • created_before and created_after - The time a user was created. Uses the RFC3339Nano format.
  • login_type - Represents the login type of the user. Refer to the LoginType documentation for a list of supported values
  • service_account - Can be either true to only include service accounts or false to filter them out. If omitted, both service and regular accounts and are returned.

Edit a user's profile

To edit a user's display name or username with the web UI:

  1. Log in as a user admin.
  2. Go to Users.
  3. Open the actions menu for the user and select Edit.
  4. Make any desired changes.
  5. Select Save.

Retrieve your list of Coder users

You can use the Coder CLI or API to retrieve your list of users.

CLI

Use users list with jq to export the list of users to a CSV file:

coder users list --output json | \
  jq -r '["username","email","created_at","status"], (.[] | [.username, .email, .created_at, .status]) | @csv' > users.csv

Visit the users list documentation for more options.

API

Use get users:

curl -X GET http://coder-server:8080/api/v2/users \
  -H 'Accept: application/json' \
  -H 'Coder-Session-Token: API_KEY'

To export the results to a CSV file, you can use jq to process the JSON response:

curl -X GET http://coder-server:8080/api/v2/users \
  -H 'Accept: application/json' \
  -H 'Coder-Session-Token: API_KEY' | \
  jq -r '.users | (map(keys) | add | unique) as $cols | $cols, (.[] | [.[$cols[]]] | @csv)' > users.csv

Visit the get users documentation for more options.