# 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](https://www.exoscale.com/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.