--- title: "File Configuration" id: "1947" type: "page" slug: "config" published_at: "2026-09-30T22:28:17+00:00" modified_at: "2026-10-01T00:11:03+00:00" url: "https://xedant.com/agents/proxy/docs/config" markdown_url: "https://xedant.com/agents/proxy/docs/config.md" excerpt: "All of Proxy Agent’s configuration — models, channels, access keys, secret-hiding rules and the values…" --- # File Configuration [https://xedant.com/agents/proxy/docs/config.md](https://xedant.com/agents/proxy/docs/config.md) All of Proxy Agent’s configuration — models, channels, access keys, secret-hiding rules and the values from the “Settings” window — lives not in a database but in ordinary text files next to the project. This page tells what those files are, how to edit them safely, and why this kind of configuration is convenient to keep in the project’s history and move to another server. ## Why files Earlier all configuration lived in the database — like the logs. Because of that, moving the product to another server was not simple: the configuration had to be assembled again or restored from a full database copy. Now the configuration lives separately from the database, in text files in the project folder. Three benefits come from that. The configuration is visible and readable by eye, without the database or the interface. It moves easily to another installation together with the project folder. And it can be kept under version control — then it is clear who changed what and when. ## Where the configuration lives The configuration folder is `/project/apps/proxy` by default. A different location is set with the `PROXYAGENT_CONFIG_FOLDER` environment variable. It is read once at startup, so after changing the path a restart is needed. In the container this folder is mounted as a separate volume: then the configuration survives recreating the container and is easy to copy. ## Five files and what is in them - **`settings.yml`** — the values from the “Settings” window, including the listener settings you set: whether the proxy service requires sign-in, the report retention, the interface appearance. Every line is a name-value pair. - **`models.yml`** — the models: how to reach the vendor, a short label, the four prices per million “portions of text” (tokens), and the channel the traffic goes through. - **`http-providers.yml`** — the channels: HTTP proxies, SOCKS5, VPN and Happ subscriptions. - **`keys.yml`** — the access keys: the fingerprint, the last characters, the spending limits, the allowed models and channels. - **`anonymization.yml`** — the secret-hiding rules and the lists of the secrets themselves. ## How to edit The files are the single source of truth, and all three ways lead into the same file: editing by hand, changing in the interface, and [management over the API](/agents/proxy/docs/api) . It does not matter where the change came from — the result ends up in the file on disk. The interface and the API write the file carefully: a temporary file is prepared first, then it replaces the old one. If the write breaks off, you are not left with half a configuration. ## Picking up edits and errors Hand edits are picked up in about 300 ms — no restart needed. When a file turns out to contain an error, the product does not crash: it keeps working with the last good state and writes a warning with the error text to the log. Fix the file — and the configuration returns. One note just in case: when a file is edited by hand and from the interface at the same time, the write that happens later wins. ## Secrets as environment-variable references Secret fields — the vendor key (`apiKey`), the channel password, the VPN private key — can be written not as the secret itself but as an environment-variable reference like `$VARIABLE_NAME`. The value is substituted at the moment of the call to the vendor, so the secret may not be in the file at all. That is convenient when the project folder is kept under version control: the list of settings lands in the history, while the secrets themselves stay in environment variables on the server. When the variable is not set, the product substitutes the string as it is and the call to the vendor fails — it will not quietly replace it with an empty value. ## The .env file: secrets next to the project Secrets are conveniently kept not in the startup variables but in one `.env` file next to the project. By default that is `/project/.env`; a different path is set with the `PROXYAGENT_ENV_FILE` variable. Inside are simple `NAME=value` lines: comments start with `#`, empty lines are skipped, `export` may precede the name, and the value may be quoted. The app reads the file itself at startup and keeps watching it, so no separate `--env-file` flag is needed in the launch command. Real environment variables always take priority over the file: when a name is set in both, the outer value wins. A line removed from the file unsets the variable, and a missing file claims nothing — one created later is picked up by itself. An unreadable file leaves the last good values in place. The variables that change on the fly are the ones read at use time: the `$VARIABLE_NAME` references in the configuration folder’s files, the management key, the administrator sign-in and the external programs (the Xray core, WireGuard). The variables read once at startup (the database, the data and configuration folders, the license, the session signing key, ClickHouse, the agent connection) still require a container restart. The file belongs in `.gitignore` and must not be published anywhere: it holds secrets. Only change counters reach the log — never the values themselves. ## What stays in the database Only the configuration lives in the files. The bulky working data remains in the database: the request log, the proxy service log and the daily spending totals per key. There is also a third place — the working-state folder (`PROXYAGENT_DATA`, by default `/apps/proxy`). It stores the DeepSeek “reasoning” cache, the session signing keys, the VPN working files and the working files of Happ subscription channels (`happ/`). It too deserves a mounted volume: otherwise, after recreating the container, every issued sign-in stops working. ## Moving to another server Copy the configuration folder to the new installation — and the models, channels, keys, rules and settings are in place without restoring any database. The database there has to be its own: it holds only history, and on the new server it starts from zero. That is exactly why it pays to keep the folder under version control together with the project: you can see who changed the configuration and when, and returning to a previous state is an ordinary file revert. ## What not to do - **Do not publish a folder with real secrets.** Access to such a folder equals access to the vendor keys. When many people can see the project folder, write the secrets as environment-variable references. - **Do not edit a file while the interface is changing it.** The later write overwrites the earlier one. - **Do not count on a database copy restoring the configuration.** The configuration is in the files now — copy the configuration folder. - **Do not expect a change of `PROXYAGENT_CONFIG_FOLDER` to apply on the fly.** The path is read once at startup; after changing it a restart is needed. Next: how to change values from the “Settings” window — in the [Settings](/agents/proxy/docs/settings) section, and how to drive them with a program — in the [Management API](/agents/proxy/docs/api) section. [← Back to the documentation index](/agents/proxy/docs)