This project uses Azure Table Storage as the default persistence layer in all environments, including local development.
For local development, we standardize on Azurite, which emulates Azure Storage locally so you can run the real persistence path without needing an Azure subscription or live storage account.
- Docker Desktop or another Docker-compatible runtime with
docker compose - .NET SDK
From the repository root, start the checked-in Azurite service:
docker compose -f compose.azurite.yml up -dOn macOS or Linux:
docker compose -f compose.azurite.yml up -dAzurite exposes the default local Azure Storage ports:
- Blob:
10000 - Queue:
10001 - Table:
10002
The emulator data is stored in .azurite/, which is git-ignored.
The Functions app is already configured to use Azurite by default through:
{
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true"
}
}That means the default repository path stays on Azure Table Storage locally, with no extra connection string needed as long as Azurite is running on its standard ports.
With Azurite running, you can start the solution normally. The backend will create the configured redirects table automatically on first use.
The local web UI is served from:
/ui
The root path / redirects to /ui, while alias lookups still use /{alias}.
If you want to use the Functions app directly:
cd src/UrlRedirect.Functions
func startOn macOS or Linux:
cd src/UrlRedirect.Functions
func startThe Azure Table integration tests use Azurite as well, so keep the emulator running and then execute:
dotnet test src/UrlRedirect.sln /p:RestoreIgnoreFailedSources=trueOn macOS or Linux:
dotnet test src/UrlRedirect.sln /p:RestoreIgnoreFailedSources=trueIf Azurite is not running, the integration test class skips itself with a message telling you how to start the emulator.
docker compose -f compose.azurite.yml downOn macOS or Linux:
docker compose -f compose.azurite.yml down