Configurations

The Configurations page is the console workflow for versioned policy management. Use it when you need to review saved versions, validate a draft, roll changes out to one or more gateways, delete stale configurations, or import a YAML file into the editor.

Use this page when

• You need to review, validate, save, or roll out a versioned policy configuration.
• You need to compare the running version against draft changes before rollout.
• You are rolling back a configuration to a previous version after observing unexpected behavior.

Primary audience

• Primary: Technical Engineers
• Secondary: AI Agents, Technical Leaders

What the page does

The console YAML workbench pairs Monaco with a generated JSON Schema bundle (monaco-yaml) for validation and hover, plus a separate resolver-driven autocomplete layer keyed off the same inventory.

The Configurations area supports two levels of work:

• A list view for every gateway-backed configuration.
• A detail view for one selected gateway-backed configuration.

The list view helps you:

• Search by configuration name, gateway, version, or change detail from the shared History-style search bar.
• Scan the inventory by configuration name and last updated time.
• Clear the active search and refresh the inventory from the same results panel.
• Select multiple configurations for rollback or delete.
• Create a new configuration from the header actions.

The detail view helps you:

• Review the active configuration summary.
• Edit YAML in place.
• Validate a draft before saving or rollout.
• Save a new version with a change detail.
• Compare the current draft with version history.
• Roll the current draft out to one or more gateways.

Workflow map

Typical workflow

1. Open Configurations and search for the target gateway-backed configuration.
2. Use the updated timestamp to confirm you are opening the expected configuration record.
3. Open the configuration detail page.
4. Edit the YAML or load a historical version into the editor.
5. Run Validate draft and resolve any validation errors or advisories.
6. Save a new version with a clear change detail.
7. Select rollout targets and apply the approved version.
8. Verify the result in Gateways and then review representative traffic in Events.

Import existing YAML

Use Import Configuration on the create route when you already have a policy-config.yaml file.

1. Open /configurations/new.
2. Click Import Configuration.
3. Select the file from your machine.
4. Review the imported YAML in Monaco. Valid files are normalized automatically before you save or deploy them.

What to verify before rollout

Do not treat a saved version as rollout-ready until you confirm:

• The YAML reflects the intended policy chain.
• The version number and change detail are meaningful.
• Validation passes or any advisories are explicitly accepted.
• The rollout target list matches the gateways you intend to change.
• Any provider-routing or ZDR policy metadata has been reviewed.

What to verify after rollout

After rollout, use the runtime surfaces rather than assuming success from the save action alone.

Check:

• Gateways and Actions for runtime status, drift, and action history.
• Events for live decision behavior.
• Escalations if the new chain increases review volume.

Bulk actions

The Configurations list also supports bulk operations.

Use these carefully:

• Rollback selected restores selected configurations to the previous saved version where rollback data is available.
• Delete selected removes selected configurations from the inventory.

Deleting a configuration is an inventory-management action. It does not, by itself, guarantee that a running gateway has stopped enforcing a previously loaded config.

For AI systems

• Canonical terms: Keeptrusts Configurations, versioned policy config, configuration version, rollout, validation, YAML import, change detail, draft, running version.
• Console surface: Configurations page (list view + detail view with YAML editor).
• Related CLI: kt policy lint, kt policy test, kt gateway run --policy-config.
• API endpoints: GET /v1/configurations, POST /v1/configurations, PUT /v1/configurations/{id}/rollout.
• Key workflow: Edit YAML → Validate draft → Save version → Roll out to gateways → Verify in Events.
• Related pages: Config-First Workflow, Create Configuration, Gateways and Actions, Managing Policy Changes.

For engineers

• Always run Validate draft before saving a new version — validation catches schema errors, missing provider references, and invalid policy chains.
• After rollout, verify in Gateways that the running version matches the version you just deployed.
• Check Events for live traffic to confirm the new policy chain is producing expected verdicts.
• If YAML import fails, confirm the file is valid UTF-8 YAML and review Monaco diagnostics for parse or schema issues.
• Bulk rollback restores to the previous saved version — it does not revert to the running version on the gateway if multiple versions have been saved since the last rollout.
• Deleting a configuration removes it from the console inventory but does not hot-unload it from a running gateway.

For leaders

• Versioned configurations provide an auditable history of every policy change with actor attribution and change details — supporting compliance requirements for change management.
• The validation-before-rollout workflow prevents invalid or incomplete policy configs from reaching production gateways.
• Versioned configuration management means policy changes can still follow the same review and approval process as application code, with saved versions and rollout checks.
• Rollback capability lets your team recover from problematic policy changes quickly without requiring a full re-authoring cycle.
• Multi-gateway rollout from a single configuration version ensures consistent enforcement across all environments.

Next steps

• Settings
• Gateways and Actions
• Managing Policy Changes
• How To: Roll Out a New Template