Secrets
Including secrets in your deployment
This plugin manages secrets on Shuttle.
Usage
Add a Secrets.toml
to the crate root or workspace root of your Shuttle service with the secrets you’d like to store.
Make sure to add Secrets*.toml
to a .gitignore
to omit your secrets from version control.
The format of the Secrets.toml file is a key-value mapping with string values.
Next, pass #[shuttle_runtime::Secrets] secrets: shuttle_runtime::SecretStore
as an argument to your shuttle_runtime::main
function.
SecretStore::get
can now be called to retrieve your API keys and other secrets at runtime.
Local secrets
When developing locally with shuttle run
, you can use a different set of secrets by adding a Secrets.dev.toml
file.
If you don’t have a Secrets.dev.toml
file, Secrets.toml
will be used locally as well as for deployments.
If you want to have both secret files with some of the same secrets for both local runs and deployments, you have to duplicate the secret across both files.
Different secrets file
You can also use other secrets files (in TOML format) by using the --secrets [file]
argument on the run
and deploy
commands.
When deploying with the --secrets
arg, that file is renamed to Secrets.toml
before being packed and sent to Shuttle. Therefore, it has to be in the same folder that a normal Secrets.toml
file would have been placed.
Example
This snippet shows a Shuttle rocket main function that uses the shuttle_runtime::Secrets
attribute to gain access to a SecretStore
.
The full example can be found on GitHub
Deleting secrets
This command will delete all secrets from your project.
Re-deploy with an updated Secrets.toml
to add them back.
Caveats
- Some libraries read from their own config files or environment variables,
with no way of providing them in code. Sometimes, this can be solved by
manually setting the variable after loading the secret (and before loading the library):
std::env::set_var("SOME_ENV_VAR", my_secret);
Was this page helpful?