• •REST endpoints for balance, history, invoices (PDF/CSV), insights via team URN (do:team:uuid).
• •Usage-based with monthly invoices on 1st; prepaid credits model.
• •Invoice items include project_name; no OpenStack Ceilometer-style real-time metering API.
• •Pagination and rate-limited.

• •Application model: DigitalOcean firewalls are applied to Droplets via `droplet_ids` and/or tags, whereas OpenStack security groups are typically attached to Neutron ports (VM NICs) and can vary per port ().
• •Rule model includes both inbound and outbound rules and notes that if none are configured then no traffic is permitted in that direction; OpenStack security groups also support egress rules but many deployments default to allow-all egress—migrating users may need to explicitly model egress restrictions in DigitalOcean if they rely on different defaults ().
• •Aggregation semantics: DigitalOcean states that when multiple cloud firewalls apply to a Droplet, rules are additive (“union of the rules”) and a more permissive rule in any firewall effectively opens access; OpenStack security groups are also generally additive, but users migrating from “deny-by-default with explicit groups” patterns may be surprised by how quickly access broadens when stacking policies ().
• •Target/source object types differ: DigitalOcean allows sources/destinations to include load balancers (by UID) and uses constructs like `load_balancer_uids`, `droplet_ids`, `tags`, and CIDRs in rule JSON, whereas OpenStack security group rules typically reference CIDRs and/or remote security group IDs (not load balancer UIDs as a primitive) ().

• •Applied to Droplets via droplet_ids and/or tags; Neutron security groups attach to ports.
• •Both inbound and outbound rules; default deny all if no rules configured.
• •Free service like Neutron security groups; no implicit L4 stateful rules without explicit config.

• •Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
• •Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
• •Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
• •Rate limits: 5000/hour, 250/minute.

No specific divergences documented yet.

• •A Droplet must select a predefined “size” bundle (RAM/vCPU/disk/transfer) rather than choosing from an OpenStack flavor catalog that many clouds let you customize/extend at the project level.
• •The size object exposes explicit monthly pricing (price_monthly) and per-hour pricing (price_hourly) in the API response, whereas OpenStack clouds typically separate pricing from the Nova flavor definition.
• •DigitalOcean sizes embed transfer allowance and region availability directly in the size metadata, while OpenStack flavors generally describe compute resources and rely on separate networking/quotas/policies for bandwidth and availability.
• •DigitalOcean size classes are described in the API as categories like Basic, General Purpose, CPU-Optimized, Memory-Optimized, and Storage-Optimized rather than OpenStack’s provider-defined flavor naming/extra-specs approach.

• •DigitalOcean requires the Droplet to be powered off for a consistent snapshot (POST /v2/droplets/{id}/actions with {"type": "snapshot"}); a live snapshot option exists but is explicitly not guaranteed to be consistent. OpenStack Nova createImage is non-disruptive on running instances.
• •DO Droplet snapshots are billed per-GiB per month. Automated weekly backups are a percentage of the Droplet monthly price and retain the last 4 snapshots. See the DigitalOcean pricing page for current rates.
• •Droplet snapshot creation powers down the Droplet by default, creating downtime unless the live (inconsistent) option is used. Nova createImage is non-disruptive and does not affect server state.
• •DO snapshots can be used to create new Droplets in any region (with cross-region transfer) or restore the original Droplet. Nova images can launch new instances in the same region; cross-region requires Glance backend replication or manual download/upload.

• •API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
• •Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
• •Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
• •Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.

• •DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
• •Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
• •DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
• •DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.

• •Uses proprietary DigitalOcean API (POST /v2/kubernetes/clusters) for provisioning; Quake AI users provision Nova instances via OpenTofu and bootstrap Kubernetes manually (kubeadm, k3s).
• •No cluster templates; direct specification of node pools in create request. Quake AI uses OpenTofu modules or IaC patterns to define cluster topology.
• •Fully managed control plane at no cost (HA mode is a paid optional add-on); on Quake AI you provision the control plane through Magnum or self-managed on Nova instances and operate it yourself, including HA configuration.
• •Node pools consist of identical Droplet-based worker nodes managed solely via kubectl (no SSH access); Quake AI nodes are Nova instances with full SSH access via keypair.

• •Product shape: DigitalOcean provides regional and global managed load balancers. Quake AI workloads use a self-managed reverse proxy, CDN/WAF edge, or Kubernetes LoadBalancer Service.
• •DigitalOcean can select backend Droplets by explicit list or by tag. Self-managed Quake AI edges select backends through proxy or ingress configuration.
• •VPC connectivity behavior: the load balancer automatically connects to Droplets in its VPC network and falls back to public IP if private networking is disabled. Self-managed Quake AI edges route to backends through proxy configuration.
• •DigitalOcean documents built-in Let’s Encrypt certificate management, optional PROXY protocol v1, and regional HTTP/3 support. On Quake AI, configure these features on the selected self-managed edge.

• •DigitalOcean VPCs automatically manage an internal IP range; users cannot create, delete, or resize subnets. Neutron subnets are explicitly provisioned with user-defined CIDRs and DHCP pool configurations.
• •All Droplets in a DO VPC share a single flat address space; there is no subnet segmentation within a VPC. Neutron supports multiple subnets per network with independent CIDR blocks.
• •DO's API exposes VPCs at /v2/vpcs but has no /subnets endpoint; the subnet concept does not exist as an addressable API resource. Neutron exposes subnets at /v2.0/subnets as first-class resources.
• •IP address assignment within a DO VPC is automatic and cannot be specified at creation; Neutron allows fixed IP allocation per port at port creation time.

• •DigitalOcean has no port concept. Droplets receive a private VPC IP automatically on creation; the network interface is implicit and not separately addressable via API. Neutron ports are explicit first-class resources with UUIDs, security group associations, and independent lifecycle.
• •Allowed-address-pairs (for floating secondary IPs, VRRP high availability) are not supported in DO's VPC model. Neutron allowed-address-pairs enable virtual IP patterns used for active-standby clustering.
• •DO Firewalls attach to Droplets or tags, not to network interfaces. Neutron security groups attach to ports, enabling per-interface rules on multi-homed instances.
• •IP address assignment in DO is automatic; a fixed IP cannot be specified at interface creation. Neutron allows fixed_ips specification at port creation with subnet-specific allocation.

• •DigitalOcean has no managed router resource. The VPC NAT Gateway (GA November 2025) handles outbound internet egress for private Droplets; it is not a general-purpose router and does not support inter-VPC routing.
• •Neutron routers connect multiple networks and subnets with configurable routing tables. DO's VPC is a flat network; there is no concept of connecting multiple VPCs via a router in the data plane.
• •Neutron supports east-west routing between subnets on the same router. DO Droplets in the same VPC communicate directly over private IPs without any router provisioning.
• •NAT Gateway in DO is provisioned at the VPC level (POST /v2/vpc_nat_gateways) with no concept of router interfaces or subnet attachments. Neutron router-interface-add attaches specific subnets to a router for controlled routing.

• •DigitalOcean has no subscription model; billing is usage-based with a monthly invoice. Resources are billed from provisioning to deletion at hourly or monthly rates. No reserved or committed use discounts are available.
• •DO provides a monthly spending limit (soft cap with alert) but no hard subscription tier. Quake AI's billing model is operator-defined.
• •DigitalOcean includes a bandwidth allowance per Droplet/Load Balancer in the resource price; outbound bandwidth beyond the allowance is metered per-GiB. Inbound bandwidth is always free. Quake AI's bandwidth pricing is operator-defined.
• •DO invoices are per-account (or per-team) and generated monthly with no billing account hierarchy above the team level.

• •DigitalOcean PATs are account-scoped (access all resources across all projects for that account) with a choice of read or read/write scope. OpenStack application credentials are project-scoped and tied to a specific set of roles.
• •DO supports OAuth2 for third-party app authorization (apps request access on behalf of a user). OpenStack Keystone supports OAuth1.0 for delegated token issuance; full OAuth2 support depends on the Keystone deployment.
• •DO PATs can be set to expire (custom expiry date) or be non-expiring. Keystone token TTL is server-configured, not per-credential.
• •DO does not support service accounts independent of a user identity. OpenStack application credentials survive user password changes and can be restricted to specific API operations via access rules.

• •UI/organizational grouping of resources (Droplets, Spaces, etc.) into named projects with description/purpose/environment; default project exists.
• •API for CRUD projects/resources; resources moved between projects.
• •Purely organizational, no access control/billing isolation like OpenStack projects; resources still scoped by teams.
• •Three resource types: project-based, droplet-based, independent.

• •Naming/API surface: DigitalOcean renamed Floating IPs to Reserved IPs; endpoints and fields change from `floating_ips` to `reserved_ips` (while legacy endpoints existed until a stated deprecation window), whereas OpenStack retains the “floatingip” resource in Neutron APIs ().
• •Identity model: DigitalOcean’s resource identifier in the API path is the IP address itself (`/v2/reserved_ips/{reserved_ip}` where `{reserved_ip}` is an IPv4 address), whereas OpenStack commonly uses UUID identifiers for Neutron resources like floating IPs and ports ().
• •Attachment model: creation requires either `droplet_id` or `region` and reassignment is conceptually “map to a Droplet”; OpenStack associates floating IPs to Neutron ports (and thus can be used with more complex networking constructs like routers), which is a different mental model for migrating users ().
• •Region binding: DigitalOcean Reserved IPs are explicitly bound to a region, while OpenStack floating IP pools are usually defined per external network and can be consumed wherever that external network is reachable (implementation-specific) ().

• •Naming differs: users create a “Space” that is a bucket, and each bucket has a unique URL (virtual-hosted or path style), whereas Swift uses containers within an account namespace. ().
• •Bucket addressing uses S3-style endpoints such as `${BUCKET}.${REGION}.digitaloceanspaces.com` (and `${REGION}.digitaloceanspaces.com/${BUCKET}`), which differs from Swift’s account/container/object path conventions. (, ).
• •Access keys can be scoped to high-level permission tiers (Read, Read/Write/Delete, All) applied across buckets/objects, which differs from Swift’s typical tenant/user + container ACL model. ().

• •Spaces documents that it implements only a subset of the Amazon S3 API; migrating users may need to validate specific S3 operations/behaviors they rely on rather than assuming full parity. ().
• •Endpoint format is region-based (`${REGION}.digitaloceanspaces.com`) and uses bucket subdomains, which differs from typical OpenStack endpoint discovery (Keystone catalog) and Swift URL layouts. ().
• •Spaces supports SigV4 (recommended) and SigV2 (legacy) signing for S3 requests, whereas OpenStack Swift deployments often rely on Keystone tokens for Swift API access (and any S3 compatibility is typically provided via an additional gateway). (, ).

• •DigitalOcean charges a flat monthly base fee for a Spaces Standard Storage subscription that includes pooled storage and outbound transfer allowances across all buckets, then per‑GiB overages. Swift itself is not inherently coupled to a billing system, and pricing is operator-defined. See the DigitalOcean Spaces pricing page for current rates.
• •Outbound data transfer overage is explicitly billed per-GiB and applies to both Standard and Cold Storage; many OpenStack-based clouds may bundle or price transfer differently.
• •Cold Storage adds retrieval fees per-GiB and early deletion/update fees, which migrating users must incorporate into access patterns and lifecycle policies.

• •SSH keys are managed at the account/team level via /v2/account/keys and then referenced by ID/fingerprint when creating Droplets, whereas OpenStack Nova keypairs are typically created per project/tenant and managed via the Nova API.
• •DigitalOcean explicitly notes that including a key during Droplet creation embeds it into the root user’s authorized_keys, whereas OpenStack’s keypair injection mechanism is generally cloud-init/metadata-service driven and may vary by image/cloud config.
• •DigitalOcean tokens/scopes model for API authorization (bearer tokens with scopes like ssh_key:read) differs from OpenStack Keystone’s token + role-based policy model.
• •DigitalOcean documentation emphasizes that post-creation SSH key changes are performed inside the guest OS (not via control panel), whereas OpenStack users may rely more heavily on metadata/cloud-init or config management patterns post-boot.

• •DigitalOcean uses tags as a grouping/selection mechanism (filtering, bulk actions, auto-inclusion in firewall/LB configs) rather than OpenStack Nova server groups that implement affinity/anti-affinity placement policies.
• •No documented user-facing placement policy (affinity/anti-affinity) is exposed via tags; tags are for organization and targeting actions, unlike OpenStack server groups which influence scheduling decisions.
• •DigitalOcean’s tags API requires canonical capitalization in the URL (e.g., /v2/tags/PROD/resources), which is a platform-specific behavior not typically present in OpenStack resource tagging.
• •Bulk actions on Droplets can be initiated across resources sharing a tag via DigitalOcean API endpoints, whereas OpenStack server groups are separate resources with policies and memberships managed via Nova.

• •DigitalOcean Teams allow multiple users to share access to one billing account's resources. There is no hierarchy above the team level; Teams cannot be grouped or nested. Quake AI's Organization → Project model provides two levels of isolation.
• •DO Teams use a simple Owner/Member role model for the entire team. OpenStack Keystone roles (admin, member, reader) are project-scoped and assignable per-user per-project for fine-grained access control.
• •All resources created by DO team members belong to the team's account; there is no per-member resource scoping. OpenStack resources belong to a project and users access them through project membership roles.
• •DO Teams have no concept of sub-teams or nested groups. OpenStack supports domain-level user management with project hierarchies (nested projects) in Keystone v3.

• •Proprietary API /v2/volumes/{volume_id}/snapshots instead of OpenStack /v3/{project_id}/snapshots.
• •Explicitly crash-consistent only, no automatic filesystem consistency (requires manual power-off/sync); OpenStack snapshots can use quiescing drivers for apps like databases.
• •Snapshots billed separately based on block-level used size (may exceed filesystem due to trim); OpenStack typically similar. See the DigitalOcean pricing page for current rates.
• •Can create new volumes only in same region as snapshot; OpenStack snapshots more flexible for cross-region with upload/download.

• •Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
• •Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
• •Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
• •Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

• •Region-scoped: a VPC network is created in a specific datacenter region and resources must be in that same region to be attached, whereas OpenStack Neutron networks/subnets are generally available across all AZs in a region and attachments are controlled by network reachability rather than an explicit region slug ().
• •Resource migration is limited: Droplets require snapshot/recreate to move between VPCs and some resources (Kubernetes clusters, load balancers, NAT gateways) cannot be migrated between VPCs, whereas in OpenStack you typically can attach/detach ports or move router interfaces without recreating servers (behavior depends on deployment, but Neutron’s object model supports it) ().
• •NAT is a managed NAT Gateway with tiered capacity (1–16 increments; each increment gives 25 Mbps symmetrical bandwidth and 100 GiB outbound transfer/month) and can be set as the default gateway for the VPC, whereas OpenStack commonly expresses egress via Neutron routers with SNAT and does not use this specific ‘size tier’ model ().
• •Security-policy coupling differs: DigitalOcean notes Cloud Firewall rules affect both public and VPC traffic and rules must specify whether they apply to the public or private IP range, whereas in OpenStack security groups are generally applied to ports and are not framed as “public vs private IP range” rule modes ().

• •DO VPC NAT Gateway (POST /v2/vpc_nat_gateways) provides outbound internet egress (SNAT) for private Droplets only; it does not support inbound NAT (DNAT). Neutron supports both SNAT via router external gateway and DNAT via floating IP association.
• •DO NAT Gateway is set as the VPC default gateway; all private Droplets automatically route outbound traffic through it. Neutron requires enable_snat: true on the router gateway; per-port floating IP assignment handles DNAT separately.
• •Only one NAT Gateway can be set as the default gateway per VPC. Neutron supports multiple routers per project with independent SNAT configurations.
• •DO NAT Gateway is billed hourly as a separate resource in addition to Droplet costs. Neutron SNAT is included in the router resource with no separate charge on Quake AI.

• •VPC-native using Cilium eBPF (K8s 1.31+), Gateway API default on 1.33+; Quake AI Kubernetes clusters use CNI plugins (Flannel, Calico, Cilium) on Neutron private networks.
• •Direct pod-to-VPC resource routing and internal load balancers; Quake AI Kubernetes clusters expose services through Kubernetes LoadBalancer behavior and floating IPs.

• •REST endpoints for balance, history, invoices (PDF/CSV), insights via team URN (do:team:uuid).
• •Usage-based with monthly invoices on 1st; prepaid credits model.
• •Invoice items include project_name; no OpenStack Ceilometer-style real-time metering API.
• •Pagination and rate-limited.

• •Application model: DigitalOcean firewalls are applied to Droplets via `droplet_ids` and/or tags, whereas OpenStack security groups are typically attached to Neutron ports (VM NICs) and can vary per port ().
• •Rule model includes both inbound and outbound rules and notes that if none are configured then no traffic is permitted in that direction; OpenStack security groups also support egress rules but many deployments default to allow-all egress—migrating users may need to explicitly model egress restrictions in DigitalOcean if they rely on different defaults ().
• •Aggregation semantics: DigitalOcean states that when multiple cloud firewalls apply to a Droplet, rules are additive (“union of the rules”) and a more permissive rule in any firewall effectively opens access; OpenStack security groups are also generally additive, but users migrating from “deny-by-default with explicit groups” patterns may be surprised by how quickly access broadens when stacking policies ().
• •Target/source object types differ: DigitalOcean allows sources/destinations to include load balancers (by UID) and uses constructs like `load_balancer_uids`, `droplet_ids`, `tags`, and CIDRs in rule JSON, whereas OpenStack security group rules typically reference CIDRs and/or remote security group IDs (not load balancer UIDs as a primitive) ().

• •Applied to Droplets via droplet_ids and/or tags; Neutron security groups attach to ports.
• •Both inbound and outbound rules; default deny all if no rules configured.
• •Free service like Neutron security groups; no implicit L4 stateful rules without explicit config.

• •Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
• •Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
• •Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
• •Rate limits: 5000/hour, 250/minute.

No specific divergences documented yet.

• •A Droplet must select a predefined “size” bundle (RAM/vCPU/disk/transfer) rather than choosing from an OpenStack flavor catalog that many clouds let you customize/extend at the project level.
• •The size object exposes explicit monthly pricing (price_monthly) and per-hour pricing (price_hourly) in the API response, whereas OpenStack clouds typically separate pricing from the Nova flavor definition.
• •DigitalOcean sizes embed transfer allowance and region availability directly in the size metadata, while OpenStack flavors generally describe compute resources and rely on separate networking/quotas/policies for bandwidth and availability.
• •DigitalOcean size classes are described in the API as categories like Basic, General Purpose, CPU-Optimized, Memory-Optimized, and Storage-Optimized rather than OpenStack’s provider-defined flavor naming/extra-specs approach.

• •DigitalOcean requires the Droplet to be powered off for a consistent snapshot (POST /v2/droplets/{id}/actions with {"type": "snapshot"}); a live snapshot option exists but is explicitly not guaranteed to be consistent. OpenStack Nova createImage is non-disruptive on running instances.
• •DO Droplet snapshots are billed per-GiB per month. Automated weekly backups are a percentage of the Droplet monthly price and retain the last 4 snapshots. See the DigitalOcean pricing page for current rates.
• •Droplet snapshot creation powers down the Droplet by default, creating downtime unless the live (inconsistent) option is used. Nova createImage is non-disruptive and does not affect server state.
• •DO snapshots can be used to create new Droplets in any region (with cross-region transfer) or restore the original Droplet. Nova images can launch new instances in the same region; cross-region requires Glance backend replication or manual download/upload.

• •API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
• •Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
• •Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
• •Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.

• •DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
• •Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
• •DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
• •DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.

• •Uses proprietary DigitalOcean API (POST /v2/kubernetes/clusters) for provisioning; Quake AI users provision Nova instances via OpenTofu and bootstrap Kubernetes manually (kubeadm, k3s).
• •No cluster templates; direct specification of node pools in create request. Quake AI uses OpenTofu modules or IaC patterns to define cluster topology.
• •Fully managed control plane at no cost (HA mode is a paid optional add-on); on Quake AI you provision the control plane through Magnum or self-managed on Nova instances and operate it yourself, including HA configuration.
• •Node pools consist of identical Droplet-based worker nodes managed solely via kubectl (no SSH access); Quake AI nodes are Nova instances with full SSH access via keypair.

• •Product shape: DigitalOcean provides regional and global managed load balancers. Quake AI workloads use a self-managed reverse proxy, CDN/WAF edge, or Kubernetes LoadBalancer Service.
• •DigitalOcean can select backend Droplets by explicit list or by tag. Self-managed Quake AI edges select backends through proxy or ingress configuration.
• •VPC connectivity behavior: the load balancer automatically connects to Droplets in its VPC network and falls back to public IP if private networking is disabled. Self-managed Quake AI edges route to backends through proxy configuration.
• •DigitalOcean documents built-in Let’s Encrypt certificate management, optional PROXY protocol v1, and regional HTTP/3 support. On Quake AI, configure these features on the selected self-managed edge.

• •DigitalOcean VPCs automatically manage an internal IP range; users cannot create, delete, or resize subnets. Neutron subnets are explicitly provisioned with user-defined CIDRs and DHCP pool configurations.
• •All Droplets in a DO VPC share a single flat address space; there is no subnet segmentation within a VPC. Neutron supports multiple subnets per network with independent CIDR blocks.
• •DO's API exposes VPCs at /v2/vpcs but has no /subnets endpoint; the subnet concept does not exist as an addressable API resource. Neutron exposes subnets at /v2.0/subnets as first-class resources.
• •IP address assignment within a DO VPC is automatic and cannot be specified at creation; Neutron allows fixed IP allocation per port at port creation time.

• •DigitalOcean has no port concept. Droplets receive a private VPC IP automatically on creation; the network interface is implicit and not separately addressable via API. Neutron ports are explicit first-class resources with UUIDs, security group associations, and independent lifecycle.
• •Allowed-address-pairs (for floating secondary IPs, VRRP high availability) are not supported in DO's VPC model. Neutron allowed-address-pairs enable virtual IP patterns used for active-standby clustering.
• •DO Firewalls attach to Droplets or tags, not to network interfaces. Neutron security groups attach to ports, enabling per-interface rules on multi-homed instances.
• •IP address assignment in DO is automatic; a fixed IP cannot be specified at interface creation. Neutron allows fixed_ips specification at port creation with subnet-specific allocation.

• •DigitalOcean has no managed router resource. The VPC NAT Gateway (GA November 2025) handles outbound internet egress for private Droplets; it is not a general-purpose router and does not support inter-VPC routing.
• •Neutron routers connect multiple networks and subnets with configurable routing tables. DO's VPC is a flat network; there is no concept of connecting multiple VPCs via a router in the data plane.
• •Neutron supports east-west routing between subnets on the same router. DO Droplets in the same VPC communicate directly over private IPs without any router provisioning.
• •NAT Gateway in DO is provisioned at the VPC level (POST /v2/vpc_nat_gateways) with no concept of router interfaces or subnet attachments. Neutron router-interface-add attaches specific subnets to a router for controlled routing.

• •DigitalOcean has no subscription model; billing is usage-based with a monthly invoice. Resources are billed from provisioning to deletion at hourly or monthly rates. No reserved or committed use discounts are available.
• •DO provides a monthly spending limit (soft cap with alert) but no hard subscription tier. Quake AI's billing model is operator-defined.
• •DigitalOcean includes a bandwidth allowance per Droplet/Load Balancer in the resource price; outbound bandwidth beyond the allowance is metered per-GiB. Inbound bandwidth is always free. Quake AI's bandwidth pricing is operator-defined.
• •DO invoices are per-account (or per-team) and generated monthly with no billing account hierarchy above the team level.

• •DigitalOcean PATs are account-scoped (access all resources across all projects for that account) with a choice of read or read/write scope. OpenStack application credentials are project-scoped and tied to a specific set of roles.
• •DO supports OAuth2 for third-party app authorization (apps request access on behalf of a user). OpenStack Keystone supports OAuth1.0 for delegated token issuance; full OAuth2 support depends on the Keystone deployment.
• •DO PATs can be set to expire (custom expiry date) or be non-expiring. Keystone token TTL is server-configured, not per-credential.
• •DO does not support service accounts independent of a user identity. OpenStack application credentials survive user password changes and can be restricted to specific API operations via access rules.

• •UI/organizational grouping of resources (Droplets, Spaces, etc.) into named projects with description/purpose/environment; default project exists.
• •API for CRUD projects/resources; resources moved between projects.
• •Purely organizational, no access control/billing isolation like OpenStack projects; resources still scoped by teams.
• •Three resource types: project-based, droplet-based, independent.

• •Naming/API surface: DigitalOcean renamed Floating IPs to Reserved IPs; endpoints and fields change from `floating_ips` to `reserved_ips` (while legacy endpoints existed until a stated deprecation window), whereas OpenStack retains the “floatingip” resource in Neutron APIs ().
• •Identity model: DigitalOcean’s resource identifier in the API path is the IP address itself (`/v2/reserved_ips/{reserved_ip}` where `{reserved_ip}` is an IPv4 address), whereas OpenStack commonly uses UUID identifiers for Neutron resources like floating IPs and ports ().
• •Attachment model: creation requires either `droplet_id` or `region` and reassignment is conceptually “map to a Droplet”; OpenStack associates floating IPs to Neutron ports (and thus can be used with more complex networking constructs like routers), which is a different mental model for migrating users ().
• •Region binding: DigitalOcean Reserved IPs are explicitly bound to a region, while OpenStack floating IP pools are usually defined per external network and can be consumed wherever that external network is reachable (implementation-specific) ().

• •Naming differs: users create a “Space” that is a bucket, and each bucket has a unique URL (virtual-hosted or path style), whereas Swift uses containers within an account namespace. ().
• •Bucket addressing uses S3-style endpoints such as `${BUCKET}.${REGION}.digitaloceanspaces.com` (and `${REGION}.digitaloceanspaces.com/${BUCKET}`), which differs from Swift’s account/container/object path conventions. (, ).
• •Access keys can be scoped to high-level permission tiers (Read, Read/Write/Delete, All) applied across buckets/objects, which differs from Swift’s typical tenant/user + container ACL model. ().

• •Spaces documents that it implements only a subset of the Amazon S3 API; migrating users may need to validate specific S3 operations/behaviors they rely on rather than assuming full parity. ().
• •Endpoint format is region-based (`${REGION}.digitaloceanspaces.com`) and uses bucket subdomains, which differs from typical OpenStack endpoint discovery (Keystone catalog) and Swift URL layouts. ().
• •Spaces supports SigV4 (recommended) and SigV2 (legacy) signing for S3 requests, whereas OpenStack Swift deployments often rely on Keystone tokens for Swift API access (and any S3 compatibility is typically provided via an additional gateway). (, ).

• •DigitalOcean charges a flat monthly base fee for a Spaces Standard Storage subscription that includes pooled storage and outbound transfer allowances across all buckets, then per‑GiB overages. Swift itself is not inherently coupled to a billing system, and pricing is operator-defined. See the DigitalOcean Spaces pricing page for current rates.
• •Outbound data transfer overage is explicitly billed per-GiB and applies to both Standard and Cold Storage; many OpenStack-based clouds may bundle or price transfer differently.
• •Cold Storage adds retrieval fees per-GiB and early deletion/update fees, which migrating users must incorporate into access patterns and lifecycle policies.

• •SSH keys are managed at the account/team level via /v2/account/keys and then referenced by ID/fingerprint when creating Droplets, whereas OpenStack Nova keypairs are typically created per project/tenant and managed via the Nova API.
• •DigitalOcean explicitly notes that including a key during Droplet creation embeds it into the root user’s authorized_keys, whereas OpenStack’s keypair injection mechanism is generally cloud-init/metadata-service driven and may vary by image/cloud config.
• •DigitalOcean tokens/scopes model for API authorization (bearer tokens with scopes like ssh_key:read) differs from OpenStack Keystone’s token + role-based policy model.
• •DigitalOcean documentation emphasizes that post-creation SSH key changes are performed inside the guest OS (not via control panel), whereas OpenStack users may rely more heavily on metadata/cloud-init or config management patterns post-boot.

• •DigitalOcean uses tags as a grouping/selection mechanism (filtering, bulk actions, auto-inclusion in firewall/LB configs) rather than OpenStack Nova server groups that implement affinity/anti-affinity placement policies.
• •No documented user-facing placement policy (affinity/anti-affinity) is exposed via tags; tags are for organization and targeting actions, unlike OpenStack server groups which influence scheduling decisions.
• •DigitalOcean’s tags API requires canonical capitalization in the URL (e.g., /v2/tags/PROD/resources), which is a platform-specific behavior not typically present in OpenStack resource tagging.
• •Bulk actions on Droplets can be initiated across resources sharing a tag via DigitalOcean API endpoints, whereas OpenStack server groups are separate resources with policies and memberships managed via Nova.

• •DigitalOcean Teams allow multiple users to share access to one billing account's resources. There is no hierarchy above the team level; Teams cannot be grouped or nested. Quake AI's Organization → Project model provides two levels of isolation.
• •DO Teams use a simple Owner/Member role model for the entire team. OpenStack Keystone roles (admin, member, reader) are project-scoped and assignable per-user per-project for fine-grained access control.
• •All resources created by DO team members belong to the team's account; there is no per-member resource scoping. OpenStack resources belong to a project and users access them through project membership roles.
• •DO Teams have no concept of sub-teams or nested groups. OpenStack supports domain-level user management with project hierarchies (nested projects) in Keystone v3.

• •Proprietary API /v2/volumes/{volume_id}/snapshots instead of OpenStack /v3/{project_id}/snapshots.
• •Explicitly crash-consistent only, no automatic filesystem consistency (requires manual power-off/sync); OpenStack snapshots can use quiescing drivers for apps like databases.
• •Snapshots billed separately based on block-level used size (may exceed filesystem due to trim); OpenStack typically similar. See the DigitalOcean pricing page for current rates.
• •Can create new volumes only in same region as snapshot; OpenStack snapshots more flexible for cross-region with upload/download.

• •Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
• •Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
• •Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
• •Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

• •Region-scoped: a VPC network is created in a specific datacenter region and resources must be in that same region to be attached, whereas OpenStack Neutron networks/subnets are generally available across all AZs in a region and attachments are controlled by network reachability rather than an explicit region slug ().
• •Resource migration is limited: Droplets require snapshot/recreate to move between VPCs and some resources (Kubernetes clusters, load balancers, NAT gateways) cannot be migrated between VPCs, whereas in OpenStack you typically can attach/detach ports or move router interfaces without recreating servers (behavior depends on deployment, but Neutron’s object model supports it) ().
• •NAT is a managed NAT Gateway with tiered capacity (1–16 increments; each increment gives 25 Mbps symmetrical bandwidth and 100 GiB outbound transfer/month) and can be set as the default gateway for the VPC, whereas OpenStack commonly expresses egress via Neutron routers with SNAT and does not use this specific ‘size tier’ model ().
• •Security-policy coupling differs: DigitalOcean notes Cloud Firewall rules affect both public and VPC traffic and rules must specify whether they apply to the public or private IP range, whereas in OpenStack security groups are generally applied to ports and are not framed as “public vs private IP range” rule modes ().

• •DO VPC NAT Gateway (POST /v2/vpc_nat_gateways) provides outbound internet egress (SNAT) for private Droplets only; it does not support inbound NAT (DNAT). Neutron supports both SNAT via router external gateway and DNAT via floating IP association.
• •DO NAT Gateway is set as the VPC default gateway; all private Droplets automatically route outbound traffic through it. Neutron requires enable_snat: true on the router gateway; per-port floating IP assignment handles DNAT separately.
• •Only one NAT Gateway can be set as the default gateway per VPC. Neutron supports multiple routers per project with independent SNAT configurations.
• •DO NAT Gateway is billed hourly as a separate resource in addition to Droplet costs. Neutron SNAT is included in the router resource with no separate charge on Quake AI.

• •VPC-native using Cilium eBPF (K8s 1.31+), Gateway API default on 1.33+; Quake AI Kubernetes clusters use CNI plugins (Flannel, Calico, Cilium) on Neutron private networks.
• •Direct pod-to-VPC resource routing and internal load balancers; Quake AI Kubernetes clusters expose services through Kubernetes LoadBalancer behavior and floating IPs.

• •REST endpoints for balance, history, invoices (PDF/CSV), insights via team URN (do:team:uuid).
• •Usage-based with monthly invoices on 1st; prepaid credits model.
• •Invoice items include project_name; no OpenStack Ceilometer-style real-time metering API.
• •Pagination and rate-limited.

• •Application model: DigitalOcean firewalls are applied to Droplets via `droplet_ids` and/or tags, whereas OpenStack security groups are typically attached to Neutron ports (VM NICs) and can vary per port ().
• •Rule model includes both inbound and outbound rules and notes that if none are configured then no traffic is permitted in that direction; OpenStack security groups also support egress rules but many deployments default to allow-all egress—migrating users may need to explicitly model egress restrictions in DigitalOcean if they rely on different defaults ().
• •Aggregation semantics: DigitalOcean states that when multiple cloud firewalls apply to a Droplet, rules are additive (“union of the rules”) and a more permissive rule in any firewall effectively opens access; OpenStack security groups are also generally additive, but users migrating from “deny-by-default with explicit groups” patterns may be surprised by how quickly access broadens when stacking policies ().
• •Target/source object types differ: DigitalOcean allows sources/destinations to include load balancers (by UID) and uses constructs like `load_balancer_uids`, `droplet_ids`, `tags`, and CIDRs in rule JSON, whereas OpenStack security group rules typically reference CIDRs and/or remote security group IDs (not load balancer UIDs as a primitive) ().

• •Applied to Droplets via droplet_ids and/or tags; Neutron security groups attach to ports.
• •Both inbound and outbound rules; default deny all if no rules configured.
• •Free service like Neutron security groups; no implicit L4 stateful rules without explicit config.

• •Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
• •Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
• •Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
• •Rate limits: 5000/hour, 250/minute.

No specific divergences documented yet.

• •A Droplet must select a predefined “size” bundle (RAM/vCPU/disk/transfer) rather than choosing from an OpenStack flavor catalog that many clouds let you customize/extend at the project level.
• •The size object exposes explicit monthly pricing (price_monthly) and per-hour pricing (price_hourly) in the API response, whereas OpenStack clouds typically separate pricing from the Nova flavor definition.
• •DigitalOcean sizes embed transfer allowance and region availability directly in the size metadata, while OpenStack flavors generally describe compute resources and rely on separate networking/quotas/policies for bandwidth and availability.
• •DigitalOcean size classes are described in the API as categories like Basic, General Purpose, CPU-Optimized, Memory-Optimized, and Storage-Optimized rather than OpenStack’s provider-defined flavor naming/extra-specs approach.

• •DigitalOcean requires the Droplet to be powered off for a consistent snapshot (POST /v2/droplets/{id}/actions with {"type": "snapshot"}); a live snapshot option exists but is explicitly not guaranteed to be consistent. OpenStack Nova createImage is non-disruptive on running instances.
• •DO Droplet snapshots are billed per-GiB per month. Automated weekly backups are a percentage of the Droplet monthly price and retain the last 4 snapshots. See the DigitalOcean pricing page for current rates.
• •Droplet snapshot creation powers down the Droplet by default, creating downtime unless the live (inconsistent) option is used. Nova createImage is non-disruptive and does not affect server state.
• •DO snapshots can be used to create new Droplets in any region (with cross-region transfer) or restore the original Droplet. Nova images can launch new instances in the same region; cross-region requires Glance backend replication or manual download/upload.

• •API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
• •Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
• •Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
• •Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.

• •DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
• •Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
• •DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
• •DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.

• •Uses proprietary DigitalOcean API (POST /v2/kubernetes/clusters) for provisioning; Quake AI users provision Nova instances via OpenTofu and bootstrap Kubernetes manually (kubeadm, k3s).
• •No cluster templates; direct specification of node pools in create request. Quake AI uses OpenTofu modules or IaC patterns to define cluster topology.
• •Fully managed control plane at no cost (HA mode is a paid optional add-on); on Quake AI you provision the control plane through Magnum or self-managed on Nova instances and operate it yourself, including HA configuration.
• •Node pools consist of identical Droplet-based worker nodes managed solely via kubectl (no SSH access); Quake AI nodes are Nova instances with full SSH access via keypair.

• •Product shape: DigitalOcean provides regional and global managed load balancers. Quake AI workloads use a self-managed reverse proxy, CDN/WAF edge, or Kubernetes LoadBalancer Service.
• •DigitalOcean can select backend Droplets by explicit list or by tag. Self-managed Quake AI edges select backends through proxy or ingress configuration.
• •VPC connectivity behavior: the load balancer automatically connects to Droplets in its VPC network and falls back to public IP if private networking is disabled. Self-managed Quake AI edges route to backends through proxy configuration.
• •DigitalOcean documents built-in Let’s Encrypt certificate management, optional PROXY protocol v1, and regional HTTP/3 support. On Quake AI, configure these features on the selected self-managed edge.

• •DigitalOcean VPCs automatically manage an internal IP range; users cannot create, delete, or resize subnets. Neutron subnets are explicitly provisioned with user-defined CIDRs and DHCP pool configurations.
• •All Droplets in a DO VPC share a single flat address space; there is no subnet segmentation within a VPC. Neutron supports multiple subnets per network with independent CIDR blocks.
• •DO's API exposes VPCs at /v2/vpcs but has no /subnets endpoint; the subnet concept does not exist as an addressable API resource. Neutron exposes subnets at /v2.0/subnets as first-class resources.
• •IP address assignment within a DO VPC is automatic and cannot be specified at creation; Neutron allows fixed IP allocation per port at port creation time.

• •DigitalOcean has no port concept. Droplets receive a private VPC IP automatically on creation; the network interface is implicit and not separately addressable via API. Neutron ports are explicit first-class resources with UUIDs, security group associations, and independent lifecycle.
• •Allowed-address-pairs (for floating secondary IPs, VRRP high availability) are not supported in DO's VPC model. Neutron allowed-address-pairs enable virtual IP patterns used for active-standby clustering.
• •DO Firewalls attach to Droplets or tags, not to network interfaces. Neutron security groups attach to ports, enabling per-interface rules on multi-homed instances.
• •IP address assignment in DO is automatic; a fixed IP cannot be specified at interface creation. Neutron allows fixed_ips specification at port creation with subnet-specific allocation.

• •DigitalOcean has no managed router resource. The VPC NAT Gateway (GA November 2025) handles outbound internet egress for private Droplets; it is not a general-purpose router and does not support inter-VPC routing.
• •Neutron routers connect multiple networks and subnets with configurable routing tables. DO's VPC is a flat network; there is no concept of connecting multiple VPCs via a router in the data plane.
• •Neutron supports east-west routing between subnets on the same router. DO Droplets in the same VPC communicate directly over private IPs without any router provisioning.
• •NAT Gateway in DO is provisioned at the VPC level (POST /v2/vpc_nat_gateways) with no concept of router interfaces or subnet attachments. Neutron router-interface-add attaches specific subnets to a router for controlled routing.

• •DigitalOcean has no subscription model; billing is usage-based with a monthly invoice. Resources are billed from provisioning to deletion at hourly or monthly rates. No reserved or committed use discounts are available.
• •DO provides a monthly spending limit (soft cap with alert) but no hard subscription tier. Quake AI's billing model is operator-defined.
• •DigitalOcean includes a bandwidth allowance per Droplet/Load Balancer in the resource price; outbound bandwidth beyond the allowance is metered per-GiB. Inbound bandwidth is always free. Quake AI's bandwidth pricing is operator-defined.
• •DO invoices are per-account (or per-team) and generated monthly with no billing account hierarchy above the team level.

• •DigitalOcean PATs are account-scoped (access all resources across all projects for that account) with a choice of read or read/write scope. OpenStack application credentials are project-scoped and tied to a specific set of roles.
• •DO supports OAuth2 for third-party app authorization (apps request access on behalf of a user). OpenStack Keystone supports OAuth1.0 for delegated token issuance; full OAuth2 support depends on the Keystone deployment.
• •DO PATs can be set to expire (custom expiry date) or be non-expiring. Keystone token TTL is server-configured, not per-credential.
• •DO does not support service accounts independent of a user identity. OpenStack application credentials survive user password changes and can be restricted to specific API operations via access rules.

• •UI/organizational grouping of resources (Droplets, Spaces, etc.) into named projects with description/purpose/environment; default project exists.
• •API for CRUD projects/resources; resources moved between projects.
• •Purely organizational, no access control/billing isolation like OpenStack projects; resources still scoped by teams.
• •Three resource types: project-based, droplet-based, independent.

• •Naming/API surface: DigitalOcean renamed Floating IPs to Reserved IPs; endpoints and fields change from `floating_ips` to `reserved_ips` (while legacy endpoints existed until a stated deprecation window), whereas OpenStack retains the “floatingip” resource in Neutron APIs ().
• •Identity model: DigitalOcean’s resource identifier in the API path is the IP address itself (`/v2/reserved_ips/{reserved_ip}` where `{reserved_ip}` is an IPv4 address), whereas OpenStack commonly uses UUID identifiers for Neutron resources like floating IPs and ports ().
• •Attachment model: creation requires either `droplet_id` or `region` and reassignment is conceptually “map to a Droplet”; OpenStack associates floating IPs to Neutron ports (and thus can be used with more complex networking constructs like routers), which is a different mental model for migrating users ().
• •Region binding: DigitalOcean Reserved IPs are explicitly bound to a region, while OpenStack floating IP pools are usually defined per external network and can be consumed wherever that external network is reachable (implementation-specific) ().

• •Naming differs: users create a “Space” that is a bucket, and each bucket has a unique URL (virtual-hosted or path style), whereas Swift uses containers within an account namespace. ().
• •Bucket addressing uses S3-style endpoints such as `${BUCKET}.${REGION}.digitaloceanspaces.com` (and `${REGION}.digitaloceanspaces.com/${BUCKET}`), which differs from Swift’s account/container/object path conventions. (, ).
• •Access keys can be scoped to high-level permission tiers (Read, Read/Write/Delete, All) applied across buckets/objects, which differs from Swift’s typical tenant/user + container ACL model. ().

• •Spaces documents that it implements only a subset of the Amazon S3 API; migrating users may need to validate specific S3 operations/behaviors they rely on rather than assuming full parity. ().
• •Endpoint format is region-based (`${REGION}.digitaloceanspaces.com`) and uses bucket subdomains, which differs from typical OpenStack endpoint discovery (Keystone catalog) and Swift URL layouts. ().
• •Spaces supports SigV4 (recommended) and SigV2 (legacy) signing for S3 requests, whereas OpenStack Swift deployments often rely on Keystone tokens for Swift API access (and any S3 compatibility is typically provided via an additional gateway). (, ).

• •DigitalOcean charges a flat monthly base fee for a Spaces Standard Storage subscription that includes pooled storage and outbound transfer allowances across all buckets, then per‑GiB overages. Swift itself is not inherently coupled to a billing system, and pricing is operator-defined. See the DigitalOcean Spaces pricing page for current rates.
• •Outbound data transfer overage is explicitly billed per-GiB and applies to both Standard and Cold Storage; many OpenStack-based clouds may bundle or price transfer differently.
• •Cold Storage adds retrieval fees per-GiB and early deletion/update fees, which migrating users must incorporate into access patterns and lifecycle policies.

• •SSH keys are managed at the account/team level via /v2/account/keys and then referenced by ID/fingerprint when creating Droplets, whereas OpenStack Nova keypairs are typically created per project/tenant and managed via the Nova API.
• •DigitalOcean explicitly notes that including a key during Droplet creation embeds it into the root user’s authorized_keys, whereas OpenStack’s keypair injection mechanism is generally cloud-init/metadata-service driven and may vary by image/cloud config.
• •DigitalOcean tokens/scopes model for API authorization (bearer tokens with scopes like ssh_key:read) differs from OpenStack Keystone’s token + role-based policy model.
• •DigitalOcean documentation emphasizes that post-creation SSH key changes are performed inside the guest OS (not via control panel), whereas OpenStack users may rely more heavily on metadata/cloud-init or config management patterns post-boot.

• •DigitalOcean uses tags as a grouping/selection mechanism (filtering, bulk actions, auto-inclusion in firewall/LB configs) rather than OpenStack Nova server groups that implement affinity/anti-affinity placement policies.
• •No documented user-facing placement policy (affinity/anti-affinity) is exposed via tags; tags are for organization and targeting actions, unlike OpenStack server groups which influence scheduling decisions.
• •DigitalOcean’s tags API requires canonical capitalization in the URL (e.g., /v2/tags/PROD/resources), which is a platform-specific behavior not typically present in OpenStack resource tagging.
• •Bulk actions on Droplets can be initiated across resources sharing a tag via DigitalOcean API endpoints, whereas OpenStack server groups are separate resources with policies and memberships managed via Nova.

• •DigitalOcean Teams allow multiple users to share access to one billing account's resources. There is no hierarchy above the team level; Teams cannot be grouped or nested. Quake AI's Organization → Project model provides two levels of isolation.
• •DO Teams use a simple Owner/Member role model for the entire team. OpenStack Keystone roles (admin, member, reader) are project-scoped and assignable per-user per-project for fine-grained access control.
• •All resources created by DO team members belong to the team's account; there is no per-member resource scoping. OpenStack resources belong to a project and users access them through project membership roles.
• •DO Teams have no concept of sub-teams or nested groups. OpenStack supports domain-level user management with project hierarchies (nested projects) in Keystone v3.

• •Proprietary API /v2/volumes/{volume_id}/snapshots instead of OpenStack /v3/{project_id}/snapshots.
• •Explicitly crash-consistent only, no automatic filesystem consistency (requires manual power-off/sync); OpenStack snapshots can use quiescing drivers for apps like databases.
• •Snapshots billed separately based on block-level used size (may exceed filesystem due to trim); OpenStack typically similar. See the DigitalOcean pricing page for current rates.
• •Can create new volumes only in same region as snapshot; OpenStack snapshots more flexible for cross-region with upload/download.

• •Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
• •Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
• •Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
• •Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

• •Region-scoped: a VPC network is created in a specific datacenter region and resources must be in that same region to be attached, whereas OpenStack Neutron networks/subnets are generally available across all AZs in a region and attachments are controlled by network reachability rather than an explicit region slug ().
• •Resource migration is limited: Droplets require snapshot/recreate to move between VPCs and some resources (Kubernetes clusters, load balancers, NAT gateways) cannot be migrated between VPCs, whereas in OpenStack you typically can attach/detach ports or move router interfaces without recreating servers (behavior depends on deployment, but Neutron’s object model supports it) ().
• •NAT is a managed NAT Gateway with tiered capacity (1–16 increments; each increment gives 25 Mbps symmetrical bandwidth and 100 GiB outbound transfer/month) and can be set as the default gateway for the VPC, whereas OpenStack commonly expresses egress via Neutron routers with SNAT and does not use this specific ‘size tier’ model ().
• •Security-policy coupling differs: DigitalOcean notes Cloud Firewall rules affect both public and VPC traffic and rules must specify whether they apply to the public or private IP range, whereas in OpenStack security groups are generally applied to ports and are not framed as “public vs private IP range” rule modes ().

• •DO VPC NAT Gateway (POST /v2/vpc_nat_gateways) provides outbound internet egress (SNAT) for private Droplets only; it does not support inbound NAT (DNAT). Neutron supports both SNAT via router external gateway and DNAT via floating IP association.
• •DO NAT Gateway is set as the VPC default gateway; all private Droplets automatically route outbound traffic through it. Neutron requires enable_snat: true on the router gateway; per-port floating IP assignment handles DNAT separately.
• •Only one NAT Gateway can be set as the default gateway per VPC. Neutron supports multiple routers per project with independent SNAT configurations.
• •DO NAT Gateway is billed hourly as a separate resource in addition to Droplet costs. Neutron SNAT is included in the router resource with no separate charge on Quake AI.

• •VPC-native using Cilium eBPF (K8s 1.31+), Gateway API default on 1.33+; Quake AI Kubernetes clusters use CNI plugins (Flannel, Calico, Cilium) on Neutron private networks.
• •Direct pod-to-VPC resource routing and internal load balancers; Quake AI Kubernetes clusters expose services through Kubernetes LoadBalancer behavior and floating IPs.

• •Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
• •Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
• •Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
• •Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

• •REST endpoints for balance, history, invoices (PDF/CSV), insights via team URN (do:team:uuid).
• •Usage-based with monthly invoices on 1st; prepaid credits model.
• •Invoice items include project_name; no OpenStack Ceilometer-style real-time metering API.
• •Pagination and rate-limited.

• •Application model: DigitalOcean firewalls are applied to Droplets via `droplet_ids` and/or tags, whereas OpenStack security groups are typically attached to Neutron ports (VM NICs) and can vary per port ().
• •Rule model includes both inbound and outbound rules and notes that if none are configured then no traffic is permitted in that direction; OpenStack security groups also support egress rules but many deployments default to allow-all egress—migrating users may need to explicitly model egress restrictions in DigitalOcean if they rely on different defaults ().
• •Aggregation semantics: DigitalOcean states that when multiple cloud firewalls apply to a Droplet, rules are additive (“union of the rules”) and a more permissive rule in any firewall effectively opens access; OpenStack security groups are also generally additive, but users migrating from “deny-by-default with explicit groups” patterns may be surprised by how quickly access broadens when stacking policies ().
• •Target/source object types differ: DigitalOcean allows sources/destinations to include load balancers (by UID) and uses constructs like `load_balancer_uids`, `droplet_ids`, `tags`, and CIDRs in rule JSON, whereas OpenStack security group rules typically reference CIDRs and/or remote security group IDs (not load balancer UIDs as a primitive) ().

• •Applied to Droplets via droplet_ids and/or tags; Neutron security groups attach to ports.
• •Both inbound and outbound rules; default deny all if no rules configured.
• •Free service like Neutron security groups; no implicit L4 stateful rules without explicit config.

• •Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
• •Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
• •Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
• •Rate limits: 5000/hour, 250/minute.

No specific divergences documented yet.

• •A Droplet must select a predefined “size” bundle (RAM/vCPU/disk/transfer) rather than choosing from an OpenStack flavor catalog that many clouds let you customize/extend at the project level.
• •The size object exposes explicit monthly pricing (price_monthly) and per-hour pricing (price_hourly) in the API response, whereas OpenStack clouds typically separate pricing from the Nova flavor definition.
• •DigitalOcean sizes embed transfer allowance and region availability directly in the size metadata, while OpenStack flavors generally describe compute resources and rely on separate networking/quotas/policies for bandwidth and availability.
• •DigitalOcean size classes are described in the API as categories like Basic, General Purpose, CPU-Optimized, Memory-Optimized, and Storage-Optimized rather than OpenStack’s provider-defined flavor naming/extra-specs approach.

• •DigitalOcean requires the Droplet to be powered off for a consistent snapshot (POST /v2/droplets/{id}/actions with {"type": "snapshot"}); a live snapshot option exists but is explicitly not guaranteed to be consistent. OpenStack Nova createImage is non-disruptive on running instances.
• •DO Droplet snapshots are billed per-GiB per month. Automated weekly backups are a percentage of the Droplet monthly price and retain the last 4 snapshots. See the DigitalOcean pricing page for current rates.
• •Droplet snapshot creation powers down the Droplet by default, creating downtime unless the live (inconsistent) option is used. Nova createImage is non-disruptive and does not affect server state.
• •DO snapshots can be used to create new Droplets in any region (with cross-region transfer) or restore the original Droplet. Nova images can launch new instances in the same region; cross-region requires Glance backend replication or manual download/upload.

• •API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
• •Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
• •Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
• •Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.

• •DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
• •Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
• •DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
• •DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.

• •Uses proprietary DigitalOcean API (POST /v2/kubernetes/clusters) for provisioning; Quake AI users provision Nova instances via OpenTofu and bootstrap Kubernetes manually (kubeadm, k3s).
• •No cluster templates; direct specification of node pools in create request. Quake AI uses OpenTofu modules or IaC patterns to define cluster topology.
• •Fully managed control plane at no cost (HA mode is a paid optional add-on); on Quake AI you provision the control plane through Magnum or self-managed on Nova instances and operate it yourself, including HA configuration.
• •Node pools consist of identical Droplet-based worker nodes managed solely via kubectl (no SSH access); Quake AI nodes are Nova instances with full SSH access via keypair.

• •Product shape: DigitalOcean provides regional and global managed load balancers. Quake AI workloads use a self-managed reverse proxy, CDN/WAF edge, or Kubernetes LoadBalancer Service.
• •DigitalOcean can select backend Droplets by explicit list or by tag. Self-managed Quake AI edges select backends through proxy or ingress configuration.
• •VPC connectivity behavior: the load balancer automatically connects to Droplets in its VPC network and falls back to public IP if private networking is disabled. Self-managed Quake AI edges route to backends through proxy configuration.
• •DigitalOcean documents built-in Let’s Encrypt certificate management, optional PROXY protocol v1, and regional HTTP/3 support. On Quake AI, configure these features on the selected self-managed edge.

• •DigitalOcean VPCs automatically manage an internal IP range; users cannot create, delete, or resize subnets. Neutron subnets are explicitly provisioned with user-defined CIDRs and DHCP pool configurations.
• •All Droplets in a DO VPC share a single flat address space; there is no subnet segmentation within a VPC. Neutron supports multiple subnets per network with independent CIDR blocks.
• •DO's API exposes VPCs at /v2/vpcs but has no /subnets endpoint; the subnet concept does not exist as an addressable API resource. Neutron exposes subnets at /v2.0/subnets as first-class resources.
• •IP address assignment within a DO VPC is automatic and cannot be specified at creation; Neutron allows fixed IP allocation per port at port creation time.

• •DigitalOcean has no port concept. Droplets receive a private VPC IP automatically on creation; the network interface is implicit and not separately addressable via API. Neutron ports are explicit first-class resources with UUIDs, security group associations, and independent lifecycle.
• •Allowed-address-pairs (for floating secondary IPs, VRRP high availability) are not supported in DO's VPC model. Neutron allowed-address-pairs enable virtual IP patterns used for active-standby clustering.
• •DO Firewalls attach to Droplets or tags, not to network interfaces. Neutron security groups attach to ports, enabling per-interface rules on multi-homed instances.
• •IP address assignment in DO is automatic; a fixed IP cannot be specified at interface creation. Neutron allows fixed_ips specification at port creation with subnet-specific allocation.

• •DigitalOcean has no managed router resource. The VPC NAT Gateway (GA November 2025) handles outbound internet egress for private Droplets; it is not a general-purpose router and does not support inter-VPC routing.
• •Neutron routers connect multiple networks and subnets with configurable routing tables. DO's VPC is a flat network; there is no concept of connecting multiple VPCs via a router in the data plane.
• •Neutron supports east-west routing between subnets on the same router. DO Droplets in the same VPC communicate directly over private IPs without any router provisioning.
• •NAT Gateway in DO is provisioned at the VPC level (POST /v2/vpc_nat_gateways) with no concept of router interfaces or subnet attachments. Neutron router-interface-add attaches specific subnets to a router for controlled routing.

• •DigitalOcean has no subscription model; billing is usage-based with a monthly invoice. Resources are billed from provisioning to deletion at hourly or monthly rates. No reserved or committed use discounts are available.
• •DO provides a monthly spending limit (soft cap with alert) but no hard subscription tier. Quake AI's billing model is operator-defined.
• •DigitalOcean includes a bandwidth allowance per Droplet/Load Balancer in the resource price; outbound bandwidth beyond the allowance is metered per-GiB. Inbound bandwidth is always free. Quake AI's bandwidth pricing is operator-defined.
• •DO invoices are per-account (or per-team) and generated monthly with no billing account hierarchy above the team level.

• •DigitalOcean PATs are account-scoped (access all resources across all projects for that account) with a choice of read or read/write scope. OpenStack application credentials are project-scoped and tied to a specific set of roles.
• •DO supports OAuth2 for third-party app authorization (apps request access on behalf of a user). OpenStack Keystone supports OAuth1.0 for delegated token issuance; full OAuth2 support depends on the Keystone deployment.
• •DO PATs can be set to expire (custom expiry date) or be non-expiring. Keystone token TTL is server-configured, not per-credential.
• •DO does not support service accounts independent of a user identity. OpenStack application credentials survive user password changes and can be restricted to specific API operations via access rules.

• •UI/organizational grouping of resources (Droplets, Spaces, etc.) into named projects with description/purpose/environment; default project exists.
• •API for CRUD projects/resources; resources moved between projects.
• •Purely organizational, no access control/billing isolation like OpenStack projects; resources still scoped by teams.
• •Three resource types: project-based, droplet-based, independent.

• •Naming/API surface: DigitalOcean renamed Floating IPs to Reserved IPs; endpoints and fields change from `floating_ips` to `reserved_ips` (while legacy endpoints existed until a stated deprecation window), whereas OpenStack retains the “floatingip” resource in Neutron APIs ().
• •Identity model: DigitalOcean’s resource identifier in the API path is the IP address itself (`/v2/reserved_ips/{reserved_ip}` where `{reserved_ip}` is an IPv4 address), whereas OpenStack commonly uses UUID identifiers for Neutron resources like floating IPs and ports ().
• •Attachment model: creation requires either `droplet_id` or `region` and reassignment is conceptually “map to a Droplet”; OpenStack associates floating IPs to Neutron ports (and thus can be used with more complex networking constructs like routers), which is a different mental model for migrating users ().
• •Region binding: DigitalOcean Reserved IPs are explicitly bound to a region, while OpenStack floating IP pools are usually defined per external network and can be consumed wherever that external network is reachable (implementation-specific) ().

• •Naming differs: users create a “Space” that is a bucket, and each bucket has a unique URL (virtual-hosted or path style), whereas Swift uses containers within an account namespace. ().
• •Bucket addressing uses S3-style endpoints such as `${BUCKET}.${REGION}.digitaloceanspaces.com` (and `${REGION}.digitaloceanspaces.com/${BUCKET}`), which differs from Swift’s account/container/object path conventions. (, ).
• •Access keys can be scoped to high-level permission tiers (Read, Read/Write/Delete, All) applied across buckets/objects, which differs from Swift’s typical tenant/user + container ACL model. ().

• •Spaces documents that it implements only a subset of the Amazon S3 API; migrating users may need to validate specific S3 operations/behaviors they rely on rather than assuming full parity. ().
• •Endpoint format is region-based (`${REGION}.digitaloceanspaces.com`) and uses bucket subdomains, which differs from typical OpenStack endpoint discovery (Keystone catalog) and Swift URL layouts. ().
• •Spaces supports SigV4 (recommended) and SigV2 (legacy) signing for S3 requests, whereas OpenStack Swift deployments often rely on Keystone tokens for Swift API access (and any S3 compatibility is typically provided via an additional gateway). (, ).

• •DigitalOcean charges a flat monthly base fee for a Spaces Standard Storage subscription that includes pooled storage and outbound transfer allowances across all buckets, then per‑GiB overages. Swift itself is not inherently coupled to a billing system, and pricing is operator-defined. See the DigitalOcean Spaces pricing page for current rates.
• •Outbound data transfer overage is explicitly billed per-GiB and applies to both Standard and Cold Storage; many OpenStack-based clouds may bundle or price transfer differently.
• •Cold Storage adds retrieval fees per-GiB and early deletion/update fees, which migrating users must incorporate into access patterns and lifecycle policies.

• •SSH keys are managed at the account/team level via /v2/account/keys and then referenced by ID/fingerprint when creating Droplets, whereas OpenStack Nova keypairs are typically created per project/tenant and managed via the Nova API.
• •DigitalOcean explicitly notes that including a key during Droplet creation embeds it into the root user’s authorized_keys, whereas OpenStack’s keypair injection mechanism is generally cloud-init/metadata-service driven and may vary by image/cloud config.
• •DigitalOcean tokens/scopes model for API authorization (bearer tokens with scopes like ssh_key:read) differs from OpenStack Keystone’s token + role-based policy model.
• •DigitalOcean documentation emphasizes that post-creation SSH key changes are performed inside the guest OS (not via control panel), whereas OpenStack users may rely more heavily on metadata/cloud-init or config management patterns post-boot.

• •DigitalOcean uses tags as a grouping/selection mechanism (filtering, bulk actions, auto-inclusion in firewall/LB configs) rather than OpenStack Nova server groups that implement affinity/anti-affinity placement policies.
• •No documented user-facing placement policy (affinity/anti-affinity) is exposed via tags; tags are for organization and targeting actions, unlike OpenStack server groups which influence scheduling decisions.
• •DigitalOcean’s tags API requires canonical capitalization in the URL (e.g., /v2/tags/PROD/resources), which is a platform-specific behavior not typically present in OpenStack resource tagging.
• •Bulk actions on Droplets can be initiated across resources sharing a tag via DigitalOcean API endpoints, whereas OpenStack server groups are separate resources with policies and memberships managed via Nova.

• •DigitalOcean Teams allow multiple users to share access to one billing account's resources. There is no hierarchy above the team level; Teams cannot be grouped or nested. Quake AI's Organization → Project model provides two levels of isolation.
• •DO Teams use a simple Owner/Member role model for the entire team. OpenStack Keystone roles (admin, member, reader) are project-scoped and assignable per-user per-project for fine-grained access control.
• •All resources created by DO team members belong to the team's account; there is no per-member resource scoping. OpenStack resources belong to a project and users access them through project membership roles.
• •DO Teams have no concept of sub-teams or nested groups. OpenStack supports domain-level user management with project hierarchies (nested projects) in Keystone v3.

• •Proprietary API /v2/volumes/{volume_id}/snapshots instead of OpenStack /v3/{project_id}/snapshots.
• •Explicitly crash-consistent only, no automatic filesystem consistency (requires manual power-off/sync); OpenStack snapshots can use quiescing drivers for apps like databases.
• •Snapshots billed separately based on block-level used size (may exceed filesystem due to trim); OpenStack typically similar. See the DigitalOcean pricing page for current rates.
• •Can create new volumes only in same region as snapshot; OpenStack snapshots more flexible for cross-region with upload/download.

• •Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
• •Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
• •Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
• •Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

• •Region-scoped: a VPC network is created in a specific datacenter region and resources must be in that same region to be attached, whereas OpenStack Neutron networks/subnets are generally available across all AZs in a region and attachments are controlled by network reachability rather than an explicit region slug ().
• •Resource migration is limited: Droplets require snapshot/recreate to move between VPCs and some resources (Kubernetes clusters, load balancers, NAT gateways) cannot be migrated between VPCs, whereas in OpenStack you typically can attach/detach ports or move router interfaces without recreating servers (behavior depends on deployment, but Neutron’s object model supports it) ().
• •NAT is a managed NAT Gateway with tiered capacity (1–16 increments; each increment gives 25 Mbps symmetrical bandwidth and 100 GiB outbound transfer/month) and can be set as the default gateway for the VPC, whereas OpenStack commonly expresses egress via Neutron routers with SNAT and does not use this specific ‘size tier’ model ().
• •Security-policy coupling differs: DigitalOcean notes Cloud Firewall rules affect both public and VPC traffic and rules must specify whether they apply to the public or private IP range, whereas in OpenStack security groups are generally applied to ports and are not framed as “public vs private IP range” rule modes ().

• •DO VPC NAT Gateway (POST /v2/vpc_nat_gateways) provides outbound internet egress (SNAT) for private Droplets only; it does not support inbound NAT (DNAT). Neutron supports both SNAT via router external gateway and DNAT via floating IP association.
• •DO NAT Gateway is set as the VPC default gateway; all private Droplets automatically route outbound traffic through it. Neutron requires enable_snat: true on the router gateway; per-port floating IP assignment handles DNAT separately.
• •Only one NAT Gateway can be set as the default gateway per VPC. Neutron supports multiple routers per project with independent SNAT configurations.
• •DO NAT Gateway is billed hourly as a separate resource in addition to Droplet costs. Neutron SNAT is included in the router resource with no separate charge on Quake AI.

• •VPC-native using Cilium eBPF (K8s 1.31+), Gateway API default on 1.33+; Quake AI Kubernetes clusters use CNI plugins (Flannel, Calico, Cilium) on Neutron private networks.
• •Direct pod-to-VPC resource routing and internal load balancers; Quake AI Kubernetes clusters expose services through Kubernetes LoadBalancer behavior and floating IPs.

• •DigitalOcean PATs are account-scoped (access all resources across all projects for that account) with a choice of read or read/write scope. OpenStack application credentials are project-scoped and tied to a specific set of roles.
• •DO supports OAuth2 for third-party app authorization (apps request access on behalf of a user). OpenStack Keystone supports OAuth1.0 for delegated token issuance; full OAuth2 support depends on the Keystone deployment.
• •DO PATs can be set to expire (custom expiry date) or be non-expiring. Keystone token TTL is server-configured, not per-credential.
• •DO does not support service accounts independent of a user identity. OpenStack application credentials survive user password changes and can be restricted to specific API operations via access rules.

• •UI/organizational grouping of resources (Droplets, Spaces, etc.) into named projects with description/purpose/environment; default project exists.
• •API for CRUD projects/resources; resources moved between projects.
• •Purely organizational, no access control/billing isolation like OpenStack projects; resources still scoped by teams.
• •Three resource types: project-based, droplet-based, independent.

• •DigitalOcean Teams allow multiple users to share access to one billing account's resources. There is no hierarchy above the team level; Teams cannot be grouped or nested. Quake AI's Organization → Project model provides two levels of isolation.
• •DO Teams use a simple Owner/Member role model for the entire team. OpenStack Keystone roles (admin, member, reader) are project-scoped and assignable per-user per-project for fine-grained access control.
• •All resources created by DO team members belong to the team's account; there is no per-member resource scoping. OpenStack resources belong to a project and users access them through project membership roles.
• •DO Teams have no concept of sub-teams or nested groups. OpenStack supports domain-level user management with project hierarchies (nested projects) in Keystone v3.

• •REST endpoints for balance, history, invoices (PDF/CSV), insights via team URN (do:team:uuid).
• •Usage-based with monthly invoices on 1st; prepaid credits model.
• •Invoice items include project_name; no OpenStack Ceilometer-style real-time metering API.
• •Pagination and rate-limited.

• •DigitalOcean has no subscription model; billing is usage-based with a monthly invoice. Resources are billed from provisioning to deletion at hourly or monthly rates. No reserved or committed use discounts are available.
• •DO provides a monthly spending limit (soft cap with alert) but no hard subscription tier. Quake AI's billing model is operator-defined.
• •DigitalOcean includes a bandwidth allowance per Droplet/Load Balancer in the resource price; outbound bandwidth beyond the allowance is metered per-GiB. Inbound bandwidth is always free. Quake AI's bandwidth pricing is operator-defined.
• •DO invoices are per-account (or per-team) and generated monthly with no billing account hierarchy above the team level.

• •DigitalOcean charges a flat monthly base fee for a Spaces Standard Storage subscription that includes pooled storage and outbound transfer allowances across all buckets, then per‑GiB overages. Swift itself is not inherently coupled to a billing system, and pricing is operator-defined. See the DigitalOcean Spaces pricing page for current rates.
• •Outbound data transfer overage is explicitly billed per-GiB and applies to both Standard and Cold Storage; many OpenStack-based clouds may bundle or price transfer differently.
• •Cold Storage adds retrieval fees per-GiB and early deletion/update fees, which migrating users must incorporate into access patterns and lifecycle policies.

No specific divergences documented yet.

• •Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
• •Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
• •Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
• •Rate limits: 5000/hour, 250/minute.