Configuration
Overview
Pipelex uses a TOML-based configuration system with shipped defaults plus project-level overrides.
- Shipped defaults: Pipelex ships default values that are maintained in the Pipelex repository (contributors will see them in the repo root
pipelex.toml). This is the baseline used by the installed package. - Project overrides: a project that uses Pipelex typically customizes behavior via files created in
.pipelex/.
You can create the configuration files by running:
pipelex init config # creates the global config at ~/.pipelex/
pipelex init config --local # creates the project config at {project_root}/.pipelex/
Configuration Setup Notes
- By default
pipelex init configtargets the global~/.pipelex/directory; pass--localto create the project-level.pipelex/instead. pipelex init configcreates a template configuration file with sample settings. It does not include all possible configuration options - it's meant as a starting point.- Running
pipelex init configwill overwrite your existingpipelex.tomlfile without warning. Make sure to backup your configuration before running this command. - Credentials (
~/.pipelex/.env) and the Gateway service-agreement file always remain in the global~/.pipelex/directory regardless of--local— only config, inference, and telemetry files are written to the project.pipelex/.
For a complete list of all possible configuration options, refer to the configuration group documentation below.
Where to edit configuration in a project
The main project configuration files are:
.pipelex/pipelex.toml: project customization (logging, reporting, feature flags, etc.).pipelex/telemetry.toml: custom telemetry destinations.pipelex/inference/…: inference backends, routing profiles, and model presets
Overrides (advanced)
In addition to the base pipelex.toml, Pipelex applies override files from inside each .pipelex/ directory (both the global ~/.pipelex/ and the project's .pipelex/) for machine- and environment-specific settings:
pipelex_local.tomlpipelex_{environment}.toml(example:pipelex_dev.toml) — selected by thePIPELEX_ENVenvironment variable (see Selecting the environment)pipelex_{run_mode}.toml(example:pipelex_normal.toml; unit tests usetests/pipelex_unit_test.toml, the one override file read outside a.pipelex/directory)pipelex_override.toml(recommended to gitignore)pipelex_temporary_override.toml(recommended to gitignore)
Contributor details
For the full “where defaults live” and “how config is merged” explanation, see Configuration Internals.
Configuration Structure
The configuration is organized into four main sections:
[pipelex]- Core Pipelex settings[cogt]- Cognitive tools and LLM settings[plugins]- Plugin-specific configurations[migration]- Migration helpers for renamed settings
Each section contains multiple subsections for specific features and functionalities.
Configuration Override System
Pipelex uses a sophisticated configuration override system that loads and merges configurations in a specific order. This allows for fine-grained control over settings in different environments and scenarios.
The exact loading sequence is (later wins, per leaf key):
- Base configuration from the installed Pipelex package (
pipelex.toml) - Global base configuration (
~/.pipelex/pipelex.toml) - Global override sequence, from
~/.pipelex/:pipelex_local.toml,pipelex_{environment}.toml,pipelex_{run_mode}.toml,pipelex_override.toml,pipelex_temporary_override.toml - Your project's base configuration (
{project_root}/.pipelex/pipelex.toml) - Project override sequence, from the project's
.pipelex/: the same five files as step 3 - Programmatic overrides passed in code, if any
Notes on the override sequence:
pipelex_{environment}.toml(example:pipelex_dev.toml) is selected by thePIPELEX_ENVenvironment variable (see Selecting the environment)pipelex_{run_mode}.toml— example run modes: normal, unit_test; under unit testing the run-mode overlay is sourced exclusively from./tests/pipelex_{run_mode}.toml- Each subsequent configuration file in this sequence can override settings from the previous ones, and project-level files override the global
~/.pipelex/layer
Override File Naming
- Base config:
pipelex.toml - Local overrides:
pipelex_local.toml - Environment overrides:
pipelex_dev.toml,pipelex_staging.toml,pipelex_prod.toml, etc. - Run mode overrides:
pipelex_normal.toml,tests/pipelex_unit_test.toml, etc. - Final overrides:
pipelex_override.toml
NB: The run_mode unit_test is used for testing purposes.
Selecting the environment
The pipelex_{environment}.toml overlay is picked at runtime from the PIPELEX_ENV environment variable.
| Value | Overlay file loaded |
|---|---|
local |
pipelex_local.toml (also loaded as the local override layer; see above) |
dev |
pipelex_dev.toml |
staging |
pipelex_staging.toml |
prod |
pipelex_prod.toml |
If PIPELEX_ENV is unset, Pipelex defaults to dev. Any other value raises an error at startup — the accepted values are defined by the RunEnvironment enum in pipelex/system/runtime.py.
The selected environment is also stamped on OpenTelemetry spans as deployment.environment, so it doubles as the environment label for traces and metrics.
Set it the way you set any other env var — for example, in your shell, your .env file, your CI configuration, or your container runtime:
export PIPELEX_ENV=staging
Best Practices for Overrides
- Use the base
pipelex.tomlfor default settings - Use
pipelex_local.tomlfor machine-specific settings - Use environment files for environment-specific settings (dev, staging, prod)
- Use run mode files for normal or unit_test configurations
- Use
pipelex_override.tomlsparingly, only for temporary overrides (add to .gitignore)
Best Practices
- Version Control: Include your base
pipelex.tomlin version control - Environment Overrides: Use environment-specific files for sensitive or environment-dependent settings
- Documentation: Comment any custom settings for team reference
- Validation: Run
pipelex validate --allafter making configuration changes - Gitignore: Add local and sensitive override files to
.gitignore