Configuration
Configuration¶
The MindFlight AI Server is designed to be flexible and easy to configure. Whether you're running it locally or in production, the configuration system allows you to adapt the server to your needs without touching the code.
How configuration works¶
The server reads its configuration from two main sources:
- YAML configuration file (usually named
config.yaml
). - Environment variables, which override the YAML file when set.
This two-layer system ensures that sensitive data (like passwords or secrets) can be kept out of the codebase and set securely via environment variables.
Metaphor:
Think of the YAML file as your recipe book, and environment variables as sticky notes you attach when you want to tweak something temporarily (like "add extra salt today").
The config.yaml
file¶
The YAML file contains all the main settings. Here's a simple overview of the key sections you'll find:
Section | What it controls |
---|---|
server | The address and performance settings (port, timeouts, rate limiting). |
auth | Security keys and JWT token settings. |
database | Database connection settings (host, port, user, password). |
providers | Enables/disables specific Providers and their options. |
notifications | Settings for internal/external notifications. |
jobmanager | Job queue configuration (e.g., number of workers, retry strategy). |
Each section can include default values, which are overridden by your specific setup.
Common environment variables¶
Environment variables allow you to override the config file easily, especially useful in Docker or cloud environments.
Environment Variable | Purpose |
---|---|
SLOP_SERVER_ADDRESS | Set the server's listening address (e.g., :8081 ). |
SLOP_JWT_SECRET | Set the secret used for token generation/validation. |
SLOP_DATABASE_HOST | Define where the PostgreSQL server is located. |
SLOP_DATABASE_PORT | Set the PostgreSQL port. |
SLOP_DATABASE_USER | The database user account. |
SLOP_DATABASE_PASSWORD | The database user's password. |
SLOP_DATABASE_DBNAME | The name of your database. |
SLOP_FILESYSTEM_ALLOWED_DIRS | Define which directories the Filesystem provider can access. |
Best practice:
- Use environment variables for secrets and passwords to avoid exposing sensitive data in version-controlled files.
Example: enabling a Provider¶
Let's say you want to enable the Unipile Provider to process emails. In your config.yaml
, you would add:
providers:
unipile:
enabled: true
api_key: "YOUR_UNIPILE_API_KEY"
base_url: "https://api.unipile.com"
Alternatively, with environment variables:
SLOP_PROVIDERS_UNIPILE_ENABLED=true
SLOP_PROVIDERS_UNIPILE_API_KEY=YOUR_UNIPILE_API_KEY
SLOP_PROVIDERS_UNIPILE_BASE_URL=https://api.unipile.com
Metaphor: Enabling a Provider is like plugging in a new kitchen appliance: once connected and configured, it's ready to use when the server needs it.
Running with Docker¶
A common way to run the server is with Docker. Using docker-compose.yml
, you can provide the environment variables directly and map the config.yaml
if needed.
Best practice:
- Mount your
config.yaml
as a volume and keep environment-specific overrides in your.env
file.
What happens if something is missing?¶
If a critical configuration (like the database connection) is missing, the server will refuse to start and log a clear error message. This is designed to avoid partial or unstable deployments.
Metaphor: If the kitchen has no oven, the restaurant won't open that day!
Security tips¶
- 🔒 Always keep your
SLOP_JWT_SECRET
andSLOP_DATABASE_PASSWORD
private. - 🔐 Use Docker secrets or cloud secret managers (like AWS Secrets Manager) in production.
- 🛑 Never commit sensitive configs to your repository.
Recap diagram (Mermaid)¶
Here's a diagram to show how configuration flows into the server:
flowchart TD
ConfigFile[config.yaml]
EnvVars[Environment Variables]
ConfigLoader[Configuration Loader]
ServerComponents[Server Components]
ConfigFile --> ConfigLoader
EnvVars --> ConfigLoader
ConfigLoader --> ServerComponents
This diagram shows that both the YAML file and environment variables are combined before the settings are applied to the server.