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

# What Xerg reads

> The files Xerg reads in your repos, the limits on source code, and what it keeps.

Xerg only reads. It reads your repos through the Xerg GitHub App and your accounts through the [services you connect](https://xerg.ai/docs/connect/overview.md), and it never changes either.

## Config files

Xerg reads the file list of each repo, then the files that say what the repo uses and where it runs:

Wherever they are in the repo: `.gitlab-ci.yml`, `.sentryclirc`, `amplify.yaml`, `amplify.yml`, `azure-pipelines.yml`, `cdk.json`, `Chart.yaml`, `cloudbuild.yaml`, `cloudbuild.yml`, `doppler.yaml`, `doppler.yml`, `drizzle.config.js`, `drizzle.config.mjs`, `drizzle.config.ts`, `firebase.json`, `fly.toml`, `Gemfile`, `go.mod`, `kustomization.yaml`, `lerna.json`, `netlify.toml`, `nx.json`, `package.json`, `Pipfile`, `pnpm-workspace.yaml`, `Procfile`, `pyproject.toml`, `railway.json`, `railway.toml`, `render.yaml`, `render.yml`, `requirements.txt`, `schema.prisma`, `serverless.yaml`, `serverless.yml`, `turbo.json`, `vercel.json`, `wrangler.json`, `wrangler.jsonc`, `wrangler.toml`.

It also reads, by pattern:

* Dockerfiles and Docker Compose files
* Terraform (`.tf`) files
* GitHub Actions workflows, CircleCI, GitLab CI and Azure Pipelines configs
* Kubernetes manifests in `k8s/` or `kubernetes/` folders, and Helm charts
* Sentry, Supabase and DigitalOcean App Platform configs
* `docs.json` and `mint.json` (Mintlify docs sites)
* `CODEOWNERS`, for who owns what
* Example env files, like `.env.example`, `.env.sample` and Cloudflare's `.dev.vars.example`

It skips dependency, build and test folders (`node_modules`, `vendor`, `dist`, `build`, tests, fixtures, examples, docs and the like), and any app an owner or admin leaves out in [setup](https://xerg.ai/docs/setup.md): nothing in that app's folder is listed or read.

Each folder with its own manifest (a `package.json` that runs, `go.mod`, `pyproject.toml` and so on) or a Cloudflare `wrangler` config is an app on the map.

## Source code, narrowly

Some services are called over plain HTTP, with no package or env variable to give them away. To find those, Xerg downloads source files and scans them (on by default; an owner or admin can turn it off in [setup](https://xerg.ai/docs/setup.md), and Xerg then reads config files and env variable names only):

* It looks only for imports and API hostnames, matched against the [services Xerg recognizes](https://xerg.ai/docs/map/recognized-services.md).
* It keeps only the service, the file and the line. Never the code, and never the hostname itself.
* Files named for a service (`stripe.ts`, `mixpanelClient.ts`) come first, then paths like `analytics`, `billing` or `webhook`, then the shallowest files.
* It skips tests, type declarations, generated, vendored and minified files.

Xerg reads up to 300 config files per repo (each up to 400 KB) and up to 300 source files (each up to 100 KB).

## Env variables: names, never values

Xerg downloads example env files and keeps only the variable names, like `STRIPE_SECRET_KEY`, so it can tell which services an app uses and where a key is used. It drops the values without keeping them, and it never downloads real `.env` files.

## What it keeps

The map: names of apps, services and resources, how they connect, and which file and line each came from. File contents aren't stored. See [Security and data](https://xerg.ai/docs/security.md).


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