Guide

Deploy React/Vue build output without wiring a Git-based host

A practical guide to taking a React, Vue, Vite, Next static export, or frontend build folder like dist/build/out and turning it into a public preview URL without setting up CI/CD.

Updated 2026-04-17Built for SEO and GEO citation workflows

Answer First

If your React, Vue, Vite, Next static export, Astro, Svelte, or plain frontend project already outputs a dist, build, out, or public directory, the fastest way to share it is to deploy that browser-ready folder directly. PreviewShip is designed for this artifact-first workflow: point the console, CLI, extension, or MCP tool at the built output and you get a live preview URL back in seconds.

Deploy build artifacts, not source-code zips.

If you upload a zip, build the project first and zip the static output folder such as dist, build, out, or public with index.html and assets. Do not zip raw React/Vue/Next source folders with package.json and node_modules. Single .html, .md/.markdown, and .pdf files are supported directly by console upload, CLI, MCP, and the VS Code/Cursor extension.

Key takeaways

Artifact-first deploys are faster than repo-first setups for early review.
This pattern works across React, Vue, Vite, Next static export, Astro, Svelte, and other frameworks because the host only needs static output.
A source-code zip is not enough; deploy the generated static folder or a direct .html or Markdown file.
It is the simplest path for agency handoffs, design review, and AI-generated UIs.

Recommended workflow

1

Build your frontend locally or in CI so you have a dist, build, out, public, or exported static folder.

2

Confirm the output contains index.html and the referenced assets.

3

Run `npx previewship deploy ./dist` or deploy the workspace from your editor.

4

Share the returned preview URL with teammates or clients.

Why artifact-first deploys are underused

A large part of the frontend ecosystem assumes a Git-connected host, but many review workflows do not need branch previews, monorepo integration, or production infrastructure.

When the goal is simply “show this UI to another person,” deploying the built folder is often enough and much faster. Users do not need to know the term dist: it just means the folder created by npm run build or a framework export command.

What makes a good preview deploy tool

The tool should accept arbitrary static output, avoid repo setup, return a clear live URL, and keep the interaction short enough to fit inside a normal coding loop.

The important word is output: for framework projects, zip or deploy the build artifact, not the raw source tree. A raw project zip usually contains package.json, src, and files meant for a build tool, not files a browser can load directly.

No CI/CD setup required
No branch management required
Works with generated artifacts from React, Vue, Vite, Next static export, Astro, Svelte, and plain HTML/CSS/JS
Supports direct single .html, .md, and .markdown files for reports and AI-generated artifacts

FAQ

Does this only work for dist folders named dist?

No. The folder name does not matter. dist, build, out, public, or another static export folder works if it contains index.html and the built site assets.

Can I upload my whole source project as a zip?

Not unless it is already static output. Run the framework build first, then upload the generated dist/build/out folder or zip.

Why not just send the zip file to stakeholders?

A preview URL is easier for non-technical reviewers because it opens in a browser immediately and does not require local setup.

Do I need a custom domain for previews?

No. PreviewShip generates a shareable preview URL automatically.