Workloads

Credentials | Workloads | Policies

A workload is a named identity scope within your organization. Requests tagged with a workload ID are grouped for policy evaluation, attribution defaults, and spend tracking. You decide how to map workloads to your systems; common patterns include one workload per application, per team, per environment, or per deployment tier.

Table of Contents

• Managing workloads in the console
• Identity and attribution scopes
• Managing workloads on the Self-Hosted Gateway
  • File structure
  • Field reference
  • Default attribution fields
  • allowed_connection_types valid values
  • Pushing workloads at runtime
• Related Topics

Managing workloads in the console

Go to Workloads in the left nav. From there you can:

• Add a workload: enter a name (required) and optionally a workload ID (auto-generated if left blank); the console creates it in your org automatically
• View workloads: see all registered workloads and their attribution defaults
• Edit a workload: update the name, allowed connection types, description, default labels, and the default attribution fields (project/account/customer ID). The edit form pre-populates from the workload's current values, so leaving a field as-is keeps it unchanged and blanking a field clears it — saving doesn't touch fields you never opened the form for.
• Delete a workload: removes the workload registration; existing records are retained

When your org is created, a default workload is provisioned automatically so you can start sending requests immediately without a separate registration step. All traffic is attributed to this workload until you create additional workloads and configure your callers to pass the appropriate workload ID.

Identity and attribution scopes

Every request carries an org_id (the tenant) and, independently, a workload_id and a project_id. workload_id and project_id are not a parent/child hierarchy — a project is never owned by a single workload, and many workloads can attribute spend to the same project.

A workload can configure a default_project_id (see Field reference below) as a convenience: when a caller's request omits project_id, the gateway fills it in from the workload's default before falling back to the org's own default. This is a fallback value, not a structural link — a single workload's requests can still freely specify any project_id explicitly, and deleting or renaming a project never affects the workloads that happen to default to it.

Risk scoring baselines are maintained per workload; a spike on one workload does not affect the score for another. See Risk Scoring for how baselines and signals work.

Managing workloads on the Self-Hosted Gateway

Location: configs/workloads/workloads.yaml (env: MVGC_WORKLOADS_DIR)

File structure

workloads:
  - workload_id: wl_prod_app_1
    org_id: org-example-001
    name: "Production Application"
    default_project_id: prj_default
    default_account_id: acct-default
    default_customer_id: cust-default

  - workload_id: wl_dev_app_1
    org_id: org-example-001
    name: "Development Application"
    default_customer_id: cust-dev
    default_account_id: acct-dev
    default_project_id: prj_dev
    default_labels:
      env: dev
    allowed_connection_types:
      - direct_api

Field reference

Default attribution fields

The default_project_id, default_account_id, default_customer_id, and default_labels fields are applied to execution records when the caller does not supply them. They allow you to set a consistent chargeback and reporting baseline for a workload without requiring every caller to pass attribution fields on every request.

allowed_connection_types valid values

Each execution record carries two independent dimensions that describe how the request arrived:

Connection Type — the transport mechanism:

Traffic Class — the behavioral intent (recorded per request; not a workload restriction):

allowed_connection_types restricts the first dimension only. When omitted (the default in the Customer Console), all connection types are permitted. To restrict a workload to direct API calls only:

allowed_connection_types:
  - direct_api

Pushing workloads at runtime

Register a workload

curl -X PUT http://localhost:7080/v1/admin/workloads \
  -H "MVGC-Admin-Token: $MVGC_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workload_id": "wl_prod_app_1",
    "org_id": "org-example-001",
    "name": "Production Application",
    "default_project_id": "prj_default",
    "default_account_id": "acct-default",
    "default_customer_id": "cust-default",
    "allowed_connection_types": ["direct_api"]
  }'

Related Topics

• Policies — how the identity layer uses workload_id in policy conditions
• Risk Scoring — per-workload behavioral anomaly detection