Overview

Exoscale Compute Instances are high-performance, KVM-based virtual machines designed to support a wide range of workloads—from small-scale applications to complex, distributed systems. They offer rapid provisioning, flexible scaling, and seamless integration with DevOps tools like Terraform, Ansible, and Kubernetes.

Encryption at Rest

Exoscale encrypts Compute root volumes and Block Storage volumes at rest transparently at the hypervisor layer. You do not need to change your workflow, install agents in your guest operating system, or manage any keys yourself — volumes are encrypted by default and encryption cannot be disabled.

This page explains what is encrypted, how the encryption is performed, how keys are managed today, and what is changing next with the upcoming Exoscale KMS integration.

How it works

Exoscale uses AES-256 in XTS mode to encrypt volume data.

Instance local storage is encrypted with unique key material per volume. Encryption keys gets destroyed when the volume is deleted.

Block storage volumes receive unique encryption keys at volume creation. Encryption keys follow the lineage of the volume: snapshots inherit encryption keys of the underlying volume, and volumes promoted from snapshots inherit encryption keys of the underlying snapshot.

Encryption and decryption happen transparently: compute instances’ operating system sees a normal block device. Your operating system, filesystem, applications, and tooling do not need to be aware that the underlying volume is encrypted.

The encryption key for a volume is only ever present in clear-text in the memory of the hypervisor that is actively running the workload attached to that volume. When the instance is stopped or migrated away, its encryption key get removed from the hypervisor.

When creating instances from custom templates, encryption is performed transparently on the hypervisor at template fetch time. This encryption step leads to instance creation timings being higher than bare template download timings.

What is covered

Compute root volumes

Every new Compute instance is provisioned on top of an encrypted root volume by default.

Block Storage volumes

Every new Block Storage volume is encrypted by default.

Block Storage snapshots

Snapshots of Block Storage volumes inherit the encryption of their parent volume and remain encrypted throughout their lifetime. When a snapshot is promoted to a new Block Storage volume, the promoted volume is encrypted with the same key as the source snapshot and its parent volume.

Instance snapshots and templates on Object Storage

Instance snapshots and templates are stored on Exoscale Object Storage with bucket-level encryption, so the data remains encrypted on the underlying storage media.

Key management today

Exoscale manages encryption keys on your behalf. Each volume key is generated randomly on creation and securely stored encrypted.

Key material is never exposed to customers and its lifecycle is fully managed by Exoscale.

Rollout

Encryption at rest is being rolled out progressively:

• New workloads are always encrypted. Every new Compute instance created boots from an encrypted root volume, and every new Block Storage volume created is encrypted at creation time.
• Existing instances will remain for the time being unencrypted. In the near future we will properly communicate how unencrypted instances can be encrypted.
• Existing Block Storage volumes are not re-encrypted in place. In-place re-encryption of attached block devices carries real corruption risk, so existing unencrypted Block Storage volumes will remain as they are. If you need your existing Block Storage data to be encrypted at rest, the recommended path is to create a new Block Storage volume (which will be encrypted) and copy your data across.

Terminology

Understanding the basic terms used in Exoscale Compute will help you get up and running quickly.

Instance

A Compute Instance is a virtual machine (VM) running in the Exoscale cloud. It behaves like a traditional server but is virtualized and runs on shared physical infrastructure. Instances are fully self-contained environments and can run various operating systems (Linux, Windows, custom ISOs).

Instance Type

The Instance Type defines the resource configuration of your VM — such as number of vCPUs, amount of RAM, and local SSD storage. Exoscale offers different instance families optimized for CPU, memory, storage, or GPU workloads.

Instance Family	Use Case	RAM Range	CPU Cores	Local Storage	Availability
Standard	General-purpose workloads	512MB - 225GB	1 - 24	10GB - 1.6TB	All zones
CPU Optimized	Compute-intensive applications	16GB - 128GB	8 - 40	10GB - 1.6TB	All zones
Memory Optimized	RAM-intensive applications	16GB - 128GB	2 - 12	10GB - 1.6TB	All zones
Storage Optimized	Data-heavy workloads	16GB - 128GB	4 - 16	1TB - 10TB	All zones

Template

A Template is a pre-configured disk image used to launch instances. Templates define the base OS and system configuration. You can use public templates provided by Exoscale or upload your own.

Features

Rapid Deployment

Launch virtual machines within seconds through the Exoscale Portal, CLI, or API.

Flexible Instance Types

Choose from various instance families tailored to specific workloads.

Local SSD Storage

All instances come with enterprise-grade local SSD RAID10 storage, ensuring high I/O performance and low latency.

Custom Templates & Snapshots

Create and deploy instances using custom templates and take snapshots for backups or cloning purposes.

Anti-Affinity Groups

Distribute instances across different physical hypervisors to enhance availability.

vTPM and Secureboot

Enhance instance security with vTPM for TPM 2.0 support, enabling Windows Bitlocker encryption, and Secure Boot to ensure only signed OS images are loaded.

Encryption at Rest

Root volumes are transparently encrypted with AES-256 in XTS mode, with unique key per volume. Encryption cannot be disabled.

Built-In IAM

Granular Identity and Access Management allows precise control over API key permissions.

Instance Pools

Automatically manage groups of identical instances for high availability and scalability.