The canvas model

On the canvas, a connection is not decoration. It is a relationship, and your topology is derived from the edges you draw.

Nodes are resources, edges are relationships

Every node is a resource: a compute node is a server, a private network is a real network, a floating IP is a real public IP. Every edge between two nodes is a typed relationship between those two resources.

A compute node does not have a field that says which network it is in. Instead, an edge from a private network node to a compute node means the compute node is in that network. The edge is the membership.

Edge-derived membership

CrossXCloud derives your topology purely from the edge set. There is no stored subnetId field on a compute node. When something needs to know which networks a compute node is in, it walks the edges that connect to it.

This keeps relationships as relationships and attributes as attributes. Adding a server to a second network is just drawing a second edge, not editing a comma-separated list. Removing it is deleting the edge.

The edge kinds

The real canvas has three edge kinds:

• Membership (private network to compute). The compute node is in this network. A compute node can be in more than one network, subject to the provider’s rules.
• Membership (floating IP to compute). This floating IP is assigned to this compute. A floating IP can be assigned to at most one compute at a time. A compute can have many floating IPs.
• Companion (compute to primary IP). The public IP belongs to this compute. This edge is auto-managed and cannot be drawn or deleted manually.

graph LR
    net[Private Network] -->|membership| comp[Compute Node]
    fip[Floating IP] -->|membership| comp
    comp -->|companion| pip[Primary IP]

Why edges, not fields

Modeling membership as a typed field conflates a relationship with an attribute. If you want to know what is in a network, you should be able to read that off the graph directly. If you want to change it, you should edit the graph, not a property on a node.

Edges also make validation clean. The rules for what can connect to what are owned by the backend and consulted as you draw, so the canvas enforces provider rules (such as a floating IP being assignable to only one compute) without you having to remember them.

What this is not

The canvas also renders a set of showreel and mock nodes behind a demo flag, including a “tunnel” edge that visually crosses compute nodes across providers. Those are demo visuals, not features. The real edges above are the only ones that produce operations on Apply.

Next

• Reconciliation for how the canvas becomes a plan.
• The canvas for the everyday mechanics.
• Networking for the networking-specific edges in detail.