# How to publish a Vite build for team review

Share the compiled frontend, keep its assets intact, enable SPA fallback when needed, and check external API access.

Source: https://staging.publidock.com/blog/publish-a-vite-build-for-review

Published: 2026-10-09
Topic: Guides

Your Vite app runs on your laptop, but the rest of the team cannot open your `localhost` address. To share a browser-based prototype through Publidock, build it and publish the output files.

You are sharing the compiled frontend. Publidock does not install the project's dependencies or run a development server, API server or database.

## Build the files you will actually share

For a project with Vite's usual build and preview scripts, run:

```sh
npm run build
npm run preview
```

The default output directory is `dist`, although a project can configure another location. The preview command helps you inspect that build locally. Check the compiled app, rather than relying only on the development server; build-time paths and environment values can behave differently.

The [Vite static deployment guide](https://vite.dev/guide/static-deploy.html) explains the build output and local preview. Your project may have different scripts, so check its `package.json` before using these commands.

## Upload the output directory

Publish `dist` as a folder, or ZIP its contents with `index.html` and the generated assets together. A typical output looks like this:

```text
dist/
  index.html
  assets/
    app.js
    app.css
```

Use the output from your project; generated asset names often include hashes. Upload the complete build, not just `index.html`, and keep its paths intact. The source folder, `node_modules` and development configuration are not the files a viewer's browser needs.

A Publidock site is served from its own origin. If the project was previously built for a subpath such as `/demo/`, review Vite's `base` setting before publishing at the site's root. When assets fail to load, inspect the requested paths and compare them with the uploaded file tree.

The [missing images and CSS guide](/blog/fix-missing-images-and-css-in-html-uploads) gives a troubleshooting sequence for failed asset requests and path mismatches.

## Make direct route links work

For a single-page app using browser routes, the first visit to `/settings` needs to load the frontend entry page. Enable **SPA fallback** in the Publidock site's settings, then test a direct URL to one of the app's routes and refresh the browser there.

Clicking from the homepage to a route only tests client-side navigation. A teammate opening the route from a message makes a new request to the host. That is the case SPA fallback handles.

If the app uses hash routes or separate HTML pages, its routing needs may differ. Test the actual addresses you plan to send.

## Check external services and the audience

A static frontend can call an external API, but that service must accept requests from the published origin and enforce its own authentication. Check allowed origins, redirects and browser API credentials at the service that provides them.

Never put a private server key in the frontend build. Browser JavaScript and embedded configuration can be read by people who can access the app. A build-time environment variable does not make a value secret once it has been compiled into the files.

Publidock's site rule controls who can open the prototype. New sites start with link sharing. In the browser flow, inspect the preview and choose the intended audience before **Go Live**; for an automated upload that publishes immediately, configure that audience before uploading confidential material. Company-domain and named-people sharing depend on the plan. The external backend must also authorize its requests; access to the frontend is not a substitute for those checks.

## Publish revisions to the existing site

After changing the prototype, make a fresh build and publish the complete output as a new version of the same site. Its URL and sharing rule remain in place. Check the live version, including a direct route, before asking the team to review it.

For a wider overview of browser-only prototypes and their limits, read [Share a vibe-coded prototype with your team](/blog/share-a-vibe-coded-prototype). The [publishing docs](/docs) cover the upload, CLI and API options when the review workflow becomes routine.