Skip to main content
This page shows complete, annotated provider examples. Each example explains the design decisions inline so you can understand not just what the code does, but why.

Cloud Resource Provider Pattern

This example shows the pattern used by real cloud providers: user-provided credentials, idempotent operations, and proper error handling. Based on the GCP Secret Manager provider.

The Complete Resource

Key Patterns to Note

This provider requires explicit credentials rather than using Application Default Credentials (ADC) or Workload Identity. This is the right choice when:
  • Your platform is multi-tenant
  • Users manage resources in their own cloud accounts
  • You cannot assume ambient credentials exist
For single-tenant deployments where the provider runs with cluster credentials, you could simplify to:
The config distinguishes between:
  • Immutable: project_id, secret_id - Changing these would create a different resource in GCP
  • Mutable: data - Can be updated in place (via new version)
The on_update method validates immutable fields and raises clear errors explaining the workaround (delete and recreate).
Each lifecycle method uses a different idempotency pattern:

Webhook Integration Pattern

This example shows a different pattern: integrating with an external webhook-based API. Common for SaaS integrations, CI/CD systems, and notification services.

When to Use This Pattern

The webhook pattern works well for:
  • Notification channels: Slack, Discord, PagerDuty webhooks
  • CI/CD triggers: Jenkins, GitHub Actions, GitLab pipelines
  • External SaaS: Services configured via API but not “created”
Key characteristics:
  • External service doesn’t persist your configuration
  • “Create” validates the integration works
  • “Delete” has nothing to clean up

Comparison of Patterns

Testing Both Patterns

Both patterns test the same way using ProviderHarness:

What’s Next

Testing

Learn more about testing patterns with ProviderHarness.

Deployment

Deploy your provider to the platform.