README
¶
Terraform Provider for Daytona
This repository contains a Terraform Plugin Framework provider for Daytona. It lets teams manage Daytona sandboxes and supporting Daytona infrastructure with the same Terraform workflows they use for AWS, Azure, GCP, and other enterprise platform dependencies.
Features
- Provider configuration through
DAYTONA_API_KEY,DAYTONA_ACCESS_TOKEN,DAYTONA_API_URL, andDAYTONA_ORGANIZATION_ID - Daytona managed-service default API URL:
https://app.daytona.io/api - Coverage across the Daytona control plane, grouped by area:
- Platform — runners, regions, region quotas, Docker registries, snapshots, volumes
- Governance — organizations, roles, member access, invitations, API keys, OpenTelemetry config
- Sandboxes — a sandbox lifecycle resource plus a broad set of sandbox and observability data sources
The provider exposes 15 resources and 70 data sources, all backed by Daytona's
generated Go OpenAPI client (github.com/daytonaio/daytona/libs/api-client-go).
Documentation
The full reference for every resource and data source is generated into
docs/ with tfplugindocs
and rendered on the Terraform Registry.
Example
terraform {
required_providers {
daytona = {
source = "536tech/daytona"
}
}
}
provider "daytona" {}
resource "daytona_volume" "workspace" {
name = "workspace-cache"
}
resource "daytona_sandbox" "agent" {
name = "agent-runtime"
snapshot = "daytonaio/sandbox:0.6.0"
desired_state = "started"
labels = {
managed-by = "terraform"
}
}
data "daytona_current_api_key" "current" {}
data "daytona_organizations" "available" {}
Set credentials with environment variables:
export DAYTONA_API_KEY="dtn_..."
export DAYTONA_ACCESS_TOKEN="eyJ..."
export DAYTONA_API_URL="https://app.daytona.io/api"
Daytona API keys work for API-key-enabled routes such as current API-key lookup and volume management. Daytona org/user provisioning and discovery routes are JWT-only in the current Daytona API; set DAYTONA_ACCESS_TOKEN and DAYTONA_ORGANIZATION_ID for those routes. When both token types are set, DAYTONA_ACCESS_TOKEN takes precedence.
Use From GitHub Source
Terraform provider installation uses provider addresses rather than module-style GitHub sources. Until this provider is published to Terraform Registry, install the provider binary from GitHub and point Terraform at the local build:
go install github.com/536tech/terraform-provider-daytona@v0.10.0
cat > ~/.terraformrc <<EOF
provider_installation {
dev_overrides {
"536tech/daytona" = "$HOME/go/bin"
}
direct {}
}
EOF
Terraform configurations and modules can then use the same provider address shown above:
terraform {
required_providers {
daytona = {
source = "536tech/daytona"
}
}
}
This repository also includes a reusable module example that can be consumed directly from GitHub:
module "daytona_sandbox" {
source = "github.com/536tech/terraform-provider-daytona//examples/modules/daytona-sandbox?ref=v0.10.0"
name = "agent-runtime"
snapshot = "daytonaio/sandbox:0.6.0"
desired_state = "started"
}
Use Cases
Ephemeral sandboxes are usually created at runtime with the Daytona SDK; this provider's sweet spot is the durable platform layer those sandboxes depend on. examples/use-cases contains complete configurations for:
- self-hosted-region — register
bring-your-own-compute regions and runners natively, with real destroy,
drift detection, and credential rotation (replaces the
terracurlcalls in daytonaio/terraform-modules). - organization-governance — custom roles, member access, invitations, region quotas, and OpenTelemetry export as reviewable code.
- golden-snapshot-pipeline — registry credentials, versioned golden snapshots, and shared volumes that SDK-created sandboxes consume.
- ci-service-api-keys — least-privilege, expiring API keys for CI systems and service accounts.
The use-case examples rely only on resources and data sources, so they work with both Terraform and OpenTofu.
Development
Requirements:
- Go 1.25 or newer
- Terraform 1.0 or newer
Run the local test suite:
go test ./...
Install and run local hooks:
prek install
prek run --all-files
Run API-key live acceptance tests:
TF_ACC=1 DAYTONA_API_KEY="dtn_..." \
go test ./internal/provider -run 'TestAcc(CurrentAPIKeyDataSource|VolumeResource|SandboxResource)_basic' -v
Run the opt-in resource acceptance tests. The Docker registry test needs an API key with the WRITE_REGISTRIES permission, and the snapshot test builds a real image:
TF_ACC=1 DAYTONA_API_KEY="dtn_..." DAYTONA_ACC_REGISTRY=1 \
go test ./internal/provider -run TestAccDockerRegistryResource_basic -v
TF_ACC=1 DAYTONA_API_KEY="dtn_..." DAYTONA_ACC_SNAPSHOT_BUILD=1 \
go test ./internal/provider -run TestAccSnapshotResource_basic -v
Run JWT-only org/user acceptance tests:
TF_ACC=1 DAYTONA_ACCESS_TOKEN="eyJ..." DAYTONA_ORGANIZATION_ID="org-..." \
go test ./internal/provider -run 'TestAcc(CollectionDataSources|LookupDataSources|OperationalDataSources)_basic' -v
Run the Daytona readiness acceptance test with a health-check API key:
TF_ACC=1 DAYTONA_HEALTH_CHECK_API_KEY="dtn_..." \
go test ./internal/provider -run TestAccHealthDataSource_basic -v
Acceptance tests create real Daytona resources. Volume create/delete was verified live after adding lifecycle polling for Daytona's asynchronous volume states. The full org/user suite requires an OAuth access token because the current Daytona API rejects normal API keys on JWT-only routes; Daytona CLI API-key login has the same organization-command limitation and is not a substitute for browser/OAuth authentication.
If an acceptance run is interrupted and leaves resources behind, clean up everything created with the tf-acc- name prefix using the sweepers:
DAYTONA_API_KEY="dtn_..." go test ./internal/provider/ -sweep=all
Generate provider documentation:
make generate
Validate release packaging:
make release-check
make release-snapshot
Contributing
See CONTRIBUTING.md for build, test, documentation, and pull request guidelines.
License
This provider is distributed under the Mozilla Public License 2.0.
Documentation
¶
There is no documentation for this package.