← All projects

LanView CLI

One command opens your app on a real phone over Wi-Fi — a local gateway, a QR code in the terminal, and no tunnel. Built so mobile testing stops being a chore.

2026open source · 26 stars
  • cli
  • nodejs
  • dev-tools
  • open-source
  • lan
  • qr-code

Every web project eventually gets tested on a phone, and every time it does, the first ten minutes are wasted on plumbing instead of the thing you were trying to check. LanView exists to delete those ten minutes. You run one command inside a project, a QR code appears in your terminal, you scan it, and your app — frontend and backend both — is open on the device in your hand.

I'm a contributor to it. Prashant Dhuri started the project.

A QR code printed in the terminal, then the same app opening on a phone

Why we built it

Desktop-first development hides a specific class of bug until the worst moment. You ship something that looks right in a narrow Chrome window, open it on a phone, and find the layout cramped and the buttons too close together. That is the easy failure. The expensive one is silent: the page renders, and every fetch to the API fails.

Because localhost means this device. On your laptop it points at your backend; on a phone it points at the phone. So mobile testing usually degrades into hardcoding your machine's IP into the frontend, remembering to undo it, and then discovering a new address when the router hands out a different lease tomorrow.

The existing escape hatch is a tunnel service. It works, but it means an account, a quota, and putting a half-finished dev server on the public internet — which is a strange thing to do to something you are still debugging.

We wanted the opposite shape: the phone is already on the same Wi-Fi as the laptop, so there is no reason the traffic should leave the room.

The problem it solves

  • Finding the URL. No more reading ipconfig and retyping http://192.168.1.45:3000 on a touch keyboard. The terminal prints a QR code; you scan it.
  • Broken API calls on device. One local gateway serves both sides, so /api requests work identically on the laptop and the phone, with relative paths and no CORS.
  • Live reload that survives the switch. WebSocket upgrades are proxied too, so hot reload keeps firing while you are looking at the phone instead of the editor.
  • Tunnels, accounts and quotas. Nothing leaves your router. No sign-up, no monthly limit, no third party holding your session open.
  • Static previews. --static serves a folder with reload-on-save, which makes it a drop-in replacement for the Live Server extension — but scannable.

What it is used for

Checking a checkout flow on an actual phone before calling it done. Suspending layout debugging until you can tilt the device. Testing touch, drag and long-press behaviour that a mouse can only imitate. Handing your phone to someone in the room to show them a build without deploying it. Opening a static export on a tablet to see whether the breakpoint you wrote does anything.

The common thread is short feedback loops: the closer the device is to the one that matters, the fewer surprises survive to launch.

How it works

Three local steps. It picks the active LAN address off the OS network interfaces, starts a small reverse proxy on :8080 that routes ordinary requests to the frontend and /api/* to the backend, then draws the gateway URL as a QR matrix out of ANSI blocks in the terminal.

npx lanview                    # :8080 → frontend :3000, /api/* → backend :5000
lanview -f 5173 -b 8000        # different ports
lanview --static ./dist --spa  # preview a build, live reload on save

It is framework-agnostic on purpose — Vite, Next, Vue, Svelte, Express, Django and Laravel all behave the same way, because from the gateway's point of view they are just ports. It is published on npm as lanview under the MIT license, and it is plain Node with no build step of its own.

Where it stands

Around 26 stars, which is roughly the point where a small tool stops being a private convenience and starts being something other people install on purpose. The full technical reference lives in the repository README — this page is the why, that one is the how.