Skip to main content

Terraform Provider Overview

StatiBeat includes a standalone Terraform provider under terraform-provider/.

What it is for​

The provider is intentionally scoped to declarative configuration. The provider implementation currently exposes resources and data sources for configuration domains such as:

  • hierarchy levels
  • hierarchy items
  • status definitions
  • incident lifecycle stages
  • maintenance lifecycle stages
  • page and site settings
  • managed domains
  • page admin and viewer authentication providers
  • view alias blocklist entries
  • SSO group mappings
  • preset messages
  • Slack app settings
  • Slack channel reminder settings
  • custom views
  • RSS feeds
  • Beat Groups, Beats, external event sources, and External Beat Triggers

Data sources currently include:

  • hierarchy levels
  • hierarchy item lookup
  • custom views
  • RSS feeds
  • status events

These are declared in terraform-provider/internal/provider/provider.go.

What it is not for​

The provider schema description explicitly states that operational incident and maintenance actions are out of scope. In practice, that means the provider is not the tool for:

  • posting incident updates
  • resolving incidents
  • acknowledging incidents
  • managing Post-Incident Reports
  • executing maintenance actions
  • managing magic-link or one-time auth flows
  • manually unlocking protected custom views for end users
  • importing subscriber CSV files
  • exporting subscriber CSV snapshots
  • running bulk subscriber hygiene actions
  • reading page-traffic or delivery analytics dashboards

Provider versus export​

StatiBeat also includes a Terraform export feature in the application admin UI. That export workflow is separate from the provider itself:

  • the provider manages supported configuration directly
  • the export workflow generates Terraform artifacts from existing admin configuration

The dedicated Terraform admin workspace in the frontend makes this distinction visible by splitting setup and export into separate tabs.

Post-Incident Reports follow the same rule in v1: they are operational incident data, not declarative Terraform-managed configuration.

Protected custom-view policy fits the provider’s intended scope because it is durable page configuration. Terraform can own the access mode, approved email or domain rules, prompt text, and session TTL, while one-time viewer sign-in remains operational and out of scope.

Hosted embed configuration follows the same rule. Terraform can own whether the hosted badge or widget is enabled and what badge label is published, while the rendered SVG and iframe remain hosted public outputs instead of separate resources.

Hosted brand extensibility follows the same pattern. Terraform can own bounded custom CSS, approved external script hook URLs, and page-local locale defaults because they are durable settings, while the resulting rendered HTML, CSS, and browser execution remain hosted outputs rather than standalone Terraform resources.

Subscriber operations follow the opposite rule: CSV migration, suppression cleanup, bounce handling, and ad-hoc delivery recovery are operational workflows, so they stay in the admin UI and API rather than becoming Terraform resources.

Status-page analytics follow the same read-only pattern. Traffic, subscriber growth, incident activity, and delivery summaries are available through the app, API, and MCP for reporting, but they are not durable configuration and therefore stay outside Terraform resources and exports.