Terraform Provider

The official Barndoor Terraform provider lets you manage your organization’s configuration — MCP servers, access policies, LLM Gateway routing and controls, and data protection — as versioned, reviewable infrastructure-as-code. The provider is published on the Terraform Registry as barndoor-ai/barndoor and developed on GitHub.

Getting Started

Generate a provider credential, configure the provider, and apply your first resource.

Manage MCP Access

Onboard an MCP server, connect it, register an AI Agent, and govern access with a policy.

Manage the LLM Gateway

Configure providers, model routing with failover, access policies, rate limits, and budgets.

Manage Data Protection

Define custom detection types, allow lists, and enforcement policies with a safe rollout path.

Best Practices

Importing existing configuration, avoiding drift, CI/CD, and troubleshooting.

Provider Reference

The complete argument-level reference for every resource and data source, on the Terraform Registry.

What you can manage

This page groups the provider’s resources by product area. For argument-level detail, each resource links to its Terraform Registry reference page — the registry is always the authoritative schema documentation for the provider version you have installed.

MCP Gateway

Resource	Manages
`barndoor_mcp_server`	An MCP server instance created from a directory entry, including OAuth or pre-populated credentials
`barndoor_connection`	A tenant-wide credential connection to an MCP server (non-OAuth providers)
`barndoor_policy`	An MCP access policy: which AI Agents may call which tools, under what conditions
`barndoor_agent`	An AI Agent registration with your organization

Data sources: barndoor_mcp_server, barndoor_agent, barndoor_policy look up existing objects by ID or name so you can reference them without managing them.

LLM Gateway

Resource	Manages
`barndoor_llm_provider`	An upstream LLM provider (OpenAI, Anthropic, …) and its API credential
`barndoor_llm_model_mapping`	A route from a caller-facing model alias to an upstream model, with failover priority
`barndoor_llm_model_access`	An allowlist or denylist of models for an organization, group, or user scope
`barndoor_llm_rate_limit`	Requests-per-minute and tokens-per-minute ceilings on a scope
`barndoor_llm_token_budget`	Daily, weekly, or monthly token budgets with alert thresholds
`barndoor_llm_model_pricing`	Pricing rules used for cost attribution
`barndoor_llm_governance_config`	Organization-wide LLM Gateway governance settings

Data Control Center

Resource	Manages
`barndoor_dlp_org_config`	The organization’s data protection master switch and global dry-run mode
`barndoor_dlp_custom_detection_type`	Organization-defined detection types built from literal and regex patterns
`barndoor_dlp_allow_list_entry`	Allow-list entries that suppress false-positive findings
`barndoor_dlp_enforcement_policy`	Enforcement policies that block, redact, or tokenize findings in MCP or LLM traffic
`barndoor_dlp_field_control_policy`	Per-tool field rules applied to an MCP server’s tool output

Security & Access

Resource	Manages
`barndoor_idp`	Your organization’s enterprise SSO / OIDC federation
`barndoor_log_export`	Streaming audit-log export to your own S3-compatible storage

Data sources: barndoor_idp_settings, barndoor_log_export_aws_trust_info.

When to use Terraform

Terraform is the right tool when you want your Barndoor configuration to be reviewable, repeatable, and auditable — policy changes that go through pull requests, environments that can be rebuilt from code, and governance settings that can’t drift silently. A few things intentionally remain portal-only:

OAuth-connected MCP servers — the interactive browser consent step can’t be performed by a declarative apply. Terraform manages non-OAuth connections (api_key, bearer_token, basic_auth, generic); OAuth servers are connected in the Barndoor app.
SSO enforcement and break-glass accounts — enforcement is irreversible and member-impacting, so it stays behind the portal’s confirmation flow.
Interactive setup flows such as provider catalogs and connectivity testing.

Give each object exactly one owner: either Terraform or the portal. Managing the same policy or server from both places causes plans that fight the UI and vice versa. See Best Practices.

Versioning and stability

The provider follows semantic versioning. The platform APIs it uses are covered by Barndoor’s public API stability contract: changes within a major version are additive, and breaking changes ship as a new API version served in parallel with the old one for a deprecation window. Review the provider changelog before upgrading, and pin a version range in your configuration:

terraform {
  required_providers {
    barndoor = {
      source  = "barndoor-ai/barndoor"
      version = "~> 0.3"
    }
  }
}

Get Started

Use-Case Guides

Operations

Getting Started

Manage MCP Access

Manage the LLM Gateway

Manage Data Protection

Best Practices

Provider Reference

What you can manage

MCP Gateway

LLM Gateway

Data Control Center

Security & Access

When to use Terraform

Versioning and stability

Getting Started

Manage MCP Access

Manage the LLM Gateway

Manage Data Protection

Best Practices

Provider Reference

​What you can manage

​MCP Gateway

​LLM Gateway

​Data Control Center

​Security & Access

​When to use Terraform

​Versioning and stability

What you can manage

MCP Gateway

LLM Gateway

Data Control Center

Security & Access

When to use Terraform

Versioning and stability