Skip to content

Repository files navigation

Terraform Provider Kernel

Terraform provider for durable Kernel infrastructure configuration.

This provider manages desired state only. Browser/session runtime operations stay in the Kernel SDK and API.

Supported

Provider configuration:

  • api_key
  • base_url
  • project_id

Resources:

  • kernel_browser_pool
  • kernel_project

Data sources:

  • kernel_project
  • kernel_profile
  • kernel_proxy
  • kernel_extension

Import:

  • kernel_browser_pool by canonical browser pool ID
  • kernel_project by canonical project ID

Not Supported

The provider intentionally does not manage:

  • browser sessions
  • acquire, release, or flush
  • app invocation
  • logs, screenshots, or live view
  • runtime status or standby state
  • force-release or recovery operations
  • API key, profile, proxy, or extension resources
  • extension upload, download, delete, or Chrome Store operations

Quickstart

Configure credentials with environment variables:

export KERNEL_API_KEY="..."
export KERNEL_PROJECT_ID="..."

Use the provider:

terraform {
  required_providers {
    kernel = {
      source = "kernel/kernel"
    }
  }
}

provider "kernel" {}

resource "kernel_browser_pool" "example" {
  name                 = "example-pool"
  size                 = 1
  headless             = true
  kiosk_mode           = false
  stealth              = false
  start_url            = "https://example.com"
  timeout_seconds      = 90
  fill_rate_per_minute = 0
}

Import existing resources by canonical ID. For browser pools, the bare form resolves the project like create (provider default, else the API key's binding); use the project-qualified form to import from a different project:

terraform import kernel_browser_pool.example <browser-pool-id>
terraform import kernel_browser_pool.example <project-id>/<browser-pool-id>
terraform import kernel_project.example <project-id>

See the first public release guide for the exact public surface and for adopting existing Kernel projects or browser pools.

Local Development

Build the provider:

go build -o terraform-provider-kernel ./cmd/terraform-provider-kernel

Run unit tests:

go test ./...

Run vet:

go vet ./...

Local Terraform Testing

For local Terraform CLI testing, build the provider binary and use Terraform development overrides. The override value must be the absolute directory containing the terraform-provider-kernel executable.

# ~/.terraformrc
provider_installation {
  dev_overrides {
    "kernel/kernel" = "/absolute/path/to/terraform-provider-kernel"
  }

  direct {}
}

Then run Terraform from a directory containing provider configuration:

terraform plan

Do not run terraform init just to exercise this unreleased provider through dev_overrides; init can still try to resolve providers through the registry. Use init only when other providers or modules in the same configuration need it.

Acceptance Tests

Acceptance tests run automatically after changes reach main and can also be started manually through the Acceptance workflow. Local runs remain opt-in because they create real Kernel resources.

Required for all acceptance tests:

export TF_ACC=1
export KERNEL_ACC=1
export KERNEL_API_KEY="..."

Browser-pool and data-source acceptance tests additionally require:

export KERNEL_PROJECT_ID="..."

The tests create uniquely named durable resources and register independent cleanup. Browser-pool deletion remains force=false. The tests do not acquire, release, or recover browsers.

Use the commands in the selected-surface acceptance matrix. It is the source of truth for current live coverage and the pre-tag release run.

Architecture

See docs/architecture.md for package layout, Terraform semantics, testing strategy, and release planning.

About

terraform provider for kernel

Resources

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages