How to Share a Vite Dev Server for Team and Client Reviews

Your Vite dev server is running. HMR is fast, vite.config.ts is dialed in, and the new dashboard component renders the way you want. But the person who needs to review it is in a different time zone, on a different machine, and your dev server lives at localhost:5173.

Vite gives you two local commands: vite dev and vite preview. Neither was built for external sharing. This tutorial walks through the difference, the gap, and how to close it.

Vite Dev Server vs Vite Preview

Vite ships with two commands that serve your project locally. They do different things, and knowing which one to reach for matters when you are sharing work in progress.

vite dev

This is the command you run all day. It starts the Vite dev server with hot module replacement, native ES module serving, and instant startup. Source files are served unbundled. Every change you save reflects in the browser in milliseconds. Your vite.config.ts defines custom plugins, aliases, proxy targets, and any middleware you have wired up.

vite dev

The dev server is fast. It’s also localhost-only. Nobody outside your machine can reach it.

vite preview

This command serves a production-like build locally. You run vite build first to generate the optimized output, then vite preview to serve it. The preview server respects your preview options in vite.config.ts: host, port, strict port, and open behavior.

vite build && vite preview

The production build is bundled, minified, and tree-shaken. It loads faster than the dev build and catches issues the dev server hides, like chunking errors or missing asset paths. But it’s still localhost-only. Nobody outside your machine can reach it either.

The Gap

Both commands serve on localhost. That’s the correct default for development. But when a teammate asks for a review link, or a client wants to click through a prototype, localhost won’t work. Your options:

1. Deploy to staging: costs a CI run and however many minutes your pipeline takes.
2. Screen share: costs the reviewer their independence, they watch you click but cannot explore.
3. Create a temporary public URL for your dev server: the shortest path between your Vite project and their browser.

Sharing Your Vite Dev Server

Creating a temporary public URL for a local dev server isn’t new. Tools like ngrok have existed for years. They give you a public endpoint that tunnels traffic to your machine.

The limitation of basic tunneling tools is visibility. They route traffic. They don’t tell you what happened. You send a link, the reviewer opens it, and you have no idea if they saw the new component, hit a broken API route, or never clicked the link.

WireMaven fills that gap. It creates a temporary encrypted public URL for your Vite dev server and adds a floating overlay that shows viewer activity, request outcomes, and failures in real time. You’re not guessing whether the review happened. You’re watching it.

Step-by-Step: Share a Vite Dev Server with WireMaven

WireMaven works with Vite out of the box. It integrates as a Vite plugin and starts alongside your dev server. No account. No configuration. Free during the beta.

1. Install WireMaven as a dev dependency

npm install -D wiremaven

WireMaven is a dev dependency. It doesn’t ship to production. It only lives in your devDependencies, right next to Vite itself.

2. Initialize WireMaven in your project

npx wiremaven init

This command patches your vite.config.ts and package.json. It adds the WireMaven Vite plugin to your plugin array:

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import wiremaven from 'wiremaven/vite'

export default defineConfig({
  plugins: [react(), wiremaven()],
})

And it updates your dev script so WireMaven starts alongside the Vite dev server:

{
  "scripts": {
    "dev": "wiremaven run vite"
  }
}

Your existing Vite config stays intact. Aliases, proxy settings, environment variables, custom middleware: all of it works exactly as it did before. WireMaven doesn’t override your configuration.

3. Start your dev server

npm run dev

Your Vite dev server starts as usual, HMR and all. WireMaven starts alongside it and generates a temporary encrypted public URL. Copy the URL from the terminal output and send it to whoever needs to review your build.

4. Share the link

The reviewer opens the URL in their browser. They see your Vite project exactly as it renders on your machine. They click through pages, test interactions, fill out forms. Everything works because the tunnel routes their requests to your running dev server.

5. Watch the overlay

While the reviewer explores your build, WireMaven shows a floating overlay in your browser:

• Active viewers: who is connected.
• Request count: total requests through the tunnel.
• Error count: failed requests with the endpoint that failed.
• Event log: a timeline of connections, completions, and failures.

When the reviewer hits a broken route, the overlay shows a request-failed event before they type a Slack message. You fix it, save, and Vite HMR updates instantly. Feedback loop closed in seconds.

Sessions auto-expire after 15, 30, or 60 minutes. Set the timer when you start the tunnel. When it expires, the URL stops resolving. No cleanup needed.

Vite Preview vs WireMaven Tunnel

You have three local Vite tools. Each solves a different problem.

vite dev

Serves source files unbundled with HMR. Fastest feedback loop while coding. Localhost only. Use it while you are actively building.

vite preview

Serves a production-optimized build locally. Catches bundling issues, chunk errors, and tree-shaking surprises pre-staging. Localhost only. Use it before committing or pushing.

WireMaven tunnel

Serves your Vite dev server (or preview server) at a temporary public URL with session visibility. Remote accessible. Use it when someone else needs to see your build.

These tools are complementary. A typical Vite workflow:

1. vite dev all day while coding.
2. When a teammate asks for a review, keep vite dev running and start the WireMaven tunnel. Share the link.
3. Before pushing, run vite build && vite preview to verify production output locally.
4. If preview needs a client sign-off, run wiremaven run vite preview to tunnel the preview build instead.
5. Push when the build and the review are both green.

wiremaven run vite preview

Same overlay, same session visibility, same one-command setup. The reviewer sees the production build. You see what they clicked.

When to Fall Back to Staging

A local tunnel isn’t a replacement for staging. Staging exists for formal QA, regression testing, and compliance. A tunnel gives you what staging can’t: instant iteration without deployment overhead. For quick design reviews, client walkthroughs, and async teammate checks, a WireMaven tunnel from your Vite dev server is the fastest path.

For a deeper look at why deployment overhead adds up, read the hidden cost of deploy-to-demo workflows. Every push-to-demo round trip costs a CI run and a context switch. A tunnel removes those from the review cycle.

One Command, Full Visibility

Your Vite dev server is fast. The feedback you get on it should be, too. WireMaven gives your local build a temporary encrypted public URL and shows you exactly what happens when someone opens it. No deployment. No staging environment. No guessing whether the reviewer saw the thing you asked them to look at.

npm install -D wiremaven