Sync & state bucket

Every placemy scan writes its output to two places:

1. The local --output file you asked for (HTML, JSON, or both).
2. The state bucket you registered with placemy bootstrap.

The second one is what makes multi-machine workflows possible. When a teammate runs placemy scan against the same cloud account from their own laptop, placemy reads the last scan out of the bucket first, so their "Optimise" pass has the diff context without either of you doing any coordination.

Discovery order

When placemy needs to find its state bucket, it looks in this order and stops at the first match:

1. The --state-uri flag on the command
2. The PLACEMY_STATE_URI environment variable
3. The [bucket] section of ~/.placemy/config.toml
4. The SSM parameter /placemy/state-bucket (AWS only)

This order is why placemy bootstrap --provider aws "just works" on a fresh machine: the SSM parameter is the tier-1 discovery mechanism for AWS, so no local config is needed.

Permissions

The credentials placemy runs with need:

• AWS: s3:GetObject, s3:PutObject, s3:ListBucket on the state bucket, and ssm:GetParameter on /placemy/state-bucket.
• Azure: Read/write on the container.
• GCS: storage.objects.get, storage.objects.create, storage.objects.list.

What about secrets?

The state bucket never contains credentials. The contents are entirely derived from what placemy sees via your cloud APIs — resource inventories, metric summaries, and rule outputs. Treat it like a report archive, not like a vault.

Rotating the state bucket

Delete the SSM parameter (or the [bucket] section of the config file), re-run placemy bootstrap. Old scan history stays in the old bucket until you delete it yourself — placemy never deletes anything without being asked.