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.File Location
The gateway searches for configuration files in this order:GOLF_CONFIG_FILEenvironment variable (explicit path)/etc/golf-gateway/config.yaml/etc/golf-gateway/config.yml./golf-gateway.yaml(current directory)./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
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
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:
issuerandjwks_uriare required - For Descope:
project_idis required;issuerandjwks_uriare auto-generated - For Entra ID:
tenant_idis required
Servers
- Names must be unique across all servers
idpreferences must match an existing identity provider nameurlmust be a valid URL- When gateway and server both enable RBAC, their
rbac_modemust be consistent (cannot mixallowanddenyacross policy levels)
Exporters
- Names must be unique within each exporter type
- Elasticsearch: use
urlORcloud_id, not both - OTEL:
endpointrequired when enabled - Sentinel: all DCR and auth fields required when enabled
Security
rate_limiting.requests_per_minutemust be between 1 and 5000 when rate limiting is enabledrate_limiting.window_secondsmust be between 10 and 300 when rate limiting is enabled
Control Plane
- When present,
url,api_key, andgateway_idare required organization_idis optional — resolved from Control Plane during activation if not set- Mode is auto-detected:
control_planepresent = Distributed mode
Configuration Validation CLI
Validate configuration files before deployment:Related Documentation
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