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/edge-network
  • examples/search-platform
  • examples/statibeat

Search platform example​

The search platform 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.

Edge network example​

The edge network example is a good medium-size reference when you want a realistic service tree without the size of the search platform example.

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 customer-facing Service Area -> Service -> Region hierarchy that matches the current Hetzner footprint while leaving room for future regional Beats
  • service modeling for website access, trial signups, customer deployments, managed domains, notifications, Beats, control-plane provisioning, PostgreSQL, and release operations
  • a statuspage_beat_group example that rolls website-facing checks into one grouped operational surface
  • the same Beat and Beat Group model used by External Beat Triggers for provider-driven alerts
  • preset incident and maintenance copy tailored to StatiBeat's own product
  • custom views for customer journey, deployments, Beats, and platform foundations

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
  • Beats
  • Custom Views & RSS Feeds
  • View Alias Blocklist
  • Page & Site Settings
  • Slack
  • Managed Domains
  • Page Authentication
  • RBAC Roles, Bindings & SSO

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.

Exports that include Beats can also include External Beat Trigger endpoint metadata, external-event Beat configuration, and trigger rules. Existing ingest secrets are intentionally not exported; rotate or recreate ingest tokens after importing generated HCL into a new workspace.

For a focused External Beat Trigger Terraform example, see External Beat Triggers.

For new provider work, start with:

  1. a dedicated Terraform API key from the Terraform workspace
  2. a provider block that points base_url at your page or custom domain
  3. hierarchy levels and hierarchy items
  4. then settings, views, RBAC, and Slack/SSO resources as needed