A Compute instance is a virtual machine running on Quake AI. It gives you isolated CPU, memory, disk, and network resources inside a project. You manage instances through the console, CLI, or API. Documentation and OpenStack APIs sometimes still call them "servers" for historical reasons; on Quake AI the service-accurate term is instance.

You assemble five inputs: an image (operating system), a flavor (vCPU, RAM, and root disk shape), a network to attach to, a key pair for SSH access, and a security group that controls inbound traffic. Optionally. You can pass user data for first-boot configuration via cloud-init. The platform combines those inputs into a running instance.

Yes. Apps (Compute > Apps in the Console) deploys a fully configured instance from a curated catalog: pre-built image, auto-allocated floating IP, security group with the ports the application needs, and an SSH key pair if you do not already have one. The current catalog includes OpenClaw (an open-source AI agent framework). Apps creates standard Compute objects, so after deploy you manage the instance the same way you would any other VM.

Compute on Quake AI is backed by OpenStack Nova, the standard open-source compute service. Choosing Nova means the APIs, CLI commands, and Terraform resources you learn are portable to any OpenStack cloud. For the full mapping between Quake AI service names and OpenStack project names, see How Quake AI uses OpenStack.

A flavor is a named combination of vCPUs, RAM, root disk size, and optional ephemeral or swap storage. You pick a flavor when you create or resize an instance. Other clouds call this an instance type (AWS), machine type (GCP), VM size (Azure), server type (Hetzner), or plan (DigitalOcean). On Quake AI, flavors are predefined; you cannot create a custom flavor.

• General Purpose (m2a.*): balanced vCPU-to-memory ratio. Web servers, small databases, dev environments.
• Compute Optimized (c2a.*): higher vCPU count relative to memory. Batch processing, CI/CD runners, CPU-bound apps.
• Memory Optimized (r2a.*): more RAM per vCPU. In-memory caches, analytics engines, large databases.
• Shared Resources (s1a.*): cost-effective shared vCPUs. Lightweight workloads, testing, personal projects.

Start slightly above your baseline; resize is supported but requires a brief restart.

Each migration guide ships a full mapping table between the source provider's instance types and Quake AI flavor families, organized by RAM-to-vCPU ratio:

• AWS EC2: see Migrate from EC2: Flavor mapping
• DigitalOcean Droplets: see Migrate from Droplets: Flavor mapping
• GCP Compute Engine: see Migrate from GCE
• Azure Virtual Machines: see Migrate from Azure VMs
• Hetzner Cloud Servers: see Migrate from Hetzner Servers

Yes. Resize moves the instance to a different flavor; this requires a brief restart. Plan to choose slightly above your baseline so you avoid frequent resizes while keeping costs reasonable.

No. The Quake AI flavor catalog (m2a.*, c2a.*, r2a.*, s1a.*) provides CPU-backed compute. For language model inference up to roughly 7–8 billion parameters, an m2a.xlarge or similar general-purpose flavor runs Ollama on CPU. For workloads that need GPU-accelerated inference (larger models, higher throughput, lower latency), run on hardware outside Quake AI or use a managed inference provider.

Every Quake AI flavor (every m2a.*, c2a.*, r2a.*, and s1a.* size) has disk: 0. The platform rejects any image-backed openstack server create that does not also specify a block-storage boot volume. Run the create with --boot-from-volume N (where N is the boot disk size in GiB):

openstack server create \
  --flavor c2a.large \
  --image Ubuntu-24.04 \
  --boot-from-volume 10 \
  --network PublicEphemeral \
  --key-name MY_KEY \
  --security-group default \
  MY_INSTANCE_NAME

Verify the disk attribute with openstack flavor show c2a.large -f value -c disk; every flavor on the platform returns 0.

The Console Create Instance wizard sets a boot volume size for you in the Base Config tab. Terraform and OpenTofu providers handle it through a block_device block on openstack_compute_instance_v2; the platform's IaC templates already include it.

The boot volume that --boot-from-volume allocates does not auto-delete when you delete the server. See "Why does my project still have a 10 GiB Cinder volume after I deleted my instance?" below for the cleanup step.

An image is a reusable template, typically an OS plus optional applications and settings, used as the disk content for new instances. A snapshot captures the state of a running instance and stores it as a new image. So every snapshot is an image, but not every image is a snapshot. You launch instances from either.

Yes. You upload a QCOW2 image to the Image service (OpenStack Glance) through the console, CLI, or API. Image signing and verification help you trust that an image has not been tampered with between upload and deploy. Linux images work best when they ship cloud-init, which applies network settings, users, packages, and SSH keys from metadata at first boot.

It depends on the source:

• AWS: supported via VM Import/Export to S3, then convert to QCOW2 with qemu-img convert. Worth doing only for custom AMIs with significant baked-in software. Marketplace, Windows/SQL Server, and encrypted EBS images cannot be exported.
• GCP: best path of any provider; native QCOW2 export with no conversion step.
• Azure: VHD export via SAS URL, then conversion to QCOW2.
• DigitalOcean: not supported. DO does not provide an API or UI for downloading Droplet snapshots; rebuild and rsync is faster and more reliable.

For most workloads on every source, rebuild and rsync is the recommended path: provision a fresh Nova instance from a Quake AI public image, install your stack with your existing configuration management, and transfer data with rsync.

You connect with the private half of the key pair you selected at launch, against the instance's floating IP, using the default SSH user for your image:

If SSH fails, work through Instance connectivity troubleshooting. It eliminates the most likely causes (missing floating IP, security group rule, wrong key, wrong user) in order.

Floating IPs are not auto-assigned. Allocate one from the external network and associate it with the instance:

openstack floating ip create PublicStatic
openstack server add floating ip YOUR_INSTANCE_NAME YOUR_FLOATING_IP

If you used the Apps deploy flow, a floating IP is allocated automatically.

None. Security groups default to deny inbound, allow outbound. To allow SSH, HTTPS, or any other inbound protocol, add an explicit ingress rule with the protocol, port, and remote CIDR. The same model holds whether you came from AWS, GCP, or Azure; the API surface is OpenStack Neutron rather than EC2's AuthorizeSecurityGroupIngress.

Yes. You can either generate a new key pair in the console (download the private half once and store it safely) or import a public key you already use. Importing is the common path so the same key works across environments.

The fastest path is the lifecycle runbook, which covers all three common failures:

• Stuck in BUILD: likely scheduler, messaging, volume, or network setup timeout. Wait five minutes; check openstack server show YOUR_INSTANCE -c fault; check quota with openstack quota show.
• Moves to ERROR: read the fault field; common causes are scheduler placement failure (no host with capacity), Block Storage timeout, port binding failure, or repeated build retries.
• Quota exceeded (HTTP 403, "Quota exceeded for resources: …"), your project quota is exhausted. Free capacity or request an increase.

openstack server create --boot-from-volume N allocates a Cinder volume from the image with delete_on_termination=false. The volume persists after openstack server delete; the delete does not cascade. Each create-instance run that uses --boot-from-volume without deleting the volume leaves an orphan boot volume against your project's volume quota.

Find and delete an orphan after a server teardown:

# Detached volumes show 'available' status; the orphan matches the size you passed to --boot-from-volume
openstack volume list --status available

# Delete by ID
openstack volume delete VOLUME_ID

To opt into cascade-delete behavior at create time, use the more verbose --block-device flag with delete_on_termination=true:

openstack server create \
  --flavor c2a.large \
  --image Ubuntu-24.04 \
  --block-device source_type=image,uuid=IMAGE_UUID,destination_type=volume,volume_size=10,boot_index=0,delete_on_termination=true \
  --network PublicEphemeral \
  --key-name MY_KEY \
  MY_INSTANCE_NAME

The Console Create Instance wizard's Deleted with the instance checkbox sets the same flag. Terraform and OpenTofu templates configure it on the block_device block (delete_on_termination = true).

Take a snapshot before a risky change: an OS upgrade, a major application deployment, or a configuration overhaul. Snapshots are also useful as cloning tools: launch multiple instances from the same snapshot to create identical environments for testing, staging, or horizontal scaling. Snapshots are immutable once created.

• Instance snapshot: full VM state including the root disk; stored as a new image.
• Volume snapshot: point-in-time copy of an individual storage volume; depends on the original volume.
• Volume clone: a new identical volume you can attach to another instance immediately.

Choose instance snapshots for full machine images. Choose volume snapshots or clones to protect data on specific attached disks independently of the instance.

Boot-from-volume instances store the root disk on Cinder, not on the Glance image record. openstack server image create snapshots the instance into Glance, but that image can report size=0 and openstack image save may write an empty qcow2 even when the command exits successfully.

For offsite backup, export through a volume snapshot instead: snapshot the boot volume, run openstack image create --volume VOLUME_SNAPSHOT_ID, and verify the new image reports non-zero size before openstack image save. The backup-and-restore how-to documents the volume-snapshot export path and cross-project image sharing.

To keep an application available during a host failure, run redundant instances and route traffic through a health-checked external edge or self-managed reverse proxy. A common Quake AI pattern is:

1. Run application replicas on 2+ instances inside an anti-affinity server group so the scheduler places members on different physical hosts.
2. Put an external CDN, WAF, or self-managed reverse-proxy tier in front, with health checks that stop routing to failed backends.
3. Associate floating IPs with the public instances or proxy nodes.
4. Pair regular volume snapshots with application-level replication (PostgreSQL streaming, MySQL binary log, etc.) for data durability.

No. Server group policies are immutable. To apply a different policy, create a new group and launch new instances into it.

For most workloads, rebuild and rsync beats image export on time:

1. Provision a fresh Nova instance from a Quake AI public image (Ubuntu, Debian, Rocky Linux).
2. Install your application stack with your existing configuration management (Ansible, cloud-init, shell scripts).
3. Transfer application data and databases with rsync or standard dump/restore tools.

For containerized workloads, push images to a portable registry (or your private one), provision Nova instances, install the container runtime, and deploy. This path stays the same regardless of source provider.

Image export is reserved for the narrow case of a custom image with significant baked-in software that would take longer to rebuild than to export, convert, and upload.

A Compute instance, backed by OpenStack Nova. The lifecycle operations (launch, stop, start, resize, snapshot, destroy) are equivalent. The differences worth knowing before you migrate:

• Pricing model: fixed monthly pricing tied to your resource tier, not per-second metering or Spot.
• Sizing model: a curated flavor catalog, not hundreds of instance types.
• Networking: Neutron's network/subnet/router model, not VPC + Internet Gateway + NAT Gateway.
• Identity: project-scoped application credentials with three roles (admin, member, reader); no IAM-style policy language.

For a service-by-service mapping table tailored to your source provider, see the relevant "Coming from" page: AWS, DigitalOcean, GCP, Azure, Hetzner.

No. Quake AI uses fixed monthly pricing tied to your resource tier; there is no per-second meter and no Spot market. Capacity planning maps to flavor + quota, not to a long instance-type catalog with spot-vs-on-demand variants.

Hetzner Cloud Servers. The Hetzner migration guide notes Hetzner is "the closest operational model to Quake AI of any provider": curated server-type catalog, fixed monthly pricing, simple networking primitives. DigitalOcean is the next-closest. AWS, GCP, and Azure all involve more concept translation (instance types vs. flavors, IAM policies vs. application credentials, VPC vs. Neutron, etc.).

Compute runs in all three Quake AI regions: us-east-1, us-east-2, and us-west-1. Each region is an independent failure domain with its own console URL, API endpoints, and resource pool, and there is no automatic cross-region replication. Quake AI uses regions, not availability zones; placement diversity within a region is expressed through server groups with an anti-affinity policy, which forces the scheduler to place members on different physical hosts. See Regions for the current region table and console URLs.

The contractual availability target and credit schedule are published as part of Quake AI's commercial terms at rumble.cloud/legal. The Service Level Agreement page explains how to read those terms and how to file a credit claim. The SLA defines what gets credited; your application's availability depends on how you architect across instances and regions. The high availability concept page translates each "nines" target into annual downtime and describes server groups, floating IPs, external edges, and self-managed reverse proxies.

For most problems, start with the relevant runbook:

• Instance connectivity troubleshooting: SSH timeouts, refused connections, unreachable floating IPs.
• Instance lifecycle troubleshooting: stuck in BUILD, ERROR state, quota exceeded.

If the runbook does not resolve the issue, open a support ticket and bring the evidence listed in Support ticket evidence collection: project ID, region, instance UUID, the exact command or API call that failed and its full output, and the UTC time window of the incident. Get help is the canonical decision tree for picking the right starting point based on the symptom.