Coming from Azure

If you have been using Microsoft Azure, here is how Quake AI maps to what you run today. Quake AI maps compute, storage, networking, and identity 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 services and the enterprise identity model are where the platforms diverge most.

Quick reference#

Compute: Azure virtual machines → instances#

What maps directly: You still pick an image, a VM size, SSH keys (or password), and disks. Instances are backed by OpenStack Nova.

What is different: Azure publishes VM series (B-series burstable, D-series general purpose, E-series memory-optimized, and many more) with pay-as-you-go, reserved instances, and spot pricing. Quake AI exposes flavors (for example, m2a.large for 2 vCPU and 8 GiB RAM on a general-purpose shape) with fixed monthly pricing. No spot market, burstable credit system, or reserved instance contracts exist. Each flavor lists a single monthly price. See Flavors for the full catalog.

openstack server create \
  --flavor m2a.large \
  --image "Ubuntu 24.04" \
  --network PublicEphemeral \
  --key-name "MY_SSH_KEY_NAME" \
  "MY_INSTANCE_NAME"

For the full workflow, see Create an instance. For workload migration steps, see Migrate from Azure VMs.

Object storage: Azure blob storage → containers (Swift, s3-compatible)#

What maps directly: You store objects in containers, use blob names as keys, and interact with an API. Object storage is backed by OpenStack Swift.

What is different: Azure Blob Storage uses access tiers (Hot, Cool, Cold, Archive, and Smart) with billing and retrieval characteristics that vary by tier. Only the Archive tier is offline and requires rehydration (up to 15 hours) before objects can be read; Hot, Cool, and Cold are online tiers with immediate retrieval. Quake AI exposes a single storage tier with an S3-compatible endpoint. No tier management, no rehydration delays.

Terminology note: Both Azure and Quake AI use the word "container" for storage groupings. Azure containers are the Blob Storage grouping unit. Quake AI containers are the Swift/S3 bucket equivalent. The concept is the same.

See Object storage and Migrate from Azure Blob Storage for compatibility detail and cutover steps.

Networking: Azure virtual networks → Neutron networks#

What maps directly: You define virtual networks with subnets, attach VMs, and control traffic with security rules. The Network service is OpenStack Neutron.

What is different: Azure VNets use address spaces with subnets, route tables, and optional VNet peering. NSGs can bind to subnets or individual NICs. On Quake AI, you create a network, attach a subnet, and connect it to a router. Security groups bind to ports (per-instance). No route tables need managing for basic internet access; routers attach directly to the external network.

See Networks for the topology. For network migration steps, see Migrate from Azure VNet.

Security: Azure network security groups → Neutron security groups#

What maps directly: You express allow/deny rules by protocol, port, source, and destination. Both platforms default to deny-inbound.

What is different: Azure NSGs support both allow and deny rules with explicit priority ordering, and can bind to an entire subnet or a single NIC. Neutron security groups are allow-only (deny is implicit), have no priority ordering, and bind per port. If you relied on Azure deny rules or subnet-level NSGs, rethink the security model for per-instance allow-only groups.

Follow Create a security group.

Block storage: Azure managed disks → Cinder volumes#

What maps directly: You create a disk, attach it to one VM, format, mount, snapshot, and detach. Block storage is OpenStack Cinder.

What is different: Azure offers Premium SSD, Standard SSD, Standard HDD, and Ultra Disk with provisioned IOPS. Quake AI exposes Cinder volumes backed by NVMe with no separate IOPS tiers.

See Create a volume.

Kubernetes: from AKS to Magnum#

What maps directly: You get a Kubernetes API, worker nodes, and cluster-scoped resources. Clusters are provisioned through OpenStack Magnum.

What is different: AKS manages node pools, offers cluster auto-scaler, KEDA-based scaling, and Azure-specific integrations (Entra ID for RBAC, Azure CNI, Azure Disk CSI). AKS node auto-provisioning (NAP, GA 2025) dynamically creates node pools based on pod resource requests; Magnum has no equivalent. Magnum gives you a managed control plane from a cluster template, but worker nodes are Nova instances you size, patch, and scale. Built-in node auto-scaling in the same shape as AKS is not available.

Cluster operations and templates are covered in Kubernetes. For cluster migration steps, see Migrate from AKS.

Automation: from ARM templates and Bicep to OpenTofu#

What maps directly: You still declare infrastructure as code and deploy it as atomic units.

What is different: Azure uses ARM templates (JSON) or Bicep (DSL that compiles to ARM) with the Azure Resource Manager. On Quake AI, OpenTofu (or Terraform) with the openstack provider is the usual path for new projects. Heat stacks are also available for OpenStack-native templates. ARM and Bicep do not translate to OpenTofu; you rewrite resources using the openstack provider types.

Get started with Infrastructure as Code with OpenTofu.

Identity: from Entra ID to application credentials#

What maps directly: You still authenticate users, rotate credentials, and scope access to resources.

What is different: Microsoft Entra ID (formerly Azure Active Directory) is an organization-wide directory with RBAC, ABAC, conditional access policies, service principals, and managed identities. Quake AI uses project-scoped application credentials with three roles: admin, member, and reader. No directory service, conditional access, or managed identity equivalent exists. You isolate workloads by creating separate projects instead of writing detailed role assignments.

Generate credentials in the Console: Generate application credentials.

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.

Platform differences#

• Outbound transfer: Azure bills for per-GB data egress with rates that vary by region and volume tier (see the Azure bandwidth pricing page). Quake AI includes outbound transfer in plan pricing, so there is no separate egress line item to model.
• Fixed monthly pricing: Compute is billed per flavor per month rather than pay-as-you-go, reserved instance, or spot models. Core networking objects such as networks, routers, floating IPs, and security groups are included in plan pricing instead of metered as separate hourly line items.
• Flat authorization: Three project-scoped roles (admin, member, reader) replace Entra ID's layered RBAC/ABAC hierarchy. This is less granular than Entra ID; you compensate with project-level isolation.
• Flat resource namespace: Resources live in a project without Resource Group nesting. No Resource Group naming conventions, lifecycle policies, or tagging strategies are required for isolation.
• OpenStack portability: Public APIs use standard OpenStack projects including Nova, Neutron, Cinder, Swift, Magnum, and Keystone. The same toolchains transfer to other OpenStack clouds.

Next steps#

• Quickstart
• Migrate from Azure Blob Storage
• Infrastructure as Code with OpenTofu
• How Quake AI uses OpenStack