Skip to content

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:

  1. YAML configuration file (usually named config.yaml).
  2. 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 and SLOP_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.