Provisioning a Key Vault

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group to hold the Key Vault:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the Key Vault

With the Resource Group in place, we can create the Key Vault itself:

The interesting part of the response is the vaultUri, which is the address the data plane lives at:

{
  "note": "some fields skipped for brevity",

  "name": "samplevault1",
  "properties": {
    "provisioningState": "Succeeded",
    "vaultUri": "https://samplevault1.vault.locally:5661/"
  },
  "type": "Microsoft.KeyVault/vaults"
}

That vault.locally hostname is served by Locally's own DNS server and points at the Key Vault Emulator running on your machine. Tools run through locally run reach it as they would Azure, and apps built on the Azure SDKs need a few lines of setup.

We can retrieve the vault again at any point with:

Which gives us:

{
  "location": "berlin",
  "name": "samplevault1",
  "sku": "standard",
  "vaultUri": "https://samplevault1.vault.locally:5661/"
}

4. Use the data plane

So far we've only used the control plane - creating the vault itself. The more useful part is the data plane, where the secrets live.

We can store a secret with:

Which returns the secret along with its generated version:

{
  "note": "some fields skipped for brevity",

  "id": "https://samplevault1.vault.locally:5661/secrets/database-password/352b7b47-2eb0-449c-9c5e-6992c03eb3a1",
  "name": "database-password",
  "value": "correct-horse-battery-staple"
}

And read it back:

Which prints just the value, ready to be used in a script:

correct-horse-battery-staple

To see everything stored in the vault:

Name               Enabled
-----------------  ---------
database-password  True

We can see the Key Vault in the Locally Dashboard too:

5. Tidy up

Finally, we can tidy up. To remove the Resource Group and everything within it:

As in Azure, deleting a Key Vault soft-deletes it rather than removing it outright, so the name samplevault1 stays reserved. To free it up for next time, purge it:

There's nothing billable to clean up, since everything ran on your machine, but it's still worth checking your teardown scripts work here before you run them against Azure.

Doing this with other tooling

Whilst this guide used the Azure CLI, Key Vaults work the same way through any of the tooling that Locally supports - a Microsoft.KeyVault/vaults resource in HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template all provision against Locally in the same way, with only the location changed.

The same is true of the data plane: point the Azure SDK for .NET, Go or Python at the vaultUri above and your application reads secrets from Locally.

Next steps

To work with keys and certificates in the same vault, see Key Vault Keys & Certificates. To read a secret from an app with no credentials, see Managed Identity.

Should you encounter any issues, please take a look at the troubleshooting section.