How do I share an Astro build without deploying?

Run `astro build`, then drag `dist/` into Comma. `index.html` becomes the report body and the `_astro/` bundles, images and fonts upload alongside it with references rewritten — a preview URL with no host and no deploy.

Why does opening dist/index.html directly render unstyled?

Astro emits absolute asset paths under `/_astro/`, which resolve against the filesystem root at a `file://` origin rather than against the build folder. Over HTTP with the assets uploaded alongside, the references resolve.

Do client-side islands still hydrate?

Yes. Report HTML renders with scripts enabled inside a sandboxed iframe, so `client:load` and `client:visible` components hydrate as they do locally.

Can I give every PR its own preview link?

Use one report id per branch and PATCH it on each push. Each PR keeps a stable URL that always shows its current build, with previous builds kept as revisions.

Can reviewers comment on the rendered page?

Yes. Anchored threads attach to the rendered content, so design and copy feedback sits on the element instead of arriving as a screenshot with an arrow drawn on it.

Share an Astro build

astro build produces a dist/ folder that is genuinely static — and genuinely awkward to hand to someone. Open dist/index.html from disk and you get unstyled markup, because Astro references its bundles absolutely under /_astro/…, which at a file:// origin resolves against your filesystem root.

The usual answer is astro preview, which helps exactly one person: you.

Build

npm run build          # → dist/

If you deploy under a subpath, set it so the build's references match:

// astro.config.mjs
export default defineConfig({ base: "/docs" });

Publish dist/

Drag dist/ (or a zip of it) into the app:

index.html becomes the report body.
The _astro/ CSS and JS bundles, images and fonts upload as assets, and their references are rewritten to the uploaded copies — which is the step that makes it render at all.
Scripts run inside a sandboxed iframe (allow-scripts, no allow-same-origin), so islands hydrate and view transitions behave.

A shareable preview with no host, no deploy, and no preview environment to tear down afterwards.

One preview per PR

npm run build

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html dist/index.html \
        --arg title "Preview — $GITHUB_HEAD_REF" '{title: $title, html: $html}')"

PATCH the same report id on each push: the PR's preview link never changes, and every build is kept as a revision so "what did it look like before the last commit?" is answerable.

What review adds

Anchored threads on the rendered page — the difference between "the hero spacing is off" and a comment attached to the hero. See commenting on HTML.
Revisions, so applied feedback is verifiable rather than asserted.
Access per report — private, team, domain-gated, or named reviewers, so an unreleased marketing page stays unreleased. See the sharing model.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total. Image-heavy marketing builds are the case to watch — publish the page under review rather than the whole site.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a site preview →