index.md

Terraform Provider

Manage your Barndoor organization as code with the official 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.

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

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.

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 {
  required_providers {
    barndoor = {
      source  = "barndoor-ai/barndoor"
      version = "~> 0.3"
    }
  }
}