> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuration Approaches

> Three ways to configure 2501 — pick the one that fits how you work

You can configure 2501 three ways. Each has trade-offs.

<CardGroup cols={3}>
  <Card title="Manual" icon="hand-pointer">
    Click through Command Center. Fastest for quick changes; tedious past a few dozen resources.
  </Card>

  <Card title="CSV import" icon="file-csv">
    Bulk-import hosts and their agents from a spreadsheet. Best for large infrastructures.
  </Card>

  <Card title="Git-managed" icon="code-branch">
    Manage every resource as MDX in a repo. Reviewable diffs, PRs, reproducible. Recommended at scale.
  </Card>
</CardGroup>

## Manual

Create resources directly in Command Center on each resource's page. Good for **getting started**, **one-offs**, and **exploring** how a feature behaves before automating it. Past a couple dozen specialties, rules, hosts, and agents the click-through cost adds up.

## CSV import

The most time-consuming part of any setup is creating hosts and agents in bulk. The [CSV importer](/0.8/configure/import-hosts-csv) reads a single file containing both, including credential references. Specialties and credentials must already exist (referenced by name).

CSV does **not** cover specialties, operational rules, blacklists, knowledge, or gateways.

## Git-managed (`2501 resources`)

The CLI synchronizes a directory of MDX files with your deployment. Each kind has its own subdirectory; each file declares one resource via YAML frontmatter, with the body holding any long-form text (specialty prompt, host knowledge, rule text).

| Kind              | Supported                                    |
| ----------------- | -------------------------------------------- |
| Agents            | ✅                                            |
| Hosts             | ✅                                            |
| Specialties       | ✅                                            |
| Operational Rules | ✅                                            |
| Blacklist         | ✅                                            |
| Credentials       | ✅ (secret values from env vars at sync time) |
| Gateways          | ✅                                            |

The workflow:

```bash theme={null}
# Snapshot the live platform into your repo
2501 resources pull -d ./config

# Apply the repo back to the platform; --prune deletes undeclared resources
2501 resources sync -d ./config
2501 resources sync -d ./config --prune
```

`sync` prints a plan (create / update / delete / unchanged) before applying. Deletes are opt-in via `--prune` and a delete that would orphan dependents is reported BLOCKED.

For the full reference and worked examples, see [Configuration as Code](/0.8/configure/configuration-as-code).

## Which one when

| Scenario                                         | Pick                                  |
| ------------------------------------------------ | ------------------------------------- |
| First-time evaluation, demo, single tenant       | Manual                                |
| Onboarding hundreds of hosts at once             | CSV → then manual or git for the rest |
| Production at scale, multiple environments       | Git-managed                           |
| You already have it manual and want to adopt git | `pull` first, commit, then `sync`     |