Configuration File
Disclaimer
This documentation may be obsolete, incomplete, or incorrect. Please refer to the default config.yaml in your installation for the most up-to-date list of settings.
WARNING: DO NOT EDIT THE DEFAULT CONFIG DIRECTLY. THIS WON'T HAVE ANY POSITIVE EFFECT. EDIT ITS COPY IN THE REPOSITORY ROOT INSTEAD.
config.yaml is the main configuration file for the SillyTavern server which you can find in the repository root directory after completing the installation and running the server for the first time. It is a YAML file that contains various settings, such as network, security, and backend-specific options. The changes made to this file will take effect after restarting the server.
New settings that are added upstream are automatically populated with default values when restarting the server after updating the repository. You can then modify these settings as needed. To add missing settings before startup, run the npm run init script.
For nested settings, dot notation is used to indicate the hierarchy. For example, protocol.ipv6: false refers to the ipv6 setting under the protocol section with a value of false.
protocol:
ipv6: false
Command-Line Arguments
You can pass command-line arguments when starting the SillyTavern server to override some settings in config.yaml.
Examples
node server.js --port 8000 --listen false
# or
npm run start -- --port 8000 --listen false
# or (Windows only)
Start.bat --port 8000 --listen false
Supported arguments
None of the arguments are required. If you don't provide them, SillyTavern will use the settings in config.yaml.
Environment Variables
Configuration may also be set via environment variables, which will override the values in the config.yaml file.
The environment variables should be prefixed with SILLYTAVERN_ and use uppercase letters for the setting names. For example, the dataRoot setting can be overridden with the SILLYTAVERN_DATAROOT environment variable.
The nested settings should be separated by underscores. For example, protocol.ipv6 can be overridden with the SILLYTAVERN_PROTOCOL_IPV6 environment variable.
Configurations that expect arrays or objects should be JSON-stringified. For example, to override the whitelist setting with the SILLYTAVERN_WHITELIST environment variable, you should set it as a JSON string: SILLYTAVERN_WHITELIST='["127.0.0.1", "::1"]'.
If you are using Node.js v20 or later, you can also store environment variables in a .env file and pass it to the server with the --env-file flag. For example, to use the .env file located in the repository root, you can start the server with the following command:
node --env-file=.env server.js
Alternatively, pass the environment variables directly via the command line:
SILLYTAVERN_LISTEN=true SILLYTAVERN_PORT=8000 node server.js
See more about using environment variables in the Node.js documentation.
Data Configuration
Logging Configuration
Network Configuration
SSL Configuration
Security Configuration
IP Whitelisting
Forwarded Headers Configuration
Adjust which headers are used to determine the real IPs for features like IP whitelisting, rate limiting and access logging.
Only change if you are sure that you use a correctly configured reverse proxy, otherwise this may lead to IP spoofing.
Private Address Whitelisting
This is an additional layer of security to prevent Server-Side Request Forgery (SSRF) attacks, performing whitelist checks against server-side HTTP requests that resolve to private IP addresses. When enabled, private network ranges will be blocked, unless explicitly allowed in the privateAddressWhitelist.allowedRanges setting.
This is disabled by default, but recommended when listen mode is enabled, or if your server is accessible by untrusted users.
Host Whitelisting
Security Overrides
DISABLING SECURITY MEASURES IS HIGHLY DISCOURAGED. PLEASE MAKE SURE YOU UNDERSTAND WHAT YOU ARE DOING BEFORE MAKING CHANGES.
User Authentication
Rate limiting is applied by default to both basic auth and user account login attempts. You can adjust the limits in the
If using basic auth behind a tunneled connection (e.g., Cloudflare Tunnel), make sure to adjust the
SSO Auto-Login
Inadequately securing an SSO flow can lead to unauthorized access. Make sure to properly configure trusted proxies and test your setup before enabling SSO. If you are unsure about the security implications, it is recommended to keep SSO auto-login disabled and resort to other authentication methods instead.
Rate Limiting Configuration
To disable rate limiting for a specific route, set the limit to 0.
For example, to disable login rate limiting, set rateLimiting.accountsLoginMaxAttempts to 0.
Request Proxy Configuration
Request proxying conflicts with the private address whitelist feature. If you enable both, only the requests that bypass the proxy will be checked against the private address whitelist, while the proxied requests will not be checked at all. If unsure, disabling the request proxy is recommended.
CORS Proxy Configuration
An enabled CORS proxy may be required by some extensions. It is not required by any built-in features.
Enabling a CORS proxy without proper security measures (e.g., IP, host, and private address whitelists) can lead to SSRF vulnerabilities. Make sure to configure the whitelists accordingly if you enable this feature, and only enable it if you trust the extensions that require it.
CORS Configuration
Browser Launch Configuration
Previously known as "Autorun" settings.
Performance Configuration
Cache Buster Configuration
Requires localhost or a domain with HTTPS, otherwise will not work!
Thumbnailing Configuration
Backup Configuration
Extensions Configuration
Server Plugins
Git Configuration
Git backends explained
auto- prefer system binary, falling back to integratedsystem- system git binary using simple-gitbuiltin- integrated engine using isomorphic-git
API Integration Settings
OpenAI Configuration
MistralAI Configuration
Ollama Configuration
Claude Configuration
IMPORTANT!
Use with caution and only when the prompt prefix is static and doesn't change between requests. {{random}} macro, lorebooks, vectors, summaries, etc. will likely invalidate the cache and you'll just waste money on cache misses. The provider may have a minimum prompt size requirement for caching. Behavior may be unpredictable and no guarantees can or will be made, please review the API documentation.
See: Prompt Caching