Run Azure Storage Locally

Provisioning a Storage Account

This guide shows you how to provision a Storage Account against Locally, and then write and read a blob in it. As with the other guides we're going to use the Azure CLI, but the same resource can be provisioned with HashiCorp Terraform, Pulumi or Bicep too.

Before you start

The Azure CLI (az) installed.
Locally installed, with Locally Setup completed.

Plugin required

This requires the Microsoft.Storage plugin, which you can install with:


        
            
                $
            

            
            locally plugin install --name Microsoft.Storage

1. Start Locally

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


        
            
                $
            

            
            locally build

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 Storage Account:


        
            
                $
            

            
            locally run az group create -n sample-resources -l berlin

There's two things to note here:

The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
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 Storage Account

With the Resource Group in place, we can create the Storage Account:


        
            
                $
            

            
            locally run az storage account create --name samplestorage1 --resource-group sample-resources --location berlin --sku Standard_LRS

Note

Storage Account names are globally unique in Azure, and must be lowercase alphanumeric between 3 and 24 characters. Locally keeps the same rules, so a name that works here works in Azure too.

The response includes the endpoints for each of the storage services:

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

  "name": "samplestorage1",
  "primaryEndpoints": {
    "blob": "https://samplestorage1.blob.core.storage.locally:5660/",
    "dfs": "https://samplestorage1.dfs.core.storage.locally:5660/",
    "file": "https://samplestorage1.file.core.storage.locally:5660/",
    "queue": "https://samplestorage1.queue.core.storage.locally:5660/",
    "table": "https://samplestorage1.table.core.storage.locally:5660/",
    "web": "https://samplestorage1.web.core.storage.locally:5660/"
  },
  "provisioningState": "Succeeded",
  "type": "Microsoft.Storage/storageAccounts"
}

Those storage.locally hostnames are served by Locally's own DNS server and point at the Storage Emulator running on your machine.

4. Create a container

Blobs live in a container, and Locally has a built-in command for creating one:


        
            
                $
            

            
            locally storage container create --account samplestorage1 --name files

Container "files" created in account "samplestorage1".

Note

locally storage is part of Locally itself, so it doesn't take the locally run prefix. Every az command does.

If you'd rather use the Azure CLI, az storage container create works too, once it has the account's connection string from the next step.

5. Upload and download a blob

The locally storage commands manage containers, queues, shares and tables, but not the blobs inside them, so for those we'll use the Azure CLI. Like the Azure SDKs, it needs the account's connection string. locally storage connection-string prints it, and putting it in AZURE_STORAGE_CONNECTION_STRING means the az storage commands below pick it up automatically:


        
            
                $
            

            
            export AZURE_STORAGE_CONNECTION_STRING=$(locally storage connection-string --account samplestorage1)

The connection string looks like the Azure one, pointed at your machine:

DefaultEndpointsProtocol=https;AccountName=samplestorage1;AccountKey=...;BlobEndpoint=https://samplestorage1.blob.core.storage.locally:5660/;FileEndpoint=https://samplestorage1.file.core.storage.locally:5660/;QueueEndpoint=https://samplestorage1.queue.core.storage.locally:5660/;TableEndpoint=https://samplestorage1.table.core.storage.locally:5660/

Now create a small file and upload it to the container:


        
            
                $
            

            
            echo 'hello from Locally' > hello.txt


        
            
                $
            

            
            locally run az storage blob upload --container-name files --name hello.txt --file hello.txt

We can confirm it's there:


        
            
                $
            

            
            locally run az storage blob list --container-name files --query "[].{Name:name, Size:properties.contentLength}" -o table

Name       Size
---------  ------
hello.txt  19

And read it back out again:


        
            
                $
            

            
            locally run az storage blob download --container-name files --name hello.txt --file downloaded.txt


        
            
                $
            

            
            cat downloaded.txt

hello from Locally

Note

You can also browse containers, blobs, queues, shares and tables visually in the Locally Dashboard - open the Storage Account's resource page and use the dropdown to jump into the emulator for the service you're working with.

We can see the Storage Account in the Locally Dashboard too:

6. Tidy up

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


        
            
                $
            

            
            locally run az group delete -n sample-resources --yes

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, Storage Accounts work the same way through any of the tooling that Locally supports - a Microsoft.Storage/storageAccounts 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: hand the connection string above to the Azure SDK for .NET, Go or Python and your application reads and writes blobs against Locally.

Next steps

To use queues in a Storage Account, see Storage Queues. Every Function App keeps its state in a Storage Account too.

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

Provisioning a Storage Account

Provisioning a Storage Account

Before you start

1. Start Locally

2. Create a Resource Group

3. Create the Storage Account

4. Create a container

5. Upload and download a blob

6. Tidy up

Doing this with other tooling

Next steps

A local cloud for you and your AI agents.