Azure Storage Emulator doesn't start in Aspire 13.4 with persistent container lifetime

[sander1095]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When installing Aspire 13.4 and using Azure Storage Emulator with a persistent lifetime, the storage resource never starts.

The same code DOES work in previous versions of Aspire.

Expected Behavior

Storage starts

Steps To Reproduce

aspire new aspire-empty --language csharp
aspire add azure-storage

Replace apphost code with this:

#:package Aspire.Hosting.Azure.Storage@13.4.0
#:sdk Aspire.AppHost.Sdk@13.4.0

var builder = DistributedApplication.CreateBuilder(args);

var storage = builder
    .AddAzureStorage("storage")
    .RunAsEmulator(azurite =>
        azurite
            .WithLifetime(ContainerLifetime.Persistent)
    );

builder.Build().Run();

Call aspire start, the storage resource never comes online

Do the same in aspire 13.3, and it does work

Exceptions (if any)

No response

Aspire doctor output

Aspire Environment Check

Aspire
✅ Aspire CLI version 13.4.0 (channel: stable)

Container Runtime
✅ Docker v28.3.2: running (auto-detected (default)) ← active

Environment
✅ HTTPS development certificate is trusted
⚠️ HTTPS development certificate has an older version (v4)
Run 'aspire certs clean' to remove all certificates, then run 'aspire certs trust' to create and trust a new one.
See: https://aka.ms/aspire-prerequisites#dev-certs
Details:
Older certificate versions (< v4) may not support all certificate trust scenarios.

Summary: 3 passed, 1 warnings, 0 failed
For detailed prerequisites: https://aka.ms/aspire-prerequisites

Aspire CLI Installations

╭─────────────────────────────────────────────────┬─────────────────────────────────────────────────┬─────────┬───────────┬─────────────╮
│ Path │ Version │ Channel │ Route │ PATH status │
├─────────────────────────────────────────────────┼─────────────────────────────────────────────────┼─────────┼───────────┼─────────────┤
│ C:\Users\stenb.aspire\bin\aspire.exe (current) │ 13.4.0+becb48e2d61099e35ae336d527d3875e928d6594 │ stable │ (unknown) │ active │
╰─────────────────────────────────────────────────┴─────────────────────────────────────────────────┴─────────┴───────────┴─────────────╯

Anything else?

Might be related to #17822

[joperezr]

🤖 Aspire triage pass — 2026-06-02 08:52 UTC

Area: area-integrations
Kind: regression
Repro: yes-minimal — see steps in issue body (AppHost code provided, ~10 lines)
Affected version(s): 13.4.0 (last working: 13.3.x per reporter; latest: 13.4.0)
Severity: S2 — core scenario (Azure Storage emulator with persistent container lifetime) broken with no obvious workaround other than dropping .WithLifetime(ContainerLifetime.Persistent)

Urgency: 🔴 servicing — recommend milestone 13.4.x
Reason: Reporter states the same code worked in 13.3 and is broken on 13.4.0. Strong corroborating signal: sibling issue #17822 (Redis ContainerLifetime.Persistent broken on 13.4) is already milestoned to 13.4.x and labeled ‼️regression-from-last-release. Both reports point at the same persistent-container-lifetime code path regressing in 13.4.

Suggested owner(s): @danegsta (score 3), backup @eerhardt (score 1)
Evidence:

• @danegsta merged Add persistent executable and project lifetimes #17112 ("Add persistent executable and project lifetimes") on 2026-05-20 — likely the regressing change in the persistent-lifetime code path, and the closest recent author on this surface
• CODEOWNERS lists @eerhardt (with @mitchdenny) for /src/Aspire.Hosting.Azure* — appropriate Azure-integration backup owner
• No recent merged PRs found under label:area-integrations Storage in the last 90d (so weighting leans on the regressing PR + CODEOWNERS)

Confidence: medium — regression baseline is reporter-asserted ("works in 13.3") rather than independently verified by the bot, but the sibling issue #17822 in the same release with the same symptom (persistent lifetime broken on 13.4) substantially raises confidence that this is a real 13.4 regression.
Needs human?: yes — 13.4.x recommendation requires human confirmation (servicing regression)

Dry-run mode — no labels or milestone applied. Reply /triage apply to
promote, or edit and reapply.

[afscrome]

Could be related to #17822

[mangeg]

It starts if you manually set all the 3 ports. Downside that it has fixed ports and don't work with --isolated and so on.

var storage = builder
    .AddAzureStorage("storage")
    .RunAsEmulator(azurite =>
        azurite
            .WithLifetime(ContainerLifetime.Persistent)
            .WithBlobPort(10000)
            .WithQueuePort(10001)
            .WithTablePort(10002)
    );

[willdean]

We have a Postgres server configured like this

var postgres = builder.AddPostgres("postgres")
    .WithLifetime(ContainerLifetime.Persistent)
    .WithDataVolume(isReadOnly: false);

Which also appears to have failed on upgrade to 13.4 - is this related?

[pfo-omicsstudio]

Same with Redis - doesn't start either. Probably related to whatever caused this.

var cache = builder
    .AddRedis("cache")
    .WithDataVolume("redis-data")
    .WithLifetime(ContainerLifetime.Persistent)
    .WithRedisInsight();

[devsko]

The same with MySql - it starts but never gets healthy because of a Timeout-Exception.
But MSSQL is working with ContainerLifetime.Persistent.

[maddymontaquila]

Hey folks!! @danegsta just merged the fix #17859 and we are spinning a build right now. will have this serviced today. Adding some new tests to cover this as well. Will update this comment when the service release is out!

[maddymontaquila]

Temp workaround till we get the release out - either assign public ports like @mangeg shows above or turn the proxy for the container back on. We started running proxyless by default in this release. Sorry for the break everyone!