Resource model
Ownership, placement, desired state, and observed state in Infra.
Infra organizes infrastructure by ownership and physical placement. Organizations own projects and fleet resources; projects own application resources.
Ownership and scope
An organization owns membership, projects, fleet policy, and billing. A project owns application resources such as droplets, networks, volumes, and backup policies. The project is the normal permission boundary for deploying an application.
Physical placement is independent of that ownership tree. A region groups compatible compute, storage, and network infrastructure. Its zones represent failure domains. A node belongs to a zone and contributes compute, storage, or both to the region.
A droplet has a project owner, a regional placement requirement, and an observed execution node. A volume has its own project owner and storage policy; its attachment records which droplet can write it. Those IDs stay separate so detaching a disk does not imply deleting its data.
An operation records an accepted change across those resources. Its scope can include several projects for an approved fleet action, but each reader still needs permission to see the corresponding targets.
A project does not own its nodes. Scheduling grants its droplets access to a node pool according to organization policy. Removing a project does not remove shared nodes or release capacity owned by another project.
Resource identity
Every resource has an immutable ID, a mutable display name, labels, and a creation time. Names help operators find resources; IDs identify targets in API calls and audit events. Renaming a droplet does not change its ID, addresses, or volume attachments. Names cannot be used as substitutes for IDs in reference fields.
Labels are string pairs used for filtering, ownership, and policy selection. Changing a label can change which backup or automation policy selects a resource. Review the matching resources before saving a policy selector. Label changes do not move running droplets; placement changes require a migration or restart.
Desired and observed state
The control plane stores desired configuration. Agents report observed state from nodes, hypervisors, storage, and networking. The console shows both when execution is incomplete or a component cannot be reached.
For example, resizing a stopped droplet updates its requested memory and starts an operation. Until the agent applies the new configuration, the observed size can still show the previous value. An accepted request is not evidence that the new configuration is active.
Resources expose a configuration revision. The API uses revisions to reject stale writes. A revision changes when configuration changes; metrics and journal entries do not increment it.
Region boundaries
Droplets, volumes, private networks, and load balancers belong to one region. A live migration moves a droplet between nodes in that region. A recovery workflow creates replacement resources in another region from copied backup data. Resource IDs and private addresses can change during recovery.
An organization can contain both owned and hosted regions. The Connector grants a self-hosted control plane access to hosted capacity. It does not transfer ownership of local hardware or create network routes between regions.
Removal and references
Deletion checks resource dependencies. A network with attached interfaces or a volume with an active attachment cannot be deleted. The error names the blocking resource IDs. Removing a droplet does not delete separately managed data volumes unless they are explicitly selected for deletion.
Operation history and audit records retain deleted resource IDs. A historical link can therefore identify an object that no longer has a live details page. Use its recorded name, project, and operation ID for investigation.