{"id":516,"date":"2026-09-29T15:32:58","date_gmt":"2026-09-29T22:32:58","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/aspire\/?p=516"},"modified":"2026-09-30T10:30:20","modified_gmt":"2026-09-30T17:30:20","slug":"whats-new-aspire-13-6","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/aspire\/whats-new-aspire-13-6\/","title":{"rendered":"Aspire 13.6: Your dashboard gets memory"},"content":{"rendered":"

Aspire 13.6 is out today, and it includes potentially the longest awaited Aspire feature ever… persistent dashboard data<\/a>! The Aspire Dashboard now keeps your runs around so you can still see traces and logs after you’ve restarted your full stack. That alone would make this a stellar release, but 13.6 also lets you interact with any container shell from the dashboard, brings Java and Rust hosting into the first-party lineup, and previews a brand-new Azure deployment target.<\/p>\n

As usual, these are some of my favorites, but the complete inventory, migration notes, and breaking changes are detailed in the aspire.dev What’s New<\/a>.<\/p>\n

Get Aspire 13.6<\/a><\/div><\/p>\n

\ud83d\uddc4\ufe0f Your dashboard remembers<\/h2>\n

Finally!!! The dashboard now automatically stores resource snapshots and telemetry after you stop the apphost. When you start the apphost again, the dashboard starts a fresh “run”, and you can quickly swap between live and past sessions with the run selector.<\/p>\n

\"The<\/p>\n

Filtering, search, paging, and aggregation all work on historical runs, so investigating an old run still gives you all the power of the dashboard. Historical runs are read-only, so you can poke around without worrying about changing anything. The runs are stored on disk as SQLite databases, so you can point your coding agent at them to compare and contrast between runs, too.<\/p>\n

The dashboard keeps up to 10 runs per application and prunes the oldest ones as new runs start. If a run captured something you want to hang onto, like the one time you actually reproduced a tricky bug, pin it in the run selector to retain it.<\/p>\n

Running the standalone dashboard<\/a> without an apphost? Give it a stable application name and opt into Resume<\/strong> so the same run survives restarts:<\/p>\n

aspire dashboard run --application-name my-app --persistence Resume<\/code><\/pre>\n
We also raised the default limits for console logs, structured logs, and traces to 100,000 entries each, so a busy run holds a lot more before the oldest entries roll off.<\/p>\n
<\/i>Protect your telemetry<\/strong><\/p>Persisted telemetry can contain sensitive values, and the underlying on-disk database has no separate encryption or authorization layer. The dashboard is still a development and short-term diagnostics tool, not a production telemetry backend.<\/div><\/p>\n
Learn more about dashboard data persistence<\/a>.<\/p>\n
\u2328\ufe0f Exec against your containers from the dashboard<\/h2>\n
When I want to check what’s actually installed on a container image, I usually drop into my container runtime of choice, find the tab that gives me a terminal, and start typing. If I want to do anything more complicated, like manually clear my cache, I have to copy-paste passwords or the connection string and hope I grabbed the right one.<\/p>\n
In 13.6, we created the WithRepl()<\/code> extension for common container-based integrations:<\/p>\n
\n
\n
\n