Arcade Engine configuration
’s configuration is a YAML file with the following sections:
| Section | Description |
|---|---|
| API Configuration | Configures the server for specific protocols |
| Auth Configuration | Configures user authorization providers and token storage |
| Cache Configuration | Configures the short-lived cache |
| Security Configuration | Configures security and encryption |
| Storage Configuration | Configures persistent storage |
| Telemetry Configuration | Configures telemetry and observability (OTEL) |
| Tools Configuration | Configures tools for AI models to use |
Specify a config file
To start the , pass a config file with -c or --config:
arcade-engine -c /path/to/config.yamlEnsure you have a running before starting the engine. See arcade serve CLI command for how to start a worker via the CLI.
Dotenv files
automatically loads environment variables from .env files in the directory where it was called. Use the -e or--env flag to specify a path:
arcade-engine -e .env.dev -c config.yamlSecrets
supports two ways of passing sensitive information like without storing them directly in the config file.
Environment variables:
topic:
area:
- id: primary
vendor:
api_key: ${env:OPENAI_API_KEY}External files (useful in cloud setups):
topic:
area:
- id: primary
vendor:
api_key: ${file:/path/to/secret}API configuration
HTTP is the supported protocol for ’s API. The following configuration options are available:
api.development(optional, default:false) - Enable development mode, with more logging and simple worker authenticationapi.host(default:localhost) - Address to which binds its server (e.g.,localhostor0.0.0.0)api.port(default:9099) - Port to which binds its server (e.g.,9099or8080)api.public_host(optional) - External hostname of the API (e.g.,my-public-host.com), if it differs fromapi.host(for example, when is behind a reverse proxy)api.read_timeout(optional, default:30s) - Timeout for reading data from clientsapi.write_timeout(optional, default:1m) - Timeout for writing data to clientsapi.idle_timeout(optional, default:30s) - Timeout for idle connectionsapi.max_request_body_size(optional, default:4Mb) - Maximum request body size
A typical configuration for production looks like:
api:
development: false
host: localhost
port: 9099When the is hosted in a container or behind a reverse proxy, set api.public_host to the external hostname of the API:
api:
development: false
host: localhost
port: 9099
public_host: my-public-host.comFor local development, set api.development = true. In development mode, does not require worker authentication.
Auth configuration
manages auth for AI tools and direct API calls. It supports many built-in auth providers, and can also connect to any OAuth 2.0 authorization server.
The auth.providers section defines the providers that can authorize with. Each provider must have a unique id in the array. There are two ways to configure a provider:
For built-in providers, use the provider_id field to reference the pre-built configuration. For example:
auth:
providers:
- id: default-github
description: The default GitHub provider
enabled: true
type: oauth2
provider_id: github
client_id: ${env:GITHUB_CLIENT_ID}
client_secret: ${env:GITHUB_CLIENT_SECRET}For custom OAuth 2.0 providers, specify the full connection details in the oauth2 sub-section. For full documentation on the custom provider configuration, see the OAuth 2.0 provider configuration page.
You can specify a mix of built-in and custom providers.
Cache configuration
The cache section configures the short-lived cache.
Configuring the cache is optional. If not configured, the cache will default to an in-memory cache implementation suitable for a single-node deployment.
The cache section has the following configuration options:
api_key_ttl(optional, default:10s) - The time-to-live for in the cache
Two cache implementations are available:
in_memory- (default) An in-memory cache implementation suitable for a single-node deployment.redis- A Redis cache implementation suitable for a multi-node deployment:
cache:
api_key_ttl: 10s
redis:
addr: "localhost:6379"
password: ""
db: 0Security configuration
The security section configures the root encryption keys that the uses to encrypt and decrypt data at rest. See the storage configuration section below to configure where data is stored.
A typical configuration looks like this:
security:
root_keys:
- id: key1
default: true
value: ${env:ROOT_KEY_1}
- id: key2
value: ${env:ROOT_KEY_2}Keys should be a long random string of characters. For example:
openssl rand -base64 32Default root key
When you install Arcade Engine locally, an engine.env file is created with a default root key:
# Encryption keys (change this when deploying to production)
ROOT_KEY_1=default-key-valueThis default value can only be used in development mode (see API configuration above).
You must replace the value of ROOT_KEY_1 in engine.env before
deploying to production.
Storage configuration
The storage section configures the storage backend that the uses to store persistent data.
There are three storage implementations available:
in_memory- (default) An in-memory database, suitable for testing.sqlite- A SQLite file on disk, suitable for local development:
storage:
sqlite:
# Stores DB in ~/.arcade/arcade-engine.sqlite3
connection_string: "@ARCADE_HOME/arcade-engine.sqlite3"postgres- A PostgreSQL database, suitable for production:
storage:
postgres:
user: ${env:POSTGRES_USER}
password: ${env:POSTGRES_PASSWORD}
host: ${env:POSTGRES_HOST}
port: ${env:POSTGRES_PORT}
db: ${env:POSTGRES_DB}
sslmode: requireTelemetry configuration
Arcade supports logs, metrics, and traces with OpenTelemetry .
If you are using the locally, you can set the environment field to local. This will only output logs to the console:
telemetry:
environment: local
logging:
# debug, info, warn, error, fatal
level: debug
encoding: consoleTo connect to OpenTelemetry compatible collectors, set the necessary OpenTelemetry environment variables in the engine.env file.
environment and version are fields that are added to the telemetry attributes, which can be filtered on later.
telemetry:
environment: prod
logging:
level: info
encoding: consoleNotes
- The Engine service name is set to
arcade_engine - Traces currently cover the
/v1/healthendpoints, as well as authentication attempts
Tools configuration
orchestrates tools that AI models can use. Tools are executed by distributed called workers, which are grouped into directors.
The tools.directors section configures the that are available to service calls:
tools:
directors:
- id: default
enabled: true
max_tools: 64
workers:
- id: local_worker
enabled: true
http:
uri: "http://localhost:8002"
timeout: 30
retry: 3
secret: ${env:ARCADE_WORKER_SECRET}When a is added to an enabled director, all of the hosted by that worker will be available to the model and through the Arcade API.
HTTP worker configuration
The http sub-section configures the HTTP client used to call the ’s :
uri(required) - The base URL of the ’ssecret(required) - Secret used to authenticate with thetimeout(optional, default:30s) - Timeout for calling the ’sretry(optional, default:3) - Number of times to retry a failed call
must be configured with a secret that is used to authenticate with
the worker. This ensures that workers are not exposed to the public internet
without security.
If api.development = true, the secret will default to "dev" for local development only. In production, the secret must be set to a random value.
Config file version history
- 1.0: Full example and schema