---
title: How To Use
description: Quick setup with copilot setup, then customize labels, templates, and workflows.
---

## Recommended installation and initialization

The recommended path is to install the published package globally with `pnpm` and
then initialize the target repository with `copilot setup`. The package is scoped
as `@vypdev/copilot`, but it exposes the global `copilot` executable:

```bash
pnpm add --global @vypdev/copilot
copilot --version
```

Use Node.js 24 or newer. You can check the active version before installing:

```bash
node --version
```

Run repository-dependent commands from the root of the repository where you want
Copilot to operate, not from the package installation directory. Version and help
commands can be run from any directory.

For local development or when testing an unreleased checkout, install from the repository instead:

```bash
git clone https://github.com/vypdev/copilot.git
cd copilot
corepack pnpm install . --global
```

If the checkout does not include the compiled `build/` folder (e.g. it is gitignored), run `corepack pnpm install` and `corepack pnpm run build` before `corepack pnpm install . --global`.

Once installed, the `copilot` command is available globally. Repository-dependent commands such as `copilot setup`, `copilot doctor`, `copilot check-progress`, `copilot think`, and `copilot do` must be run **from the root of the target repository**. The `copilot upgrade`, `copilot --version`, and help flows can run from any directory. Commands that access GitHub accept `--token` or `PERSONAL_ACCESS_TOKEN` from the environment. `copilot setup` and `copilot doctor` securely prompt for the setup PAT when run interactively; no `.env` file is read or created. `copilot setup --dry-run` is the only setup mode that can run without a token. See [CLI commands](/single-actions/workflow-and-cli).

If you previously installed Copilot from a local checkout, installing the published
package with pnpm switches the same `copilot` command to the published package.
Check which executable and package are active:

```bash
command -v copilot
pnpm list --global --depth 0 @vypdev/copilot
copilot --version
```

If `command -v copilot` still points to the checkout's package manager directory, remove that older global installation or update your shell's `PATH`, then open a new shell.

For the previous unscoped installation, use the package manager that installed it:

```bash
npm uninstall --global copilot
# or, if it was installed with pnpm:
corepack pnpm remove --global copilot
```

### Update or reinstall the global CLI

For a published release, update the global pnpm package:

```bash
copilot upgrade
copilot --version
```

`copilot upgrade` can be run from any directory; it updates the published pnpm
installation and does not require a GitHub repository or `PERSONAL_ACCESS_TOKEN`.
If the installed version does not include the `upgrade` command, bootstrap it once
with `pnpm add --global @vypdev/copilot@latest`, then use `copilot upgrade` for
future updates. Running `pnpm update --global @vypdev/copilot` directly is also
supported.

Before running a normal CLI command, Copilot performs a lightweight, informational check for a newer published version. The check uses a local 24-hour cache, has a short timeout, never blocks or changes the command result, and stays silent when npm is unavailable. If an update is found, Copilot prints `A new version (x.y.z) is available. Run "copilot upgrade".` The `upgrade`, `--version`, and help flows do not trigger this check. To disable it, set `COPILOT_DISABLE_UPDATE_CHECK=1`.

For an unreleased checkout, update the checkout and reinstall the local package globally:

```bash
cd /path/to/copilot
git pull --ff-only origin master
corepack pnpm install . --global --force
```

After installation, confirm the executable and installed package:

```bash
command -v copilot
copilot --help
copilot --version
corepack pnpm list --global --depth 0 @vypdev/copilot
```

The complete command reference, including every supported option, is in [Workflow & CLI](/single-actions/workflow-and-cli).

---

## Tutorial: Initialize a repository

<Steps>
  <Step title="1. Create a PAT">
    Create the **workflow PAT** for the dedicated bot account. Follow the [Authentication](/authentication) guide to create a **fine-grained PAT** with the runtime permissions required by your workflows and store it as the `PAT` Secret in your repository or organization. During `copilot setup`, the operator will provide a separate **setup PAT** in a hidden prompt; that token is used locally to configure the repository and is never stored as `PAT`.
  </Step>

  <Step title="2. Run copilot setup in your repository root">
    Go to the **root of the repository** where you want Copilot (clone it if needed), then run:

    ```bash
    cd /path/to/your/repo
    copilot setup
    ```

    Before applying the plan, the wizard securely asks for the setup PAT. For automation, pass it explicitly or through the environment:

    ```bash
    PERSONAL_ACCESS_TOKEN=your_setup_pat copilot setup --non-interactive --yes --skip-secrets
    # or: copilot setup --token your_setup_pat
    ```

    The wizard shows a reviewable plan and asks for confirmation. Its forward-only questionnaire keeps defaults and every answer immutable; cancel and rerun if you need to revise an earlier stage. `Ctrl-C` or end-of-input exits 130 with no writes, while declining the final plan exits 0 with no writes. Use `copilot setup --dry-run` to inspect the plan without a token or changes.

    In automation, `--non-interactive` creates no terminal. `--yes` approves only the final plan: it does not supply a missing setup PAT, workflow credential, provider credential, target, or organization prerequisite.

    `copilot setup` will:
    - Create `.github/`, `.github/workflows/`, and `.github/ISSUE_TEMPLATE/` if they do not exist.
    - Copy only the selected files from the Copilot `setup/` folder into your repo (workflows, issue templates, pull request template). Existing files are **not** overwritten unless you approve an update.
    - Detect existing setup workflows and ask before updating them. Use `--update-workflows` to approve updates non-interactively; existing workflow files are backed up under `.copilot/setup-backups/` before replacement.
    - Verify GitHub access using the setup PAT. This operator token is used only for the setup operation and is never stored as a workflow Secret.
    - Ask for the separate workflow PAT owned by the bot account. It is validated and stored remotely as the `PAT` Secret; it is not the setup PAT.
    - Offer the credential fallbacks needed by the selected providers, validate supplied values with metadata-only requests, and store them as GitHub Secrets. Existing Secrets are never overwritten unless you explicitly replace them. Codex credentials are optional when the target runner already passes `codex login status`; setup and doctor report that state as an operational warning rather than a missing-secret failure. If a remote credential health workflow is already available, existing values are validated remotely before you choose to keep them.
    - Create or update non-sensitive Repository Variables for the selected runtimes, model policy, branches, Projects, AI behavior (including `AI_IGNORE_FILES`), and Bugbot settings. Use `--skip-variables` to leave them unchanged.
    - Create all required **labels** in the repository (type, action, priority, size, progress 0%–100%, and the lifecycle/activity/waiting labels).
    - Create all required **issue types** in the organization (Task, Bug, Feature, Release, Hotfix, etc.), if your plan supports it.

    After this step you have a working baseline: labels, selected templates/workflows, agent routing, operational Variables, and validated credentials are in place.
  </Step>

  <Step title="3. Adapt files to your repository">
    You can tweak issue templates (text, dropdowns), workflow names, and branch names. The following points are **required** for the GitHub Action to behave correctly; the rest is optional.

    **Required for the action to work:**
    - **Token**: Every workflow that runs Copilot must pass the `token` input (your PAT). Typically you set `token: ${{ secrets.PAT }}` in each Copilot step. Without it, the action cannot create branches, update issues, or call the API.
    - **Workflow file names for release/hotfix**: When an issue has the **deploy** label, Copilot *dispatches* a workflow by **filename**. The action inputs `release-workflow` (default: `release_workflow.yml`) and `hotfix-workflow` (default: `hotfix_workflow.yml`) must match the **exact filenames** in `.github/workflows/`. If you rename `release_workflow.yml` or `hotfix_workflow.yml`, you **must** pass the new names to the action in the workflows that invoke Copilot (e.g. in `copilot_issue.yml` add `release-workflow: 'your_release.yml'` and `hotfix-workflow: 'your_hotfix.yml'`).
    - **Deploy label**: The label that triggers the deploy flow is configured by the `deploy-label` input (default: `deploy`). The issue templates and your usage must use this same label when you want to run the release or hotfix workflow.
    - **Branch names in workflows**: The Commit workflow (push) often excludes the main and development branches from running (e.g. `!master`, `!develop`). If you change the default branch names (e.g. `main-branch: 'main'`, `development-branch: 'develop'`), update the `push.branches` filter in `.github/workflows/copilot_commit.yml` so it excludes those same names; otherwise the action may run on every push to main/develop or never run on feature branches.

    **Runner selection:** The setup templates and documentation use `runs-on: ubuntu-latest` as the neutral default. Change every agent workflow, including `agent-cli-provisioning.yml`, to the same runner labels used by your infrastructure. This repository's active dogfooding workflows use `runs-on: [self-hosted, codex]` because its Codex runner is pre-initialized; that is an internal optimization, not a requirement for consumers.

    **Optional but keep coherence:**
    - **Labels**: If you change any label input (e.g. `feature-label`, `bugfix-label`, `deploy-label`), use the **same** label names in your issue templates (`labels:` in each `.yml`) and when labeling issues manually. Otherwise the action will not recognize the type or flow.
    - **Branch name prefixes**: The action uses inputs like `feature-tree`, `bugfix-tree`, `release-tree`, `hotfix-tree` (defaults: `feature`, `bugfix`, `release`, `hotfix`) to create branch names. If you change them, branch names will follow the new prefixes; keep templates and docs in sync.
    - **Project columns**: Default column names are "Todo" and "In Progress". If you rename columns in GitHub Projects, set the corresponding action inputs (`project-column-issue-created`, `project-column-issue-in-progress`, etc.) so the action moves issues/PRs to the correct columns.

    **Bugbot autofix (issue/PR comments):** Workflows that run on `issue_comment` or `pull_request_review_comment` (so users can ask the bot to fix reported findings) must grant **`contents: write`** so the action can commit and push. On **issue_comment**, the action resolves the branch from an open PR that references the issue and checks out that branch before applying fixes and pushing. See [Bugbot autofix](/bugbot/autofix) and [Troubleshooting](/security-operations/operations/troubleshooting).
  </Step>
</Steps>

---

## Manual workflow integration (advanced)

The Action can also be wired manually from a GitHub Actions workflow. This is a
lower-level integration path for repositories that cannot run the setup wizard;
it is not equivalent to the recommended `copilot setup` flow.

1. Copy only the workflow files you need from the installed package's `setup/workflows/`
   directory into `.github/workflows/`.
2. Ensure every Copilot step uses a stable Action reference such as
   `vypdev/copilot@v3` and passes a write-capable `token` where required.
3. Configure the labels, issue types, Variables, Secrets, templates, permissions,
   and workflow dependencies yourself.

For example:

```yaml
- uses: vypdev/copilot@v3
  with:
    token: ${{ secrets.PAT }}
```

Manual workflow installation only adds execution wiring. It does not initialize
the repository metadata or install the complete set of Copilot workflows. Prefer
`copilot setup` unless this manual control is intentional. See [Workflow setup](/issues/workflow-setup)
for the action-level contract.

---

## What lives in `setup/` (and what gets created)

The workflow and template files under `setup/` are copied into your repo by
`copilot setup`. Manual copying is supported as an advanced integration path, but
it does not perform the rest of initialization. Credentials are never shipped in
the package or written to local configuration files. Below is a breakdown of
labels (with defaults), issue types, and the contents of `setup/` so you know what
you can customize and what must stay consistent.

### Coherence when customizing

If you rename or change any of the following, keep these in sync:

- **Label names** in the action inputs (e.g. in workflow `with:` or in repo/organization variables) must match the **labels** used in issue templates and on issues (e.g. `deploy`, `release`, `feature`).
- **Workflow filenames** for release and hotfix (e.g. `release_workflow.yml`) must match the action inputs `release-workflow` and `hotfix-workflow` wherever you call the action (e.g. in the Issue workflow that reacts to the deploy label).
- **Branch names** (main, develop, feature, bugfix, etc.) must match between the action inputs and any workflow filters (e.g. `push.branches` in the Commit workflow).

---

## Labels created by `copilot setup` (default values)

The setup creates the following labels. Names come from the action input defaults; colors and descriptions are set by the code.

### Type and flow labels

| Input key | Default label name | Purpose |
|-----------|--------------------|--------|
| `branch-management-launcher-label` | `branched` | Triggers branch creation when added to an issue |
| `feature-label` | `feature` | Feature branches |
| `enhancement-label` | `enhancement` | Treated like feature |
| `bug-label` | `bug` | Bug type |
| `bugfix-label` | `bugfix` | Bugfix branches |
| `hotfix-label` | `hotfix` | Hotfix branches (from main at tag) |
| `release-label` | `release` | Release branches (from develop) |
| `docs-label` | `docs` | Docs branches |
| `documentation-label` | `documentation` | Treated like docs |
| `chore-label` | `chore` | Chore branches |
| `maintenance-label` | `maintenance` | Treated like chore |
| `question-label` | `question` | Question issues (e.g. Think action) |
| `help-label` | `help` | Help request issues |
| `deploy-label` | `deploy` | Triggers release/hotfix workflow dispatch when added |
| `deployed-label` | `deployed` | Mark issue as deployed after workflow runs |

### Priority labels

| Input key | Default label name |
|-----------|---------------------|
| `priority-high-label` | `priority: high` |
| `priority-medium-label` | `priority: medium` |
| `priority-low-label` | `priority: low` |
| `priority-none-label` | `priority: none` |

### Size labels

| Input key | Default label name |
|-----------|---------------------|
| `size-xxl-label` | `size: XXL` |
| `size-xl-label` | `size: XL` |
| `size-l-label` | `size: L` |
| `size-m-label` | `size: M` |
| `size-s-label` | `size: S` |
| `size-xs-label` | `size: XS` |

### Progress labels

The setup creates **21 progress labels**: `0%`, `5%`, `10%`, … `100%`. Colors go from red (0%) to yellow (50%) to green (100%). These are used by the Check Progress action and commit steps to update issue progress.

### Lifecycle, activity, and waiting labels

The setup creates three related label dimensions. The durable lifecycle phase is exclusive; the temporary activity label and the waiting label are independent, so a target can have (for example) `state:in-progress` and `state:ai-processing` at the same time.

| Input key | Default label name | Purpose |
|-----------|--------------------|--------|
| `state-planned-label` | `state:planned` | An implementation plan is available |
| `state-in-progress-label` | `state:in-progress` | Implementation has started |
| `state-reviewing-label` | `state:reviewing` | A pull request is under review |
| `state-changes-requested-label` | `state:changes-requested` | The review has active findings |
| `state-verified-label` | `state:verified` | The pull request was merged successfully |
| `state-ready-label` | `state:ready` | The latest review is ready for human action |
| `state-blocked-label` | `state:blocked` | The workflow needs human intervention |
| `state-ai-processing-label` | `state:ai-processing` | Temporary marker while a Copilot agent is working; removed at run end |
| `state-awaiting-maintainer-label` | `state:awaiting-maintainer` | Waiting for maintainer response, approval, or merge |
| `state-awaiting-issue-author-label` | `state:awaiting-issue-author` | Waiting for information or changes from the issue author |

---

## Issue types created by `copilot setup` (defaults)

For organizations that support issue types, the setup ensures these exist (name / description / color from action inputs):

| Type | Default name | Default color |
|------|--------------|---------------|
| Task | Task | blue |
| Bug | Bug | orange |
| Feature | Feature | green |
| Documentation | Documentation | pink |
| Maintenance | Maintenance | purple |
| Hotfix | Hotfix | red |
| Release | Release | yellow |
| Question | Question | gray |
| Help | Help | purple |

---

## Branch name prefixes (defaults)

Used to build branch names (e.g. `feature/42-my-title`). Configurable via action inputs:

| Input key | Default value |
|-----------|----------------|
| `main-branch` | `master` |
| `development-branch` | `develop` |
| `feature-tree` | `feature` |
| `bugfix-tree` | `bugfix` |
| `hotfix-tree` | `hotfix` |
| `release-tree` | `release` |
| `docs-tree` | `docs` |
| `chore-tree` | `chore` |

---

## Contents of `setup/` (workflows, templates, PR template)

### `setup/workflows/`

These are the available setup-managed workflows. `copilot setup` copies the
files required by the selected features to `.github/workflows/`; a manual
installation must preserve the dependencies described below. Default filenames
and roles:

| File | Purpose |
|------|--------|
| `copilot_issue.yml` | Runs on issue events (opened, edited, labeled, unlabeled, etc.): creates branches, links to projects, assignees, deploy trigger. |
| `copilot_pull_request.yml` | Runs on PR events: links PR to issue/project, reviewers, AI description, etc. |
| `copilot_commit.yml` | Runs the issue-centric push pipeline (all branches except main/develop by default): commit notice, size/progress, and Bugbot. |
| `copilot_branch_sync.yml` | Lightweight push observer on all branches: detects parent/working drift and maintains a synchronization notice without loading Bugbot or an agent. |
| `copilot_issue_comment.yml` | Runs on explicitly addressed issue comments: e.g. Think action (answer questions). |
| `copilot_pull_request_comment.yml` | Runs on explicitly addressed PR review comments, including translation checks. |
| `release_workflow.yml` | **Manual** (`workflow_dispatch`) with internal `prepare` and `publish` modes: prepares a release from its frozen development cut, promotes it to production, then publishes only the accepted production commit and starts reconciliation. Filename must match `release-workflow`. |
| `hotfix_workflow.yml` | **Manual** (`workflow_dispatch`) with internal `prepare` and `publish` modes: prepares a hotfix from the selected production tag, promotes it, then publishes and reconciles the accepted production commit. Filename must match `hotfix-workflow`. |
| `copilot_deployment_orchestration.yml` | Runs on marked `pull_request: closed` events: verifies the operation identity, repository, branches, and SHAs, then resumes publication or final reconciliation without polling inside the original runner. |
| `agent-cli-provisioning.yml` | **Manual** (`workflow_dispatch`): verifies that the selected agent runtime binaries and their non-interactive command surfaces are available on the target runner. |
| `copilot_credential_health.yml` | **Manual** (`workflow_dispatch`): validates selected remote credentials without exposing their values; used by `copilot doctor`. |
| `copilot_close_inactive_issues.yml` | **Scheduled every 6 hours** (also `workflow_dispatch`): closes open issues waiting for a maintainer or issue author after the configured inactivity threshold. Opt-in. |

Each Copilot workflow step passes at least `token`. Agent-capable workflows also
pass the configured CLI inputs via `vars.*`; `copilot_branch_sync.yml`
deliberately does not. The **release** and **hotfix** workflows are dispatched by
the action when an issue has the deploy label and the corresponding
release/hotfix context; they are not triggered by issue events directly.
The continuation and every enabled publishing workflow must be installed
together on the default branch before the first operation. This project enables
both release and hotfix, so it installs all three files. The close event cannot
be resumed by a continuation that exists only on the release or hotfix branch.

The distributed release/hotfix templates are registry-neutral. Their `publish`
mode creates or verifies the production tag and GitHub Release and provides a
clearly marked deployment extension point. This repository's own files under
`.github/workflows/` additionally compile, validate, smoke-test, and publish
`@vypdev/copilot` through npm OIDC; consumer setup templates never publish this
package.

The `agent-cli-provisioning.yml` workflow checks the selected runtime binaries,
reported identities, and non-interactive help commands without making a paid model request. Runtime
installation itself validates the pinned provisioning inputs. The `copilot_credential_health.yml` workflow is
read-only with respect to repository configuration: it executes provider-specific
health checks and reports only whether each requested credential is usable. GitHub
does not expose Secret values through its API, so `copilot doctor` dispatches this
workflow when it is available on the repository's default branch.

When Repository Variables are enabled, setup creates the common `AGENT_*` contract,
the provider/model/effort variables for each configured `FINDINGS_*`, `FIXER_*`,
`PLANNER_*`, `REVIEWER_*`, and `TESTER_*` role, the repository and
project variables, and the AI/Bugbot variables. The workflow templates read
the optional `*_EXECUTABLE` selections too. Each value may contain only the
provider's exact basename or an absolute path to that same executable; arguments,
wrappers, and shell text are rejected.

Release/hotfix setup also writes these bounded orchestration Variables:

| Repository Variable | Action input |
|---|---|
| `RELEASE_RECONCILIATION_STRATEGY` | `release-reconciliation-strategy` |
| `HOTFIX_RECONCILIATION_STRATEGY` | `hotfix-reconciliation-strategy` |
| `RECONCILIATION_PR_MODE` | `reconciliation-pr-mode` |
| `MERGE_QUEUE_CHECK_ATTESTATIONS` | `merge-queue-check-attestations` |
| `RECONCILIATION_BACKMERGE_MODE` | `reconciliation-backmerge-mode` |
| `HOTFIX_ACTIVE_RELEASE_POLICY` | `hotfix-active-release-policy` |
| `RECONCILIATION_TREE` | `reconciliation-tree` |
| `RECONCILIATION_CLEANUP` | `reconciliation-cleanup` |
| `RECONCILIATION_ISSUE_COMPLETION` | `reconciliation-issue-completion` |
| `ORCHESTRATION_PRESENTATION_MODE` | `orchestration-presentation-mode` |
| `ORCHESTRATION_DIAGRAMS` | `orchestration-diagrams` |
| `ORCHESTRATION_COMMENT_MODE` | `orchestration-comment-mode` |

`MERGE_QUEUE_CHECK_ATTESTATIONS` defaults to `[]`. Setup accepts it as a
structured YAML array and serializes it as bounded JSON for the Action. It is a
reviewed exception only for required producers Copilot cannot prove
automatically; it is not a wildcard or a bypass for known-incompatible
workflows.

The project-only npm visibility Variables are
`NPM_VISIBILITY_POLL_INTERVAL_SECONDS` (default `20`, allowed `10`–`60`) and
`NPM_VISIBILITY_TIMEOUT_SECONDS` (default `120`, allowed `60`–`900`). They are
not Action inputs and are not created for registry-neutral consumer workflows.

When enabled, inactivity cleanup also creates `INACTIVITY_THRESHOLD_HOURS` (168
by default). The scheduled workflow closes only issues marked
`state:awaiting-maintainer` or `state:awaiting-issue-author`; it rechecks the
issue immediately before mutating it and skips candidates that became active or
entered `state:ai-processing`.

### `setup/ISSUE_TEMPLATE/`

All files here are copied to `.github/ISSUE_TEMPLATE/`.

| File | Purpose |
|------|--------|
| `config.yml` | Issue template config (e.g. `blank_issues_enabled`, contact link to Git-Flow). |
| `feature_request.yml` | Feature request; uses labels like `enhancement`, `feature`, `priority: low`. Add `branched` if you want a branch created automatically. |
| `bug_report.yml` | Bug report; uses `bug`, `bugfix`, `priority: high`. Add `branched` if needed. |
| `doc_update.yml` | Documentation; uses `documentation`, `docs`. |
| `chore_task.yml` | Chore/maintenance; uses `chore`, `maintenance`. |
| `help_request.yml` | Help request; uses `help` (no branch). |
| `hotfix.yml` | Hotfix; uses `hotfix`, `branched`, `priority: high`. Includes Base Version, Hotfix Version, Changelog. |
| `release.yml` | Release; uses `release`, `branched`, `priority: medium`. Includes Release Type, Version, Changelog. |

The **labels** in each template must match the label names configured in the action (or your custom inputs). For example, if you change `deploy-label` to `ready-to-deploy`, then any template or process that adds the deploy trigger must use `ready-to-deploy`.

### `setup/pull_request_template.md`

Copied to `.github/pull_request_template.md`. Used as the default body for new PRs. The AI PR description feature can fill this structure; you can edit the sections (Summary, Related Issues, Scope, Technical Details, How to Test, etc.) to fit your repo. No Copilot logic depends on specific headings; only the deploy/release/hotfix flows depend on **workflow filenames** and **label names**.

---

## Optional: Configure projects, AI, and workflows

After the tutorial and file customization, you can:

- Set **repository or organization variables** for the agent CLI contract (`AGENT_PROVIDER`, `AGENT_MODEL_PROVIDER`, `AGENT_MODEL`, `AGENT_EFFORT`, `AGENT_ALLOWED_MODEL_PROVIDERS`, and `AGENT_ALLOWED_MODELS`) and, when needed, independent task overrides for `FINDINGS_*`, `REVIEWER_*`, `PLANNER_*`, `FIXER_*`, and `TESTER_*`. The supplied Copilot workflow templates forward these values to the action. Keep `CURSOR_API_KEY` available only when one of the configured task providers is Cursor.
- Enable the `inactiveIssueClosure` setup feature when you want the scheduled cleanup, and adjust `INACTIVITY_THRESHOLD_HOURS` (1–8760 hours) to match your retention policy. This feature is disabled by default because it closes GitHub issues.
- Adjust **project column names** and **branch names** via action inputs so the action moves issues/PRs to the right columns and uses your branch naming.
- Customize **issue templates** (copy, add fields, change labels) while keeping label and workflow names consistent as above.
- Add or modify **release/hotfix** workflow steps (e.g. build, deploy) while keeping the workflow **filenames** and the action inputs `release-workflow` and `hotfix-workflow` in sync.

For a full list of inputs and behaviors, see [Configuration](/configuration) and [Features & capabilities](/features).