Show a local dev server without deploying

Choose live review or persistent access

Preview without deployment fits “look at this version together now”: the page is changing, the client needs real interaction, and you can keep your computer online. Use staging or a normal deployment when clients need access at any time, or when you must verify production builds, domains, server configuration, and release behavior.

• Local sharing: shows your current dev server, starts quickly, and depends on your computer and sharing session.
• Staging: shows a deployed version and suits asynchronous acceptance reviews and release-configuration checks.
• Production: serves ongoing public traffic and needs normal hosting, operations, and release procedures.

A complete edit-to-review example

You have just adjusted the mobile layout of a product page at http://localhost:3000. The client needs to check the heading and purchase button before you release it.

1. Open the target page locally and test the demo flow using test data.
2. Open Previa, sign in, enter the actual port, and start sharing.
3. Send the generated link with the page and task to review. The client opens it in Chrome or Safari.
4. The client interacts with the page, selects a region, and sends a note.
5. Edit locally, check the result, and ask the client to reload and verify. Do not assume their page follows your local hot reload.
6. Export the feedback you need, stop sharing, then build, test, and release through your existing project workflow.

Check the dependencies as well as the page

The visitor receives what their browser can load, rather than your whole development environment. Verify API access, authentication, third-party resources, and other local services for your actual project.

• A hardcoded API URL on another localhost port points to the visitor’s machine. Inspect network requests and prefer relative paths through the same dev server and its development proxy.
• Your browser’s signed-in state is not automatically transferred by a share link. Prepare a test account and verify any authenticated demo flow.
• Features tied to production domains, callback URLs, or production configuration still need checks in the corresponding test environment.
• If the page works locally but fails remotely, test a simple page first, then check individual assets and API calls instead of changing several conditions at once.

When to move to a deployed environment

Sleep, a stopped server, or an ended session affects future access. Move to deployment when you need asynchronous review, a stable address, release validation, or access that does not depend on one person’s computer. Temporary sharing shortens the feedback loop during development.

Remove sensitive data before the demo and select “Stop sharing” afterward. Continue with the client annotation guide for feedback and export steps, or localhost sharing and troubleshooting for connection issues.

Does the project get uploaded?

Previa does not require uploading the project directory or a build archive to a hosting server. After the client opens the share link, the browser requests only the HTML, scripts, styles, and images needed by the running page. Data uses a peer-to-peer path by default and an encrypted relay when a direct path is unavailable.

This does not hand the whole project to the client, and it is not a backup or deployment. Front-end resources received by a browser can still be inspected, so never place secrets in client-side code or real sensitive records in demo data.