Skip to main content

Examples and Workflows

The repository already contains provider examples under terraform-provider/examples/.

Included examples​

The current tree includes at least these example sets:

  • examples/cloudflare
  • examples/elastic-cloud
  • examples/statibeat

Elastic Cloud example​

The Elastic Cloud example is the best current reference when you need a large, deeply nested, multi-cloud hierarchy.

It demonstrates:

  • a four-level Category -> Provider -> Region -> Component model
  • separate hosted, serverless, and global platform branches
  • status definitions and preset messages tuned for regional recovery, provisioning delays, and platform maintenance
  • custom views that slice the same hierarchy into hosted, serverless, global, search/ingest, and control-plane perspectives
  • site settings for a production-style public page

Because it creates nearly 600 hierarchy items, it is a better fit for realistic large-scale modeling than for the fastest local demo cycle. On hosted tenants, the first apply can take several minutes because the provider intentionally paces requests to stay within the authenticated admin write budget and avoid 429 responses.

By default, the example only creates the global_platform_services custom view so it still works on lower custom-view limits. You can expand enabled_custom_views in terraform.tfvars to create the rest on higher plans.

Cloudflare example​

The Cloudflare example is the clearest current reference for the scoped provider shape because its provider block includes:

  • base_url
  • token
  • organization_id
  • status_page_id

It demonstrates:

  • hierarchy levels
  • hierarchy items across multiple depths
  • status definitions
  • preset messages
  • custom views
  • site settings

StatiBeat example​

The StatiBeat example is the best reference when you want a status page that represents the product itself instead of mirroring a large third-party estate.

It demonstrates:

  • a concise two-level hierarchy built around platform areas and services
  • customer-readable service modeling that still maps back to Cloud Run delivery, runtime APIs, Cloud SQL, migrations, control-plane rollouts, SMTP, Slack, and Terraform
  • preset incident and maintenance copy tailored to StatiBeat's own product
  • custom views for customer-facing availability, admin operations, data/provisioning, and integrations

It is also the closest starting point for a status.statibeat.com style internal dogfooding page.

note

Like other fresh pages, a newly created StatiBeat example page will already contain seeded default status definitions. The current handwritten examples use the seeded status keys (operational, degraded, partial, outage, and maintenance), so a fresh page only needs to create the extra example-specific status definition before the first terraform apply.

Terraform export workflow​

Separate from handwritten Terraform, the admin UI can generate a Terraform export package. The export UI lets admins choose feature groups such as:

  • hierarchy
  • status definitions
  • incident lifecycle
  • maintenance lifecycle
  • preset messages
  • custom views and RSS feeds
  • settings
  • RBAC roles, bindings, and SSO group mappings

The export workflow also supports:

  • import block generation
  • import script generation
  • lock-plan generation
  • optional lockdown activation

These controls are implemented in application/frontend/src/pages/admin/TerraformExport.jsx.

For new provider work, start with:

  1. a dedicated Terraform API key from the Terraform workspace
  2. a provider block including organization_id, plus status_page_id if you are managing page-scoped resources
  3. hierarchy levels and hierarchy items
  4. then settings, views, RBAC, and Slack/SSO resources as needed