Terraform Provider - Barndoor Documentation

Documentation Index

Fetch the complete documentation index at: /llms.txt

Use this file to discover all available pages before exploring further.

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

Manage MCP Access

Manage the LLM Gateway

Manage Data Protection

Best Practices

Provider Reference

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, and barndoor_policy look up existing objects by ID or name so you can reference them without managing them. barndoor_mcp_server_directory and barndoor_agent_directory look up catalog entries by slug or name, so onboarding a server or registering an agent needs no hand-copied IDs.

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 source: barndoor_llm_provider looks up a provider created in the Barndoor app by ID or name, so mappings, access policies, and pricing rules can reference it without managing it.

Data Control Center

Resource Manages
barndoor_dlp_org_config The organization’s data protection master switch and global dry-run mode
barndoor_dlp_detection_engine A detection engine (a Protection Profile in the app): which detection provider scans for which data types
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

Data source: barndoor_dlp_detection_engine looks up an existing Protection Profile by ID or name.

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:

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:

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