A sandbox preview link is bound to a live session and a project you keep open. A private link is a finished artifact. Here's exactly when the preview stops being the right thing to send — and what to send instead.
There's a quiet category error in how a sandbox preview link gets used. The link is a window into a live workspace — and we keep sending it as if it were a finished file. Most of the time that's fine. Sometimes it bites, usually a day or two after you've stopped thinking about it, when the recipient pings you with "the link is broken" and you have no idea why — because nothing broke on your screen. The project rebuilt on theirs, and rebuilt differently.
This post is about that gap. Not "which tool is better" — CodeSandbox and StackBlitz are excellent at the thing they're built for. It's about the single property that decides whether a preview link is the right thing to send: is it bound to a session, or is it a standalone artifact?
When you share a CodeSandbox or StackBlitz preview, you're not sharing a page. You're sharing an instruction: open this project and build it.
That instruction runs every time someone clicks. The platform spins up a container, reads your current source, installs dependencies, compiles, and renders the result. It's genuinely impressive engineering — a full dev environment materializing in a browser tab. But it means the preview is a function of live state, not a snapshot. Three things follow from that, and all three are invisible until they're not:
None of this is a flaw. It's the whole point of a sandbox: the preview is the project, alive. The mismatch only appears when you treat that living thing as a frozen deliverable.
Forget feature tables. The honest way to decide is to watch for these signals. Any one of them means the session-bound link has stopped being the right object to send.
1. You're done editing and you want it to stay done. The work is finished. You don't want a future you — or a future dependency update — to change what the recipient sees. The instant "stop touching it" becomes a requirement, you want a snapshot, not a live build.
2. The recipient is non-technical. A client, a stakeholder, a marketing lead. They open a sandbox preview and, even in preview-only mode, something feels like a tool rather than a thing. You want them looking at the running page on a clean URL — not at anything that hints there's a build system behind it.
3. "The link is broken" is now a support cost. If you've explained a cold start or a rebuild error more than once, the preview is leaking your time. A pre-built copy can't cold-start, because there's nothing to build — it's already compiled.
4. You need privacy, a password, or an expiry. A sandbox is built around shareable, forkable workspaces — great for collaboration, not the shape of "only these three people, and only until Friday." When the requirement is who can see this and for how long, you're asking for delivery controls a workspace isn't designed to give.
5. It needs to outlive the project. Six months from now, will that sandbox still exist, still be public, still build against the same dependency versions? If the link has to survive longer than your attention to the project, it can't depend on the project.
It's smaller than it sounds. You're not migrating anything. You're taking a photograph of the finished result and sending the photograph instead of a key to the darkroom.
Concretely: run your build (npm run build, or whatever your framework calls it). That produces a static output folder — dist, build, out — containing the compiled, runnable version of your app: HTML, bundled JS, CSS, assets. That folder is self-contained. It doesn't need the sandbox, doesn't need a rebuild, doesn't need npm. Drop it — as a single HTML file or a ZIP — onto a host, and you get one private URL that loads the same way for everyone, with no editor in sight.
That's the whole move. A sandbox is a workshop; the export is the object you made in it. You keep the workshop. You just stop mailing people the workshop when they asked for the object.
This is exactly the seam miinideck sits in. You drop the build, you get an unguessable link that's private and no-index by default — the viewer needs no account, sees no platform chrome, no rebuild. Add a password if it's sensitive, an expiry if it's time-boxed, or a link that never expires if it's a permanent reference. The patterns are the same whether your project came from Bolt, Replit, v0, Lovable, Codex, or a Cursor build — see the general share a vibe-coded app and host an AI artifact guides.
There's a real limit here, and pretending otherwise would cost you. A static export is exactly that — static. If your app needs a server it talks to, a database, secret API keys, server-side rendering at request time, or anything that runs backend code, exporting the front end gives you a beautiful page that can't reach its data.
That's not a miinideck job. If your project has a live backend, the right move is a platform built to run it — Vercel or Netlify will deploy your full app, server functions and all, and give you a real production URL. A static host owns the slice where the deliverable is a self-contained front end: a finished UI, a calculator, a dashboard you want kept private, a client-proofing page, a prototype that runs entirely in the browser. For those, you don't need a server, and a private link is the cleaner answer.
So the decision tree is short:
The sandbox preview was never meant to be the final delivery format. It's a window into work in progress — perfect for that, and only that. When the work stops being in progress, the link should stop being a session and start being an object. That's the whole call.
A Loom or screenshot shows the reviewer your build. A live private link lets them click through it themselves. Here's exactly what each format loses in transit — and when a recording is still the right call.
GitHub Pages publishes a public, git-tracked site to the open web. A private unguessable link delivers a self-contained page to specific people. Here is the honest split — by who reaches it, what the URL is for, and where the work lives — so you pick the right one instead of bending one to fit.
A private link and a public deploy are the two ends of one dial: how findable the page should be. A job-by-job map of where each endpoint fits, plus the in-between cases most real work actually lands in.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.