The dashboard file

A published Dashies dashboard is one HTML file. Not a project, not a bundle, not a set of assets. One file, served whole.

That is what makes it cheap to view, cheap to store, and possible for an AI to write in the first place. It is also why the rest of the product is shaped the way it is: every constraint elsewhere in Dashies comes from the fact that the finished artifact is a single self-contained document.

The three things inside it

Dashies is deliberately incurious about most of the file. You can put anything in it: your own markup, your own CSS, your own copy, a logo, a footnote. Three things are structural, and everything else is yours.

1. Slots, marked with data-dash

Any element opts into the runtime by carrying a data-dash attribute naming its role, plus role-specific attributes saying what it reads.

<span data-dash="metric" data-measure="revenue" data-format="currency">-</span>

That element is a slot. It contains a placeholder dash until the runtime fills it with a number. Elements without a data-dash attribute are ignored entirely: the runtime fills only matched slots and appends one stylesheet, and it never replaces the page.

The roles cover KPIs, charts, tables, matrices, heatmaps, scatter plots, treemaps, waterfalls, funnels, drill-downs, stacked and combo charts, pies, gauges, and filters.

2. The data island

Exactly one element, found by its id:

<script type="application/json" id="dashies-data">
{ "version": 4, "updated_at": "2026-08-05T09:00:00Z", "datasets": { } }
</script>

This holds the numbers. It must be valid JSON, and the id dashies-data is reserved: the compiler refuses a dashboard that uses it anywhere else, because every consumer finds the island by first match and a decoy would make the scheduler rewrite the wrong element forever.

The data island covers what is in it and why it is the only thing a refresh touches.

3. The runtime marker

An empty script element:

<script data-dashies-runtime></script>

The code that draws the charts is not in the published file. This marker is where it goes, and it is filled at serve time rather than at publish time. See The runtime.

What is not in the file

• Credentials. The file never carries a connection string, a password, or a token. It carries results, not access.
• Your SQL. The query lives in a refresh manifest stored alongside the dashboard, not in the served bytes.
• The runtime. As above.

What a viewer's browser can and cannot do

Every served dashboard runs in a sandbox on an opaque origin. Its scripts run, so charts and filters and interactivity all work. What it cannot do:

• read or write localStorage, sessionStorage, cookies, or IndexedDB
• make a same-origin authenticated request
• read anything belonging to the Dashies web app

This is not a limitation that was tolerated; it is the isolation that makes it safe to serve arbitrary author-written HTML from the same domain as a signed-in application. Without it, a published dashboard could read a viewer's session.

The practical consequence for an author: everything on screen must come from data already inside the file. A dashboard cannot fetch something when a viewer opens it. Filter state is the exception, and it lives in the URL hash, so a filtered view is a shareable link that survives a reload.

Where the file lives

At https://<handle>.dashies.xyz/<slug> for a personal dashboard, or https://<workspace-slug>.dashies.xyz/<slug> for a workspace one. Renaming a dashboard leaves the old URL working: it becomes an alias that redirects to the new one.

Next

The data island is the part that changes.