The person who needs your dashboard usually has no seat in your BI tool — and buying one is the wrong fix. How to ship a live, interactive dashboard to a no-login viewer, and where a live connection beats a snapshot.
The dashboard is done. The board member, the client's CFO, the partner team lead — they ask to see it. You open the share menu, and the first thing your BI tool offers is "add a user."
That's where it stalls. They have no seat. Buying one means a paid invite, an account they'll use once, an entry in your next access review, and a name to remember to deactivate. For a person who needs to look at one dashboard for two weeks, you are standing up a membership to grant a glance.
The seat is the wrong unit. What the viewer needs is the chart. What the seat gives them is the chart plus an identity inside your tooling — and that bundle is what's expensive, not the looking.
Per-seat pricing was designed around people who live in the tool. It prices the analyst correctly and the occasional viewer terribly, because most BI platforms don't cleanly separate a read-only viewer from a full editor — and the ones that do often park viewer access behind a higher plan tier. So the board member who opens the dashboard once a quarter lands in the same cost bucket as the analyst who builds in it daily.
Then there's everything a login drags along. An account is a credential you now manage. It's a row in the access review when security asks "who can see the revenue dashboard." It's an offboarding step when the engagement ends and you have to remember to revoke. None of that is the dashboard — it's the membership the dashboard tool insisted on.
For an external or occasional viewer, you want the inverse: give them the view, give them nothing else, and have the access end cleanly without a deprovisioning chore.
Most dashboards that get shared aren't live products. They're a finished view — this quarter's numbers, this analysis, this set of questions — built for an audience that will read it across a known window and then stop.
That view exports. Most tools have a path to a single self-contained HTML file: Plotly's fig.write_html(), a static export from Metabase or Observable, a deck built from a notebook. The result is one file with the charts, the data, and the JavaScript all inlined — it runs in any browser with no server behind it.
Host that file at a private link and the no-login problem dissolves. The viewer clicks a URL and sees the dashboard. Filters work. Dropdowns work. Hover tooltips explain the methodology. They explore it themselves — not a recording of you exploring it — and they never create an account, because there's nothing to log into. The URL is the access.
Export the dashboard view to a self-contained HTML file, drop it on miinideck, and you get an unguessable, noindex-by-default private link. The viewer opens it in their browser with no seat and no sign-in — and you didn't provision anything you'll have to revoke later.
No login is not no control. It's a different control, and for a snapshot dashboard it's usually the better-fitting one.
The link itself is the gate: long, random, unguessable, and noindex by default — it won't surface in search and can't be found by poking at URLs. For most internal and client dashboards that's the right level. When the numbers are sensitive, you stack two cheap factors on top:
Expiry quietly solves the offboarding problem a seat creates. There's no account to deactivate; the access ends on a date you set. And it solves a second, subtler issue: a dashboard is a snapshot of a moment. Q3 numbers read in October are useful; the same link found in February, still resolving, looks current and misleads. An expiry tied to the engagement keeps the snapshot from outliving its accuracy. When a self-destruct date helps versus hurts is worth a deliberate choice, covered here.
You can also see who looked. A private-link host can give you open-tracking on the link — opens and timing — without the viewer needing an identity in your BI tool. You get the "did the CFO actually open it" signal without the seat that signal usually requires.
A private link ships a snapshot. The data is frozen at export time. The viewer explores that frozen view as much as they want — but they can't pull fresh rows from your warehouse, because there's no warehouse behind the file.
That's exactly right for a finished analysis read by a defined audience. It's the wrong tool when:
Those cases need a real backend: a server, a live database connection, and yes, a login — because now the login is doing genuine work, gating which live data each person sees. That's a deployed app. Your BI platform's own hosted sharing handles it, or you stand it up on Vercel or Netlify with auth in front. Don't fake a live dashboard with a static file; when the job needs a server, use one.
The two aren't competitors — they're different jobs. Live deployment owns the always-current, per-user, product-grade dashboard. The private-link snapshot owns the finished view that a specific audience needs to read and poke at, without anyone provisioning a seat to do it. Most dashboards that get shared — as opposed to operated — are the second kind.
Your dashboard is done and someone with no seat needs to see it. Skip the invite. Export the view to self-contained HTML, drop it at a private link, and send the URL. Add a password if the numbers are sensitive, an expiry if the window is bounded. The viewer opens it, explores the live charts, and never logs into anything you'll have to clean up later.
You shared the dashboard. You didn't hand out a membership to do it.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
How analysts, consultants, and agency teams hand a finished HTML report to one named client — what each channel is built for, and where private-link hosting fits.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.