Share Components Across LiveSystems

Some infrastructure is naturally shared across many workloads — a corporate network, a multi-tenant Kubernetes cluster, a database that backs several services. In Fractal Cloud, multiple LiveSystems can reference the same physical resource, but only one of them owns its lifecycle. Every other LiveSystem treats it as read-only.

This protects against the most common failure mode of shared infrastructure: deleting one LiveSystem accidentally taking down resources that other LiveSystems depend on.

How ownership works

When an agent creates a new cloud resource, it stamps two tags on it:

• managed-by: fractal-cloud — the resource is under agent control
• fractal-cloud-owner: <live-system-id> — this LiveSystem owns the resource

The owner is whoever creates the resource first. Once the owner tag is set, no agent will ever change it. If a second LiveSystem references the same resource — same natural identity (name + scope) — the agent reconciling for that second LiveSystem reads the owner tag, recognises that it does not match the LiveSystem currently being reconciled, and treats the component as Externally Managed.

                                              ┌───────────────────────┐
                                              │  Cloud resource       │
                                              │  shared-vpc           │
                                              │  managed-by:          │
                                              │    fractal-cloud      │
                                              │  fractal-cloud-owner: │
                                              │    ls-platform        │
                                              └─────────┬─────────────┘
                                                        │
                       ┌────────────────────────────────┼────────────────────────────────┐
                       │                                │                                │
                       v                                v                                v
        ┌──────────────────────────┐    ┌──────────────────────────┐    ┌──────────────────────────┐
        │ LiveSystem ls-platform    │    │ LiveSystem ls-team-a     │    │ LiveSystem ls-team-b     │
        │                           │    │                          │    │                          │
        │  Owns the resource        │    │  References the resource │    │  References the resource │
        │  Status: Active           │    │  Status: ExternallyManaged│   │  Status: ExternallyManaged│
        │  Reconciles drift         │    │  Reads output fields only │   │  Reads output fields only │
        │  Can mutate / delete it   │    │  Cannot mutate / delete   │    │  Cannot mutate / delete  │
        └──────────────────────────┘    └──────────────────────────┘    └──────────────────────────┘

When to use this

• A corporate VPC consumed by every team's LiveSystem
• A shared Kubernetes cluster onto which several LiveSystems deploy workloads
• A central database referenced by multiple application LiveSystems
• A logging or monitoring stack used by everyone

Setting up a shared component

There is no special syntax. Each LiveSystem declares the component as it normally would, using the natural identifier of the shared resource.

The first LiveSystem to deploy:

// LiveSystem ls-platform
const sharedVpc = network.aws.vpc({
  id: 'shared-vpc',
  name: 'shared-vpc',
  region: 'eu-west-1',
  cidrBlock: '10.0.0.0/16',
});

When deployed, the agent finds no existing resource, creates one, and stamps fractal-cloud-owner: ls-platform. The component appears as Active in the ls-platform dashboard.

A second LiveSystem then references the same VPC:

// LiveSystem ls-team-a
const sharedVpc = network.aws.vpc({
  id: 'shared-vpc',
  name: 'shared-vpc',          // same name as in ls-platform
  region: 'eu-west-1',          // same region
  cidrBlock: '10.0.0.0/16',     // must match — drift would otherwise be reported
});

const subnet = network.aws.subnet({
  id: 'team-a-subnet',
  vpc: sharedVpc,
  cidrBlock: '10.0.10.0/24',
});

When ls-team-a deploys, its agent finds the existing VPC, sees fractal-cloud-owner: ls-platform, and assigns the VPC component the ExternallyManaged status. The agent still reads the VPC's output fields (vpcId, cidrBlock, etc.) so the team-a subnet — which ls-team-a does own — can be created inside the shared VPC.

What each LiveSystem can do

Action	Owner LiveSystem	Importing LiveSystem
Read output fields (resource IDs, endpoints, etc.)	Yes	Yes — re-read on every poll
Modify resource configuration	Yes	No — never
Delete the resource	Yes	No — only drops the local reference
Receive drift alerts when reality differs from declaration	Yes	No — drift on someone else's resource is not actionable
Apply tags to the resource	Yes	No

Output field freshness

Importers re-read the shared resource on every reconciliation cycle. This is essential — dependent components inside the importing LiveSystem (the team-a subnet above) consume those output fields, and stale values would propagate stale configuration. There is no caching shortcut for ExternallyManaged components.

Deleting an owner LiveSystem

When the owning LiveSystem is deleted, the agent deletes the shared resource as it would any other component it owns. Importing LiveSystems detect Missing on their next poll and surface it through the normal drift channels.

The control plane warns you at delete-time:

This LiveSystem owns 3 resources that are imported by 2 other LiveSystems. Deleting will cause those LiveSystems to report Missing on those references.

The warning is advisory. If you proceed, the deletion succeeds.

caution

Ownership transfer is not supported in the current protocol. If the owner LiveSystem must be retired but the resource needs to keep living, the recommended path is to manually transfer ownership: the operator updates the fractal-cloud-owner tag on the resource to the new owner LiveSystem's ID before deleting the old one. The new owner's agent will see itself as the owner on its next reconcile.

Pre-stamping ownership

You can assign ownership to a specific LiveSystem before any agent has reconciled the resource by setting fractal-cloud-owner: <ls-id> directly on the resource in the cloud console or CLI. The first agent that reconciles a matching component for that LiveSystem will see itself as the owner; agents for other LiveSystems will see ExternallyManaged.

This is useful for:

• Migrating an existing shared resource into Fractal Cloud and assigning a specific LiveSystem as its long-term owner
• Establishing intended ownership before any LiveSystem races to claim it

FAQ

Q: Two LiveSystems deploy at exactly the same time. Which one becomes the owner? A: The one whose agent successfully creates the resource first. The other agent, on its next poll, finds the resource already tagged and adopts ExternallyManaged. There is no race-loss state to clean up.

Q: Can the owner change later? A: Not via the protocol. The fractal-cloud-owner tag is set once and never overwritten by an agent. To transfer ownership manually, an operator updates the tag on the cloud resource directly.

Q: My LiveSystem references a shared resource, but its cidrBlock is wrong in my declaration. What happens? A: As an importer, you can't reconcile drift — the agent reads the actual cloud state and reports drift in your output fields, but does nothing about it. Update your declaration to match the actual resource.

Q: Can I share a component that doesn't exist yet? A: Yes. The first LiveSystem to deploy creates it and becomes the owner. All subsequent LiveSystems that reference the same natural identity find the existing resource and become importers.

Q: What if I want full read/write access from multiple LiveSystems? A: That isn't supported, by design. Multi-writer reconciliation is incompatible with deterministic drift correction — two LiveSystems with different declarations would fight over the resource forever. Pick an owner.