Skip to main content
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

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

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

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

​
Security & Access

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 — including the Slack app install a slack notification channel depends on, and the channel test action.
  • Personal notification preferences — a user’s own in-app and email alert settings belong to that user, not to the organization, so Terraform manages only the organization-wide channels.
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: