cloud-image-bake

Bake, select, prove, and retire Cloud Worker images across providers.

388k|81.5k|Updated Nov 24, 2025
One-click install
npx skills add https://github.com/steipete/clawdis --skill cloud-image-bake
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cloud-image-bake
Source: https://github.com/steipete/clawdis/tree/main/custodian-skills/cloud-image-bake
Command: npx skills add https://github.com/steipete/clawdis --skill cloud-image-bake

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Managing Cloud Worker images across multiple providers (AWS, Hetzner, Firecracker) is error-prone, with risks of leaking secrets, breaking config, or losing track of superseded snapshots. This Skill enforces a disciplined gather-mutate-repair-prove-report workflow so image bakes are reproducible and safe.

Core Features & Use Cases

  • Multi-provider image baking: Lease workers via crabbox, install tooling, and snapshot through AWS native, Hetzner hcloud, or Firecracker rootfs pipelines.
  • Validated config updates: Point profiles at new images only through openclaw config schema-checked writes, never hand-edited files.
  • Proof-driven promotion: Verify baked tooling with timed warmups and end-to-end session dispatch before retiring the previous image.
  • Use Case: Rolling out a new Node.js runtime on AWS Cloud Workers by leasing, installing, snapshotting, promoting, and dispatching a test session before deleting the old AMI.

Quick Start

Use the cloud-image-bake skill to bake a new AWS Cloud Worker image with the latest Node.js runtime, prove it via a timed warmup, and report the rollback state.

Frequently Asked Questions about cloud-image-bake

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I bake a new Cloud Worker image with updated tooling?

Lease a worker via crabbox warmup, run install commands with crabbox run, then snapshot per backend (AWS native, hcloud image create, or Firecracker rootfs rebuild). Point the profile at the new image through `openclaw config set` after schema validation.

What is the difference between AWS, Hetzner, and Firecracker image baking?

AWS uses crabbox checkpoint create with native mode and crabbox image promote for selection. Hetzner uses hcloud image create from a server snapshot with no crabbox lifecycle yet. Firecracker rebuilds the rootfs template through the host pipeline rather than snapshotting a running microVM.

Can I hand-edit the cloudWorkers config file to change the image?

No. Profile changes must go through `openclaw config` with schema validation and dry-run checks. Hand-editing config files on disk is explicitly disallowed because it bypasses validation and can corrupt the profile.

Why does image promotion fail after a successful snapshot?

Promotion fails when the profile lacks a matching image settings key, the schema does not recognize the field, or the warmup proof did not complete. Run `openclaw doctor --non-interactive` and re-check `openclaw config schema` for the correct key path.

When should I delete the previous Cloud Worker image?

Delete the superseded snapshot only after the new image passes the Prove step (timed warmup and end-to-end session dispatch) and you receive hard operator confirmation. Without confirmation, leave the old image intact and report cleanup as pending.