Components & config

Valved’s control plane references components by name rather than containing their code. A component is an independently-versioned unit — a dlt extract-load source, a dbt project, or SQL glue — that follows its own repo, CI/CD, and lifecycle. A pipeline composes components into a step DAG.

Simple mode vs multi mode

Simple mode (the default). Omit [components.<name>] blocks entirely. Components are discovered by convention: each el/<name>/ directory is a dlt component, and the single detected dbt project is a dbt component. Convention-discovered components track branch HEAD — zero pinning, zero friction.
Multi mode. Add a [components.<name>] block when a component graduates to its own path or repo. Graduation is a single guided command (valved component <name> --separate-remote …) and requires no pipeline rewrites — pipelines still reference the component by the same name.

[project]
name = "jaffle-shop"
default_target = "dev"
valved_version = ">=0.1,<0.2"

[state_store]
url = "${DATABASE_URL}"          # Postgres only; env-var interpolation

[components.analytics]           # a dbt component graduated to its own repo
type = "dbt"
mode = "separate-remote"
url  = "git@github.com:acme/analytics.git"
ref  = "9f3a1c7"                 # optional pin (SHA or tag)

[components.stripe_charges]      # a dlt component in a sibling checkout
type = "dlt"
mode = "separate-local"
path = "/path/to/ingest-stripe"

Pin precedence: ref (exact pin) → branch (track that branch’s HEAD) → the remote’s default-branch HEAD.

Inspect what’s resolved:

valved components show           # name, type, mode, resolved ref/path, referencing pipelines

The config files

valved init scaffolds these under the project root:

File	What it holds
`valved.toml`	Control-plane config: project name, `default_target`, `[state_store]`, and any `[components.<name>]` references.
`valved/connections.toml`	Named targets (`dev`, `prod`, …) — each carries a warehouse dialect and role-scoped credentials (referenced, never inlined).
`valved/runner.toml`	Venv-backed execution knobs (timeouts, concurrency) and the recovery `[auto_fix]` budget.
`valved/models.toml`	How the harness authenticates to Anthropic (`api_key` or `oauth`) and the default model + optional tiers.
`valved/runtime.toml`	(optional, not scaffolded) Supervisor-loop tuning: scheduler, reaper, worker slots, archive windows, recovery budget, the tighten-only `[permissions]` block, API CORS.
`pipelines/<name>.toml`	A pipeline: its step DAG and optional `[seed_schedule]`. Authored by `plan`/`build`, not by hand.

Credentials are referenced via ${ENV_VAR} or { file = "/path" } (for Docker/K8s secrets). Valved never stores secrets in the state store.

The full schema for every file — including agent frontmatter, skills, hooks, and MCP config — is in the Configuration reference.

Targets

A target is a named environment a run executes against. dev and prod are typical; default_target lives in valved.toml, and each target’s connection lives in valved/connections.toml.

valved target list
valved target create staging
valved run <pipeline> --target prod

Snowflake and DuckDB are first-class dialects; Postgres, BigQuery, Databricks, and SQL Server are supported via sqlglot.