Skip to main content

YAML Configuration Schema

Golf Gateway supports YAML configuration for Distributed mode deployments, where server configurations are defined locally in a YAML file while organization policies and monitoring are managed through the Control Plane. This reference documents the complete YAML schema with all fields, types, and validation rules.

When to Use YAML Configuration

Use YAML configuration when you want to:
  • Version control your MCP server configurations alongside your infrastructure code
  • GitOps workflows where server definitions are managed through pull requests
  • Local server definitions while still benefiting from Control Plane’s centralized policy management and monitoring
YAML configuration works in Distributed mode only. The mode is auto-detected: when a control_plane section is present in the YAML, the gateway runs in Distributed mode. For fully managed deployments without local configuration files, use Centralized mode where all settings are managed through the Golf Control Plane.

Quick Start Example

Here’s a complete, annotated configuration showing the most common settings:
golf-gateway.yaml
Use ${VAR} for required environment variables or ${VAR:default} for optional ones with defaults.
Scroll down for detailed documentation of each section.

File Location

The gateway searches for configuration files in this order:
  1. GOLF_CONFIG_FILE environment variable (explicit path)
  2. /etc/golf-gateway/config.yaml
  3. /etc/golf-gateway/config.yml
  4. ./golf-gateway.yaml (current directory)
  5. ./golf-gateway.yml (current directory)

Environment Variable Interpolation

YAML configuration supports environment variable substitution:

Root Configuration

Root Fields

The deployment mode is auto-detected: if control_plane is present, the gateway runs in Distributed mode. If absent, it runs in Standalone mode. No explicit mode field is needed.

Identity Providers

Configure OAuth/OIDC identity providers for authentication.

Identity Provider Fields

Descope-Specific Fields


Servers

Configure MCP upstream servers with RBAC and security settings.

Server Schema

servers
array
List of upstream MCP server configurations.

Gateway Policy

Gateway-level policy defaults that apply to all servers unless overridden. In distributed mode, these are merged with organization policies from the Control Plane.

Scrubbing Policy

The scrubbing configuration uses the same schema at both gateway and server levels. All fields are merged using union — if any layer adds a field or rule, it applies.
When recognizer configs are merged across layers (org → gateway → server), enabled: true wins over enabled: false (most-restrictive doctrine). Server-specific replacement text overrides gateway defaults.

Server RBAC Policy

Capability RBAC Policy

Local Servers Policy

Controls the gateway-level blocking policy for locally-defined servers.

Security

The security section controls replay protection and rate limiting. This is operational configuration, not policy — it does not participate in the org → gateway → server policy merge cascade.

Replay Protection

Rate Limiting

YAML configures the per-user limit only. System-wide (global) and per-server limits are managed through the Control Plane. See Configure Rate Limiting for the full model.

OAuth Server

Configure the gateway’s MCP OAuth authorization server for third-party server authentication flows.

Exporters

Configure multiple export destinations for audit logs. You can configure multiple exporters of each type.

Exporter Schema

exporters
object
Configure audit log export destinations.
For Elasticsearch, use either url (self-hosted) or cloud_id (Elastic Cloud), not both.

Control Plane Connection

Connects the gateway to the Control Plane for centralized policy management and monitoring. The presence of this section activates Distributed mode.

Complete Example

A complete Distributed mode configuration with Control Plane connection, identity providers, servers, security, and exporters:

Validation Rules

Version

  • Must be exactly "1.0"
  • Required field

Identity Providers

  • Names must be unique across all providers
  • For non-Descope providers: issuer and jwks_uri are required
  • For Descope: project_id is required; issuer and jwks_uri are auto-generated
  • For Entra ID: tenant_id is required

Servers

  • Names must be unique across all servers
  • idp references must match an existing identity provider name
  • url must be a valid URL
  • When gateway and server both enable RBAC, their rbac_mode must be consistent (cannot mix allow and deny across policy levels)

Exporters

  • Names must be unique within each exporter type
  • Elasticsearch: use url OR cloud_id, not both
  • OTEL: endpoint required when enabled
  • Sentinel: all DCR and auth fields required when enabled

Security

  • rate_limiting.requests_per_minute must be between 1 and 5000 when rate limiting is enabled
  • rate_limiting.window_seconds must be between 10 and 300 when rate limiting is enabled

Control Plane

  • When present, url, api_key, and gateway_id are required
  • organization_id is optional — resolved from Control Plane during activation if not set
  • Mode is auto-detected: control_plane present = Distributed mode

Configuration Validation CLI

Validate configuration files before deployment:

Environment Variables

Configure Golf Gateway using environment variables

Audit Log Schema

Complete audit log entry structure reference

RBAC Configuration

Set up role-based access control

Deployment Guide

Deploy Golf Gateway to production