Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.qa.tech/llms.txt

Use this file to discover all available pages before exploring further.

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 persisted to configs.environment_overrides for that environment ID.

​
Where overrides are stored

Config rows in public.configs include:
  • data: base config payload.
  • environment_overrides (jsonb): environment UUID -> config payload.
  • application_id (uuid | null): optional application scope used by the SaaS Config editor to limit selectable environments.
environment_overrides is persisted directly on each config row, not in a separate table.

​
How project defaults are built

Project-level defaults are constructed from:
  1. Application default environments (applications.default_environment_id).
  2. Config row environment_overrides, aggregated into a single configsByEnvironment map keyed by environment ID, then by config slug.
If multiple config rows 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 configs.data.
  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": "preview-user@example.com",
          "apiToken": "preview-token"
        }
      }
    },
    "configs": {
      "cfg-login_abc123": {
        "username": "global-user@example.com",
        "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.