Change an existing Cycle container: its runtime config (start command/args, environment variables, ports, hostname, public network mode, CPU/RAM, automated backups, shared file systems), its instance count, its image, its volumes (extend, read-only), or its metadata (name, identifier, annotations, lock, deprecate). Adding or removing volumes is a redeploy, not a reconfigure. The virtual-machine equivalent is reconfigure_virtual_machine.

Each group reaches Cycle through a different mechanism and differs in disruption; every change in the preview diff is tagged with an 'impact':

• 'restart' — runtime config. Cycle's reconfigure REPLACES the container's entire config, so this tool fetches the current config, applies only the fields you pass, and submits the whole result; everything you don't pass keeps its value (including deployment constraints, integrations, and devices). Applying RESTARTS every instance; there is no way to change runtime config without a restart. volumes.max_size and volumes.read_only rewrite the volume set through Cycle's volumes.reconfigure task, which also restarts every instance. 'backups' (stateful containers only) merges the passed fields over the current backups integration — destination, command, schedule and restore_command must all be present once merged; backups:{disable:true} removes it. 'shared_file_systems' is the complete replacement set of mounts (keyed by the identifier a server exposes, see list_servers); preview checks that the servers the instances run on expose each identifier and says when to offer configure_server instead.

• 'scale' — instance count. Instances cannot be changed by reconfiguring; the tool submits Cycle's scale task, which does not rewrite the config. More than 1 instance on a stateful container is allowed but NOT recommended (the tool applies it with a warning note) — prefer separate single-instance containers.

• 'reimage' — moves the container onto a different image built from the image source it ALREADY uses, keeping its runtime config; instances restart on it. reimage:true imports a fresh image to pick up the latest. image_id reimages onto any live image from that same source, including an older one — that is how you ROLL BACK a bad image: preview with reimage:true, and the response's 'image_options' lists the source's live images newest first with build times and marks the running one; pass the chosen id as image_id (it takes precedence over reimage:true, so nothing is imported). A rollback keeps the CURRENT runtime config, so check the args, env and volume paths still suit the older image and reconfigure them in the same call if not. Switching image sources is a redeploy, not a reimage, and is refused. Stack-deployed containers are refused too — reimage them by building and redeploying the stack. If an import outlives the wait, the response carries the new image_id; call again with it to finish without importing a second copy.

• 'volume' — volumes.extend grows a local volume's allocation in place with an instance task, no restart; sizes only increase and are capped by the volume's max_size. Passing volumes at all returns the current volumes, each with its max_size and per-instance used/allocated, so a preview with an empty volumes object is a read.

• 'none' — metadata. Applies immediately: no job, no restart, instances untouched.

Always call with preview:true first — it fetches the current state and returns a field-by-field from/to diff with each change's impact, making NO changes. The diff is computed by this tool, not validated by Cycle; use it to confirm the change matches the user's intent. Get explicit confirmation, then call again without preview.

Changes from several groups are applied in order — metadata, runtime config, volumes, image, instances — and each step is reported in 'steps'. The run stops at the first failed step, so a partial result is possible; read 'steps' rather than assuming all-or-nothing.