How to publish a Vite build for team review
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:
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 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:
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 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. The publishing docs cover the upload, CLI and API options when the review workflow becomes routine.