Skippr Cloud deployment model

Choose one owner for desired infrastructure state. Use the skippr-cloud CLI for day-to-day Cloud commands, Terraform or CDKTF for declarative infrastructure, Functions for executable packages, and Sites for immutable web releases.

Status: Preview. Use the CLI, Terraform, or CDKTF for the same Cloud resources. Sites can publish a website and bind a custom domain after DNS validation.

Boundaries first

Boundary	Owner	What it does
Authentication	Cloud User Directory and policies	Identifies the caller and applies policies.
Provisionable control plane	Direct API or Terraform	Creates and manages resources such as tables, queues, functions, Apis, Sites, and domains.
Desired state and plan	Terraform	Evaluates configuration, stores state, plans changes, imports, and applies.
Managed-resource verification	inventory	Records and verifies provider-managed resources; never plans or repairs them.
Data plane	Cloud API or SDK	Reads items, sends messages, transfers object bytes, and invokes functions.
Function release	functions	Registers a package and configuration as a function revision.
Web release	sites	Stores immutable Deployments and promotes one as the active Site release.

At a glance

Surface	Deployment unit	State owner	Result
CLI	Cloud command	Calling client	Service control-plane state
Native Cloud API	Service resource or operation	Calling client	Service control-plane state
Terraform	cloud_* resource	Terraform configuration and state	Planned and applied Cloud resources
CDKTF TypeScript or Python	Generated construct	Terraform configuration and state	Terraform plan/apply result
Functions	Function package and configuration	Functions API	Registered function revision
Sites	Immutable Deployment	Sites API	Preview static or SSR release, with origin routes, ISR, and cache controls

CDKTF does not introduce a second Cloud deployment engine. It synthesizes Terraform configuration.

Choose your path

Use the CLI

Choose the CLI for interactive Cloud commands and scripts. Install skippr-cloud, run skippr-cloud login, then skippr-cloud <service> <operation>. See CLI and SDKs.

Use direct Cloud APIs or SDKs

Choose direct APIs when your application explicitly controls resource calls or when you are performing data-plane work. A resource's generated contract lists its create, read, update, delete, and list operations.

Your client owns call ordering, retries, and any desired-state record outside the service. Use clientToken, revision, conditional, and pagination fields only where the operation schema defines them.

Use Terraform

Choose Terraform when you want declarative cloud_* resources, plans, state, refresh, and import. The provider is skippr/cloud version 0.1.0.

The provider calls the same native Cloud resource operations as a direct client. It also registers and verifies managed resources with inventory. Terraform remains the owner of the plan and any corrective action.

See Terraform and CDKTF for credential prerequisites, a copyable cloud_table example, the resource identifiers, and lifecycle details.

Use CDKTF TypeScript or Python

Choose CDKTF when you want to define the same Terraform resources in TypeScript or Python:

Language	Package	Provider class
TypeScript	@skippr/provider-cloud 0.1.0	CloudProvider
Python	skippr-cdktf 0.1.0; import skippr_cdktf	CloudProvider

CDKTF synthesizes Terraform JSON. Terraform then plans and applies it, so the ownership and inventory boundaries are identical to HCL.

Deploy application code

Deploy a function

1. Put a Zip artifact in objects, or choose an OCI image reference.
2. Run skippr-cloud functions register-function with package and runtime configuration.
3. Use skippr-cloud functions update-function-code or update-function-configuration for later changes.
4. Run skippr-cloud functions invoke or invoke-async, or connect the function to gateway, events, or queue.
5. Use skippr-cloud functions get-function and list-functions to inspect state.

Zip and image package types are distinct contract values. A Zip package uses an object location and digest. An image package uses an OCI image reference and optional digest. Authorize the function's workload principal through Cloud User Directory policies.

Deploy a Site

Terraform can manage the stable cloud_site and cloud_site_domain_binding resources. Your release workflow manages immutable Sites Deployments:

1. Build the static application in your own build workflow.
2. Call CreateDeployment and upload the requested content.
3. Call CompleteDeployment to validate and publish the immutable release.
4. Test the Deployment preview hostname.
5. Call PromoteDeployment to make it the active Site release.
6. Promote an earlier ready Deployment to roll back.

You can publish a site, promote or roll back a deployment, purge cache, and revalidate paths or tags. Bind a custom domain after DNS validation.

Keep control and data operations separate

Client → HTTPS gateway edge → authentication → policies → Cloud service

Terraform and CDKTF manage only resources listed in the Infrastructure resources. Data-plane operations remain API or SDK calls. Terraform can create cloud_table, but your application uses skippr-cloud tables put-item / skippr-cloud tables get-item.

Limits, errors, and contracts

• Check the API action reference before adding a deployment step. Skip anything listed as coming soon.
• Use Infrastructure resources for required attributes, import identities, and update-or-replace behavior.
• Use each service guide for package, payload, resource, and concurrency limits. There is no shared deployment limit to infer across services.
• Cloud API failures use the shared error contract. Terraform and CDKTF surface those service failures during plan, refresh, or apply as appropriate.

Related

• CLI and SDKs
• API reference
• API action reference
• Infrastructure resources
• Providers
• Functions
• Sites
• Inventory