Cloud Resource Tags
Fractal Cloud uses a small, well-defined set of tags applied directly to the cloud resources it manages. These tags are the source of truth for everything an agent does — they govern whether a resource is reconciled, who owns its lifecycle, and when an emergency override is in effect. There are no state files; the tags on the resource and the LiveSystem declaration are everything.
This page lists every tag Fractal Cloud reads or writes, what each one means, who sets it, and the rules around modifying it.
Tags at a glance
| Tag key | Value | Set by | Removed by | Purpose |
|---|---|---|---|---|
managed-by | fractal-cloud | Agent on resource creation; user/Force Push for adoption | User (manually or via console) | Declares that the resource is under Fractal Cloud's reconciliation lifecycle |
fractal-cloud | reconcile | User or Force Push | Agent automatically once reconciliation completes | Re-adoption signal — combined with managed-by, instructs the agent to reconcile a previously-overridden resource back to the declaration |
fractal-cloud-owner | <live-system-id> | Agent on resource creation; user pre-stamp for ownership transfer | Agent only when the owning LiveSystem deletes the resource | Identifies the single LiveSystem that owns the resource. Only this LiveSystem may mutate or delete it. |
How the tags interact
The three tags work together to express four different management states for any given cloud resource:
| Tags present | Resource state | Agent behaviour |
|---|---|---|
managed-by + fractal-cloud-owner: <my-ls> | Managed (owner) | Normal reconciliation against the LiveSystem declaration |
managed-by + fractal-cloud-owner: <other-ls> | Externally Managed (importer) | Read output fields only — the resource is owned by another LiveSystem |
| Tags absent | Manual Override | Hands off — engineer is making manual changes, or the resource pre-existed |
managed-by + fractal-cloud: reconcile | Reconcile Requested | Agent reconciles to declaration, then removes reconcile tag |
For more on the state transitions, see Break-the-Glass, Importing Existing Resources, and Sharing Components Across LiveSystems.
Tag rules
These rules are enforced by every Fractal Cloud agent. They are non-negotiable safety guarantees.
managed-by
- The agent never restores a removed
managed-bytag. Removal is interpreted as an explicit operator decision to take manual control. Once gone, only an operator (or Force Push triggered by an operator) can put it back. - Identity is not the tag. Agents correlate resources by their existing per-offer identifiers (component ID, naming convention, ARN, resource path). The
managed-bytag is a management flag, not a lookup key. An agent will never create a duplicate resource because the tag is missing.
fractal-cloud: reconcile
- Meaningless without
managed-by. An agent that seesfractal-cloud: reconcileon a resource with nomanaged-bytag ignores it entirely. The two-tag handshake exists specifically to prevent accidental re-adoption. - The agent removes this tag itself once reconciliation completes. Operators do not need to clean up after re-adoption.
fractal-cloud-owner
- Set once, never overwritten. An agent that sees an existing
fractal-cloud-ownertag respects the value. Ownership cannot accidentally transfer between LiveSystems. - Only the owner can mutate or delete the resource. Every other LiveSystem that references the same resource sees it as Externally Managed and reads output fields only.
- Pre-stamping is supported. An operator may apply
fractal-cloud-owner: <ls-id>to a resource before any LiveSystem has reconciled it, in order to assign ownership to a specific LiveSystem in advance. The first agent reconciling a matching component will respect the tag.
Tag application by cloud provider
Tags map to the native tagging or labelling primitive of each provider.
| Provider | Primitive |
|---|---|
| AWS | Resource tags (EC2, RDS, S3, etc. — each service has its own API) |
| Azure | Resource tags |
| GCP | Resource labels (note: GCP labels disallow uppercase and most punctuation; agents normalise tag values accordingly) |
| OCI | Free-form tags |
| Hetzner | Labels |
| VMware vSphere | vSphere Tags (under the fractal-cloud tag category) |
For resource types that do not support tagging at all, agents apply the Externally Managed behaviour by default — the resource cannot carry an ownership stamp, so it is treated as read-only. This is the safe fallback.
Frequently asked questions
Q: Can I add my own tags to a Fractal Cloud-managed resource? A: Yes. Fractal Cloud only reads and writes the three tags listed above. Any other tags you add are preserved across reconciliations.
Q: Will the agent remove tags I added when it reconciles drift?
A: No. The agent only removes tags it set, and only when the situation calls for it (e.g. removing fractal-cloud: reconcile after re-adoption, or all Fractal Cloud tags on resource deletion).
Q: What happens if I change the value of fractal-cloud-owner?
A: Don't. Ownership transfer is not supported in the current protocol. If you need to move ownership between LiveSystems, contact support — manually editing the tag will result in undefined behaviour.
Q: Why two tags instead of one for break-the-glass re-adoption?
A: The two-tag handshake prevents accidental re-adoption. If an engineer re-adds managed-by by reflex during cleanup without intending to trigger reconciliation, nothing happens — the agent waits for the explicit fractal-cloud: reconcile tag before acting.