Terraform and CDKTF

Use Terraform when you want HCL. Use CDKTF TypeScript or Python when you want code that synthesizes the same Terraform resources. All three workflows use the same skippr/cloud provider lifecycle and the same generated cloud_* resource types.

Status: Preview.

At a glance

Fact	Value
Terraform provider	skippr/cloud
Provider version	0.1.0
Regions	eu-central-1 (more will follow)
Default endpoint	https://api.cloud.skippr.io
CDKTF TypeScript package	@skippr/provider-cloud 0.1.0
CDKTF Python package	skippr-cdktf 0.1.0; import skippr_cdktf
CLI	skippr
SDKs	crates.io skippr-cloud; npm @skippr/cloud; PyPI skippr-cloud
Resource count	29
Managed-resource verification	inventory

Choose a workflow

Choose	When
Terraform	Your infrastructure source is HCL and Terraform owns plan and state.
CDKTF TypeScript	Your infrastructure source is TypeScript; CDKTF synthesizes Terraform JSON.
CDKTF Python	Your infrastructure source is Python; CDKTF synthesizes Terraform JSON.
Direct Cloud API, CLI, or SDK	You are performing data-plane work or need explicit application-controlled resource calls. Use the CLI and SDKs for Cloud commands without Terraform.

CDKTF does not add a separate deployment engine. Terraform still performs plan, refresh, apply, import, and state management.

Before you start

You need:

1. Terraform, or CDKTF with the matching language package.
2. Preview access to Skippr Cloud.
3. An access key for Terraform. Sign in with skippr login, then create an operator key. See Keys for Terraform and CI. Set CLOUD_ACCESS_KEY_ID and CLOUD_SECRET_ACCESS_KEY (or the operator-prefixed pair). CLOUD_BEARER_TOKEN also works for a signed-in session.
4. Permission to manage the resources you declare.

The current region is eu-central-1; more will follow. Access keys and secret keys must be supplied as a pair.

Create the same table

Each example creates cloud_table named sessions with partition key PK and sort key SK. Service guides use the same four tabs for every provisionable resource.

CLI

skippr tables create-table --table-name sessions --input - <<JSON
{
  "attributeDefinitions": [
    { "attributeName": "PK", "attributeType": "S" },
    { "attributeName": "SK", "attributeType": "S" }
  ],
  "keySchema": [
    { "attributeName": "PK", "keyType": "HASH" },
    { "attributeName": "SK", "keyType": "RANGE" }
  ]
}
JSON

Terraform

terraform {
  required_providers {
    cloud = {
      source  = "skippr/cloud"
      version = "0.1.0"
    }
  }
}

provider "cloud" {
  region = "eu-central-1"
}

resource "cloud_table" "sessions" {
  table_name = "sessions"
  hash_key   = "PK"
  range_key  = "SK"
}

CDKTF TypeScript

import { App, TerraformStack } from "cdktf";
import { Construct } from "constructs";
import { CloudProvider, CloudTable } from "@skippr/provider-cloud";

class CloudStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    const provider = new CloudProvider(this, "cloud", {
      region: "eu-central-1",
    });
    new CloudTable(this, "sessions", {
      tableName: "sessions",
      hashKey: "PK",
      rangeKey: "SK",
      provider,
    });
  }
}

const app = new App();
new CloudStack(app, "cloud");
app.synth();

CDKTF Python

from cdktf import App, TerraformStack
from constructs import Construct
from skippr_cdktf import CloudProvider, CloudTable


class CloudStack(TerraformStack):
    def __init__(self, scope: Construct, id: str) -> None:
        super().__init__(scope, id)
        provider = CloudProvider(self, "cloud", region="eu-central-1")
        CloudTable(
            self,
            "sessions",
            table_name="sessions",
            hash_key="PK",
            range_key="SK",
            provider=provider,
        )


app = App()
CloudStack(app, "cloud")
app.synth()

Run your normal terraform init, terraform plan, and terraform apply workflow after synthesizing CDKTF.

Manage supported resources

Task	Terraform resources
Data and secrets	cloud_table, cloud_object_bucket, cloud_secret
Work and scheduling	cloud_queue, cloud_event_bus, cloud_event_rule, cloud_event_target, cloud_schedule
Compute	cloud_function
APIs	cloud_api, cloud_api_integration, cloud_api_authorizer, cloud_api_route, cloud_api_domain_name
Domains and certificates	cloud_dns_zone, cloud_dns_record, cloud_certificate
Web delivery	cloud_site, cloud_site_domain_binding
Observability and ELT	cloud_log_group, cloud_metric_alarm, cloud_trace_group, cloud_pipeline
Deploy Runner	cloud_deploy_runner_github_installation, cloud_deploy_runner_repository_binding, cloud_deploy_runner_pool, cloud_deploy_runner_pool_variable, cloud_deploy_runner_pool_secret_ref

Infrastructure resources lists required inputs, computed outputs, import identities, service actions, and update strategies for every resource type.

Understand lifecycle and inventory

Terraform owns desired configuration, dependency ordering, plan, state, refresh, import, and apply decisions. The provider calls the matching Cloud create, read, update-or-replace, delete, and list operations.

The provider also manages inventory records:

1. Create or import registers the resource.
2. Read describes the service resource and verifies its inventory record.
3. Update refreshes the record after a successful mutation.
4. Delete deregisters the record.

inventory_revision is computed provider state. It is not an input to the underlying Cloud resource. Inventory reports missing or changed resources; Terraform decides whether a later plan should correct them.

Know the boundary

Providers manage provisionable control-plane resources. Use Cloud APIs or SDKs for item reads and writes, queue message delivery, object bytes, function invocation, and other data-plane operations.

Sites Deployments are release history, not Terraform resources. Terraform can manage the stable cloud_site and cloud_site_domain_binding resources while your release workflow creates and promotes immutable Deployments through the Sites API.

Limits, errors, and contracts

• Resource attributes and replacement rules come from Infrastructure resources; do not assume every attribute updates in place.
• Provider authentication fails when an access key is missing its paired secret or when the credential is not valid for the Cloud control plane.
• Service validation, conflict, not-found, and authorization failures are returned through the shared Cloud error contract.
• Endpoint overrides use the provider endpoints map. Normal customer deployments use the published Cloud endpoints.

Related

• Infrastructure resources
• API action reference
• Deployment model
• Inventory
• Cloud User Directory