Coming from DigitalOcean
Coming from another cloud?
▸DigitalOcean·Droplets, Spaces, Kubernetes, Volumes, VPC (VPC Network), Load Balancer, Floating IP
Droplets
- 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.
Volumes
- 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.
VPC (VPC Network)
- 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 ().
Coming from DigitalOcean
If you have been using DigitalOcean, here is how Quake AI maps to what you run today. Quake AI maps compute, storage, networking, and Kubernetes to OpenStack-backed services with fixed monthly pricing on infrastructure. Quake AI runs on OpenStack: the services below expose standard OpenStack APIs with upstream documentation. Managed application services are where the platforms diverge most.
Quick reference#
| DigitalOcean | Quake AI | OpenStack project | Key difference |
|---|---|---|---|
| Droplet | Instance | Nova | Flavors vs fixed Droplet sizes; more granular options |
| Spaces | Container | Swift | Same S3 API pattern; endpoint change |
| Managed Kubernetes (DOKS) | Kubernetes Cluster | Magnum | DOKS auto-scales nodes and manages upgrades; Magnum workers are self-managed Nova instances |
| Volume | Volume | Cinder | Same attach model; NVMe at all tiers |
| VPC | Network | Neutron | More flexible subnet-router model |
| Cloud Firewall | Security Group | Neutron | Applied per-instance, not per-network |
| Load Balancer | Self-managed edge proxy or API gateway | Nova + Neutron | Run Caddy, SafeLine, or APISIX on a VM with a floating IP |
| Reserved IP | Floating IP | Neutron | Same concept, different API |
| App Platform | No equivalent | - | Deploy on VMs or Kubernetes |
| Managed Database | No equivalent | - | Self-managed on VMs |
Compute: droplets → Nova instances#
What maps directly: You still pick an image, a size, a region, SSH keys, and optional volumes. Virtual machines are owned by OpenStack Nova, the same Compute service pattern you already use when you think in terms of Droplets.
What is different: DigitalOcean publishes fixed Droplet plans (s-1vcpu-1gb, and similar) with per-second billing capped at a monthly maximum. Quake AI exposes flavors (for example, m2a.large for 2 vCPU and 8 GiB RAM on a general-purpose shape) with fixed monthly pricing per resource tier: there is no per-second meter. Families and sizes span general-purpose, compute-optimized, memory-optimized, and burstable tiers; see Flavors. Quotas still bind what you can run in a project.
CLI: Where you run doctl compute droplet create, you use the OpenStack client against Nova:
openstack server create \
--flavor m2a.large \
--image "Ubuntu 24.04" \
--network PublicEphemeral \
--key-name MY_KEY \
my-serverFor the full workflow, see Create an instance. For workload migration steps, see Migrate from Droplets.
Object storage: Spaces → Swift (S3-compatible)#
What maps directly: Both products expose an S3-compatible API: endpoint URL, access key, secret key, buckets (Quake AI calls them containers), and object keys. Object storage on Quake AI is backed by OpenStack Swift with an S3 gateway, so boto3, aws-cli, rclone, and s3cmd behave the same once you retarget the endpoint.
What is different: DigitalOcean Spaces uses region hostnames such as nyc3.digitaloceanspaces.com. Quake AI uses object.us-east-2.rumble.cloud. You change the endpoint (and credentials) in your config; application code that already abstracts the endpoint carries over.
import boto3
client = boto3.client(
"s3",
endpoint_url="https://object.us-east-2.rumble.cloud",
aws_access_key_id="ACCESS_KEY_ID",
aws_secret_access_key="SECRET_ACCESS_KEY",
region_name="REGION",
)
client.list_buckets()Read Object storage and Migrate from DigitalOcean Spaces for compatibility detail and cutover steps.
Kubernetes: DOKS → Magnum#
What maps directly: You still get a Kubernetes API, worker nodes, and cluster-scoped resources. Clusters are provisioned through OpenStack Magnum, which selects a cluster template the way DOKS selects a version and node pool profile.
Kubernetes Services with type: LoadBalancer keep the same workload-facing contract after migration. The cluster provisions the public endpoint without exposing a tenant-managed load balancer service.
What is different: DOKS manages node pools, offers auto-scaling options, and keeps the control plane fully hands-off. Magnum gives you a managed control plane from the template, but worker nodes are Nova instances you size, patch, and scale. Built-in node auto-scaling in the same shape as DOKS is not available.
Operations: You plan capacity, upgrades, and add-ons the way you would on self-managed nodes, with OpenStack and Kubernetes APIs both in play. Cluster operations and templates are covered in Kubernetes. For cluster migration steps, see Migrate from DOKS.
Block storage: volumes with Cinder#
What maps directly: You create a volume, attach it to one instance, format it, mount it, snapshot, and detach. Block storage is OpenStack Cinder: the attach lifecycle matches DigitalOcean Block Storage closely enough that runbooks port with API swaps.
What is different: Quake AI backs Cinder volumes with NVMe at every tier; you do not pick separate performance SKUs for baseline block storage the way some clouds segment tiers. Capacity and attachment limits still apply per project and flavor.
See Create a volume.
Networking: VPC → Neutron networks#
What maps directly: You still place instances on private address space, route traffic, and attach public addresses where needed. Networking is OpenStack Neutron.
What is different: A DigitalOcean VPC is a flat private network with a small configuration surface. On Quake AI you compose networks, subnets, routers, and floating IPs as separate Neutron objects. The model is more flexible: you decide how internal and external connectivity attach instead of inheriting a single VPC abstraction.
See Networks for topology and terminology. For network migration steps, see Migrate from DigitalOcean VPC.
Security: Cloud Firewall → Neutron security groups#
What maps directly: You still express allow rules for TCP/UDP/ICMP by port and source, default-deny inbound, and allow outbound. Neutron security groups implement the same pattern as Cloud Firewalls.
What is different: DigitalOcean often associates firewalls with Droplets via tags or explicit attachment in the control plane. Quake AI applies security groups per instance or per port in Neutron: the binding is to compute ports, not to a VPC-wide firewall object. When you migrate, you recreate the same port and CIDR matrix under new group IDs.
Follow Create a security group.
Load balancing: DigitalOcean Load Balancer to a self-managed edge#
DigitalOcean Load Balancer concepts still apply at the application edge: terminate TLS, define backends, and health-check them. On Quake AI, run an edge reverse proxy, edge WAF, or API gateway on a VM with a floating IP.
Translate listeners into proxy routes, target pools into backend lists, and health monitors into application health checks. Caddy handles automatic HTTPS, SafeLine adds request filtering, and APISIX adds API routing and rate limits.
Floating IPs: Reserved IPs → Neutron floating IPs#
What maps directly: DigitalOcean Reserved IPs (formerly Floating IPs) and Quake AI floating IPs are the same idea: a stable public IP you detach from one instance and attach to another. Neutron owns the floating IP object and associates it with a fixed internal address on a port.
What is different: The API and Console paths are OpenStack, not doctl compute floating-ip. You allocate a floating IP, associate it with a server port, and reassociate during failover the same way you would in a DO reserved-IP cutover.
App Platform: no direct equivalent#
DigitalOcean App Platform builds, deploys, and scales applications from a repo or container image without you managing the underlying VMs. Quake AI does not offer a comparable PaaS: you run workloads on Nova instances, Kubernetes (Magnum), or both, and you bring your own CI/CD, container registry, and process manager. Start from automation templates or your existing Docker and Kubernetes manifests when you need a structured baseline.
Managed Database: no direct equivalent#
DigitalOcean Managed Databases provision PostgreSQL, MySQL, MongoDB, Valkey, Kafka, and OpenSearch with backups, failover, and operator dashboards. Quake AI does not provide a first-party managed database: you run the engine on a VM or on Kubernetes, configure backups, and monitor it yourself. Use automation templates for repeatable database setups.
Self-managed services and deployment patterns#
Quake AI provides infrastructure primitives: compute, networking, storage, Kubernetes, and automation. Application-level managed services are not part of the platform. You compose your own stack from these primitives, using the same open-source tools you already know.
| DigitalOcean service | Status on Quake AI | Alternative |
|---|---|---|
| App Platform | Not available | Deploy on VMs with Docker or Kubernetes |
| Managed Database | Not available | Self-managed on VMs (templates) |
| Managed Valkey (formerly Managed Redis) | Not available | Self-managed Valkey on a VM |
| Functions (serverless) | Not available | Containers on VMs or Kubernetes |
| Monitoring / alerts | Not available | Self-managed Prometheus + Grafana |
| Managed CDN (Spaces CDN) | Not available | Cloudflare or self-managed caching |
Platform differences#
- Outbound transfer: DigitalOcean includes a monthly outbound transfer allowance that varies by Droplet size and bills overage beyond it (see DigitalOcean pricing). Quake AI includes outbound transfer in plan pricing, so there is no separate egress line item to model.
- Fixed networking pricing: Floating IPs and core networking objects are included in plan pricing instead of metered as separate hourly SKUs on top of Droplets.
- OpenStack portability: Public APIs use standard OpenStack projects including Nova, Neutron, Cinder, Swift, Magnum, and Keystone. The same toolchains and resource types transfer to other OpenStack clouds.
- Infrastructure as code: OpenTofu (or Terraform) with the
openstackprovider maps to Nova, Neutron, and the rest of the stack.
Next steps#
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.
Last validated: 22.06.2026