> ## 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. [Import and export](/0.16/configure/import-export) does it as files - one for hosts, one for agents, in CSV or JSON - and you can export what you have, edit it, and import it back. Specialties and credentials must already exist; files reference them by id.

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.16/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` |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.