# Coming from DigitalOcean

Source: https://docs.quake.ai/docs/platform/migration/coming-from-digitalocean
Markdown: https://docs.quake.ai/docs/platform/migration/coming-from-digitalocean.md

---

# 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](/docs/platform/migration/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](https://docs.openstack.org/nova/latest/), 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](/docs/compute/concepts/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:

```bash
openstack server create \
  --flavor m2a.large \
  --image "Ubuntu 24.04" \
  --network PublicEphemeral \
  --key-name MY_KEY \
  my-server
```

For the full workflow, see [Create an instance](/docs/compute/how-to/create-instance). For workload migration steps, see [Migrate from Droplets](/docs/compute/migration/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](https://docs.openstack.org/swift/latest/) 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.

```python
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()
```


  Replace `ACCESS_KEY_ID`, `SECRET_ACCESS_KEY`, and `REGION` with values from your Quake AI object storage credentials. The hostname is the contract: if it still points at DigitalOcean, authentication and routing fail even when the code is otherwise correct.


Read [Object storage](/docs/object) and [Migrate from DigitalOcean Spaces](/docs/object/migration/migrate-from-digitalocean) 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](https://docs.openstack.org/magnum/latest/), 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](/docs/kubernetes). For cluster migration steps, see [Migrate from DOKS](/docs/kubernetes/migration/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](https://docs.openstack.org/cinder/latest/): 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](/docs/block/how-to/create-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](https://docs.openstack.org/neutron/latest/).

**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](/docs/network/concepts/networks) for topology and terminology. For network migration steps, see [Migrate from DigitalOcean VPC](/docs/network/migration/migrate-from-do-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](/docs/network/how-to/create-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](/build/iac-templates/edge-reverse-proxy), [edge WAF](/build/iac-templates/edge-waf), or [API gateway](/build/iac-templates/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.

See [Allocate floating IPs](/docs/network/how-to/allocate-floating-ips).

## 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](/build/iac-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](/build/iac-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](/build/iac-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](https://www.digitalocean.com/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 [`openstack` provider](https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs) maps to Nova, Neutron, and the rest of the stack.


  When you cut over object storage or DNS, work through the linked how-tos so credentials, endpoints, and TTLs land in the right order.


## Next steps

- [Quickstart](/docs/quickstart)
- [Resource tiers](/docs/platform/account/resource-tiers): Developer Plan details
- [Migrate from DigitalOcean Spaces](/docs/object/migration/migrate-from-digitalocean)
- [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac)
- [How Quake AI uses OpenStack](/docs/platform/migration/openstack)


  See the [full DigitalOcean migration guide](/docs/platform/migration/from-digitalocean) for a service-by-service migration journey.