Bruno V4 - Release Notes

Secret Manager configuration is moving into your environments

Action required for CLI / CI users

What's changing

In V4, external secrets configuration no longer lives in a secrets.json file at the root of your collection. It moves into your environment files, under a new externalSecrets section, and is managed from the Environment UI instead of from Collection Settings > Secrets.

You also get a simpler way to reference a secret - by its name directly:

Both resolve to the same value for now, so nothing breaks immediately. The old {{$secrets.*}} form is deprecated and will be removed after 3 months. Wherever the old syntax appears, the app marks it with an underline and a hover tooltip pointing you to the new form.

Why we're doing this

Secrets are environment-specific - your Production token is not your Staging token. Keeping configuration alongside the environment it belongs to is clearer, removes a separate root-level file, and makes the environment the single source of truth. It also brings full secret manager support to the CLI across AWS, Azure, and Vault, and adds support for workspace and global environments, which the old secrets.json model could not express.

What you need to do

Before and after

Before - secrets.json at collection root

{
  "type": "aws-secrets-manager",
  "data": [
    {
      "environment": "Production",
      "secrets": [
        { "name": "dbPassword", "secretName": "prod/db/credentials", "enabled": true },
        { "name": "apiKey", "secretName": "prod/payment-gateway/api-key", "enabled": true }
      ]
    }
  ]
}

After - YAML: environments/production.yml

name: Production
variables:
  - name: baseUrl
    value: https://api.example.com
externalSecrets:
  type: aws-secrets-manager
  variables:
    - name: dbPassword
      secretName: prod/db/credentials
      enabled: true
    - name: apiKey
      secretName: prod/payment-gateway/api-key
      enabled: true

After - BRU: environments/staging.bru

vars {
  baseUrl: https://staging.api.example.com
}
vars:externalsecrets:aws-secrets-manager {
  dbPassword: staging/db/credentials
  ~apiKey: staging/payment-gateway/api-key
}

Environment variable changes are saved to disk by default

Action required if scripts set sensitive values

What's changing

In V4, scripts that modify environment variables automatically persist those changes to disk. This makes script-driven variable updates consistent and predictable.

Who is affected

How to prepare

1. Audit your scripts for bru.setEnvVar(), bru.deleteEnvVar(), and bru.setGlobalEnvVar() usage that handles sensitive values
2. For sensitive values, switch those calls to bru.setVar() / bru.deleteVar(), which keep the value in memory for the run instead of persisting it
3. In V3.5.0+, enable the V4 migration option in the footer panel - it highlights these API calls in the sidebar, scripts, and tests so you can find and update them before upgrading

Multiple WebSocket messages

No migration needed - watch out on mixed-version teams

What's new

In V4, you can add multiple WebSocket messages to a single request. To support this, Bruno saves requests in a new message format. Existing requests keep working, and you can now define more than one message per WebSocket request.

Schema changes

body:ws {
  type: <json | text>
  content: '''
    <message payload>
  '''
}

body:ws {
  name: <message title>
  type: <json | text>
  selected: <true | false>
  content: '''
    <message payload>
  '''
}

message:
  type: <json | text>
  data: "<message payload>"

message:
  - title: <message title>
    selected: <true | false>
    message:
      type: <json | text>
      data: |-
        <message payload>

Descriptions and variable types

No migration needed - watch out on mixed-version teams

What's new

In V4, you can add descriptions to params, headers, multipart form fields, and variables, and assign types (@string, @number, @boolean, @object) to your variables. Bruno stores these as annotations on the line above each pair.

Schema changes

headers {
  Content-Type: application/json
  Authorization: Bearer {{token}}
}
params:query {
  page: 1
}
vars:pre-request {
  baseUrl: https://api.example.com
  retryCount: 3
}

headers {
  @description('Payload format for the request')
  Content-Type: application/json
  @description('Bearer token used for auth')
  Authorization: Bearer {{token}}
}
params:query {
  @description('Page number to fetch')
  page: 1
}
vars:pre-request {
  @string
  @description('Base URL for all requests')
  baseUrl: https://api.example.com
  @number
  retryCount: 3
}

http:
  headers:
    - name: Content-Type
      value: application/json
    - name: Authorization
      value: Bearer {{token}}
  params:
    - name: page
      value: "1"
      type: query
runtime:
  variables:
    - name: baseUrl
      value: https://api.example.com
    - name: retryCount
      value: "3"

http:
  headers:
    - name: Content-Type
      value: application/json
      description: Payload format for the request
    - name: Authorization
      value: Bearer {{token}}
      description: Bearer token used for auth
  params:
    - name: page
      value: "1"
      type: query
      description: Page number to fetch
runtime:
  variables:
    - name: baseUrl
      value: https://api.example.com
      description: Base URL for all requests
    - name: retryCount
      value:
        type: number
        data: "3"

CLI JUnit report: classname now uses the request path

Action required if you consume CLI JUnit output in CI

What's changing

In the CLI JUnit reporter, each test case's classname attribute changes from the request URL to the collection path to the request - for example, Users/Get Users for a request named "Get Users" inside a "Users" folder.

Why we're doing this

CI tools like Xray and Azure DevOps use classname + name as a test's unique identifier. Because the URL changes per environment, the same test produced a different classname in staging vs. production and showed up as duplicate test cases. The collection path is stable across environments.

Who is affected

• Teams that feed the CLI JUnit report into Xray, Azure DevOps, or similar tools
• Anyone with scripts that read classname expecting a URL

Before and after

<testcase
  name="Status is 200"
  classname="https://prod.api.example.com/users"
/>

<testcase
  name="Status is 200"
  classname="Users/Get Users"
/>