Config Environment Overrides

How config environment overrides are stored, merged, and resolved at runtime.

This page explains how config environment overrides are stored, merged, and resolved at run time.

Overview

Config environment overrides let you assign different payloads for the same config slug based on the selected environment.

The system supports two override layers:

• Environment-scoped overrides via configsByEnvironment.
• Plan-wide overrides via configs.

When both are present for the same config slug, the plan-wide value wins.

Add config overrides in the UI

In the SaaS app, you can configure environment-scoped overrides directly on a config:

1. Go to your project’s Configs page.
2. Open an existing config and click Edit.
3. In Environment Overrides, select the application for this config.
4. Under Add Environment Override, choose the environment you want to override and click Add.
5. Update the override fields for that environment.
6. Click Save on the config form.

After save, the override is saved on that config and linked to the selected environment.

How project defaults are built

Project-level defaults are constructed from:

1. The application’s default environment selection.
2. Config environment overrides, aggregated into a single configsByEnvironment map keyed by environment ID, then by config slug.

If multiple configs define overrides for the same environment, each config slug is merged into that environment map.

Merge order across project, test plan, and run request

Before execution, parameters are merged in this order, with later values overriding earlier values:

1. Project parameters.
2. Test plan parameters.
3. Runtime request parameters (triggerData.parameters).

This merged object is written to the blueprint and used during test preparation and execution.

Effective config resolution order

For a given test and config slug, resolved value precedence is:

1. Base payload from the config.
2. parameters.configsByEnvironment[environmentId][configSlug] (if the test has an environment ID and a matching override exists).
3. parameters.configs[configSlug].

This means configs always overrides configsByEnvironment for the same slug.

Runtime API shape

POST /v1/run accepts config overrides under parameters:

{
  "testPlanShortId": "pln_my-plan_123",
  "parameters": {
    "configsByEnvironment": {
      "b73dc3c3-92b0-4f15-83b0-500c42ecd95c": {
        "cfg-login_abc123": {
          "username": "[e-mail]",
          "apiToken": "preview-token"
        }
      }
    },
    "configs": {
      "cfg-login_abc123": {
        "username": "[e-mail]",
        "apiToken": "global-token"
      }
    }
  }
}

In this payload, the effective value for cfg-login_abc123 is the configs entry because it has higher precedence.

Key format and normalization notes

• configs and configsByEnvironment preserve raw map keys as provided.
• Config identifiers are treated as string keys (typically config short IDs or slugs).
• Environment-specific overrides are only considered when execution has a concrete environmentId.