schema

Show what Kyku knows about a resource type’s customConfig on a given provider: which keys are lifecycle-aware (safely updatable in place) vs. create-only, which keys are reserved (owned by a first-class field), and where to find the typed alias for IDE autocomplete.

This reads the same CustomConfigSchema metadata the planner uses to decide update vs. replace — it doesn’t call any cloud API and needs no credentials beyond what the provider’s constructor requires.

Usage

kyku schema <resourceType> --provider <provider> [options]

Options

Flag	Default	Description
-p, --provider <provider>	—	Cloud provider (aws, gcp, hetzner, digitalocean, kubernetes) — required
--json	false	Output as JSON instead of a formatted summary

Examples

kyku schema Vpc --provider aws

customConfig schema: Vpc on aws

Typed alias (if exported): AwsVpcCustomConfig — import from @kykucloud/aws

Lifecycle-aware keys:
  InstanceTenancy: string, lifecycle=create
    read behavior: reflects live cloud state
  EnableDnsHostnames: boolean, lifecycle=both
    read behavior: reflects live cloud state
  EnableDnsSupport: boolean, lifecycle=both
    read behavior: reflects live cloud state
  EnableNetworkAddressUsageMetrics: boolean, lifecycle=both
    read behavior: reflects live cloud state
  subnet: object, lifecycle=create
    read behavior: reflects live cloud state
  natGateway: object, lifecycle=create
    read behavior: reflects live cloud state
  routeTable: object, lifecycle=create
    read behavior: reflects live cloud state
  internetGateway: object, lifecycle=create
    read behavior: reflects live cloud state

Any other key defaults to lifecycle="create": a change plans a replace (destroy + recreate).
Unknown keys are never rejected outright — they pass through with a plan-time warning.

Every lifecycle-aware key also prints a read behavior line. Most reflect live cloud state, but a field the cloud’s read response never returns at all (write-only) instead echoes back whatever you set — the diff engine can’t otherwise tell an applied write-only change from a pending one:

kyku schema Vm --provider hetzner

customConfig schema: Vm on hetzner

Typed alias (if exported): HetznerVmCustomConfig — import from @kykucloud/hetzner

Lifecycle-aware keys:
  automount: boolean, lifecycle=create
    read behavior: echoes desired value (write-only — the cloud never returns this field, so drift can't be confirmed by reading)
  placement_group: number, lifecycle=both
    read behavior: reflects live cloud state
  volumes: array, lifecycle=create
    read behavior: reflects live cloud state
  backups: boolean, lifecycle=both
    read behavior: reflects live cloud state
  protection: object, lifecycle=both
    read behavior: reflects live cloud state
  dns_ptr: string, lifecycle=both
    read behavior: reflects live cloud state

Any other key defaults to lifecycle="create": a change plans a replace (destroy + recreate).
Unknown keys are never rejected outright — they pass through with a plan-time warning.

kyku schema Vm --provider aws --json

{
  "provider": "aws",
  "resource": "Vm",
  "schema": {
    "keys": {
      "DisableApiTermination": { "type": "boolean", "lifecycle": "both" },
      "DisableApiStop": { "type": "boolean", "lifecycle": "both" },
      "InstanceInitiatedShutdownBehavior": { "type": "string", "lifecycle": "both" },
      "SourceDestCheck": { "type": "boolean", "lifecycle": "both" },
      "Monitoring": { "type": "object", "lifecycle": "both" },
      "MetadataOptions": { "type": "object", "lifecycle": "both" }
    }
  }
}

Notes

• A resource type with no registered schema entries still accepts customConfig — it’s an untyped passthrough, not an unsupported feature. The command says so explicitly rather than erroring.
• reserved keys shown here (if any) are a hard plan-time error to set, since they collide with a first-class field Kyku already manages — see Custom Config for how collisions and unknown keys are handled.
• The default lifecycle Kubernetes reports is both, not create — every typed Kubernetes resource applies via server-side apply, which is always safe to re-run in place, so customConfig changes there plan an update rather than a replace by default.