Prior to v1, Evervault Enclaves were referred to as Evervault Cages. The rollout of our v1 of Enclaves requires some migration for existing Cages customers.
As part of the release of Enclaves, we have removed support for Global API Keys in favour of Scoped API Keys. If you are still using a Global API Key in your Client or CI, you will need to replace it with a Scoped API Key. You can create a Scoped API Key from the App Settings Page in the Evervault Dashboard.
From v1, the installed CLI is named
ev-enclave. You can install the new CLI with the following command:
Once you have the latest CLI installed, you can migrate the Cage.toml files of your pre-existing Cages using the following command:
If you have been using the
ev-cage CLI in CI, you will need to update your CI tasks to use the new
ev-enclave CLI. To do this, you can update the install step to use the new path:
Any commands should be updated to use
ev-enclave in place of
Any commands which use the
--desired_replicas flag will need to be updated to use
If your in Enclave process consumes the
x-evervault-cage-ctx header sent from the data plane, you will need to update this to use the new standardized header:
x-evervault-ctx. This header is now shared across Relay and Enclaves, and transaction IDs will be concatenated to build a trace.
To migrate to the new Enclaves runtime, you'll need to deploy your image using the new Enclave CLI:
If you are using an Evervault SDK when invoking your Enclave, you will need to update the SDK to the latest version, and use the new enclave functions in place of the deprecated Cage functions.
If you are using your own client, or making network requests directly to the Enclave, you will need to update the hostname from
<YOUR CAGE NAME>.<YOUR APP ID>.cage.evervault.com to
<YOUR CAGE NAME>.<YOUR APP ID>.enclave.evervault.com.