PageSpy: remote debugging for Web, Mini Programs and HarmonyOS

The debugging gap PageSpy is built to close

A console error on your own laptop is cheap to investigate. The same error on a user's phone, inside an embedded webview, inside a WeChat Mini Program, or inside a HarmonyOS app is not. You cannot attach a debugger, you cannot ask the user to open devtools, and screenshots of a truncated log line rarely carry the object shape you need. The README lists exactly these cases: local debugging of H5 and webview applications on small screens, remote collaboration where error details get lost across email and calls, and white-screen reports from user terminals that a log pipeline cannot localize quickly.

The project is for front-end and client engineers who already have a stack for logs and dashboards but still cannot see the runtime state of a specific device. PageSpy does not replace those pipelines. It gives you a live console attached to one session, on a machine you control.

How the SDK intercepts native APIs and ships them to the console

The README describes the mechanism in one paragraph: PageSpy wraps native APIs, and when those methods run it filters and transforms the arguments, serializes them in a standard format, and sends them to the debugging client. The client then renders that data in an interface similar to a local devtools console.

That means the interception happens in the runtime under debug, not in the browser you are sitting at. Each platform gets its own package, which is why the repository carries badges for @huolala-tech/page-spy-browser, @huolala-tech/page-spy-wechat, @huolala-tech/page-spy-alipay, @huolala-tech/page-spy-uniapp, @huolala-tech/page-spy-taro and @huolala/page-spy-harmony. The web console itself is a TypeScript and React application built with Vite; the repository splits into src/ for the client, backend/ for the Go service, and public/ for static assets. There is a separate API repository, HuolalaTech/page-spy-api, whose Go version is exposed as a badge in the README.

The practical consequence: the data you see is whatever the SDK decided to serialize. Objects that cannot be serialized cleanly will not arrive intact. The README does not document how deep serialization goes or how large a payload can be, so treat that as an open question for your own testing.

Installing page-spy-api and opening the first session

The README gives two deployment paths. The Node.js path installs the API server globally:

yarn global add @huolala-tech/page-spy-api@latest

# if you use npm

npm install -g @huolala-tech/page-spy-api@latest

After installation, run `page-spy-api` in the terminal to start the service. When it is up, open `http://localhost:6752` in your browser. The README advises testing locally first and then deploying the same setup to your server.

The Docker path is a single command, and it mounts two volumes so logs and data survive container restarts:

docker run -d --restart=always -v ./log:/app/log -v ./data:/app/data -p 6752:6752 --name="pageSpy" ghcr.io/huolalatech/page-spy-web:latest

When the container is running, open `http://localhost:6752` in your browser. Port 6752 is the only port the README mentions for both paths, and the Dockerfile in the repository shows the image is built from a Go backend stage on golang:1.23 and runs the compiled binary on alpine:latest.

What you should see after either command is the PageSpy dashboard at that address. The README does not walk through connecting an SDK to the dashboard, so the next step is reading the per-platform SDK documentation rather than guessing at an initialization call.

Where PageSpy stops being the right tool

PageSpy is a live console, not a session recorder. The README never mentions recording, replay, or retaining a debugging session for later. If your problem is a bug that happened last Tuesday and nobody was watching, this tool does not address it. That is the job of an error tracker or a log pipeline, and the README explicitly frames dashboards and log pipelines as the slower alternative for white-screen reports rather than something PageSpy replaces.

There is a second boundary. The README's own framing is that PageSpy shines where local console debugging is not possible. If you can open devtools on the machine where the bug reproduces, the interception layer is overhead with no payoff. The same applies to build-time or server-side failures: the SDKs listed are browser, Mini Program, UniApp, Taro, React Native and HarmonyOS packages, so a Node.js process is outside the documented surface.

A third constraint is operational. Both deployment options put the console and the API on infrastructure you run. That is the point, since the README says the design keeps your data under your control, but it also means the tool has no managed fallback if you do not want to operate a service. The README does not document authentication, access control or how sessions are isolated, so anyone planning a public deployment needs to check that before exposing port 6752.

How PageSpy differs from browser-based remote debugging services

The obvious alternative is a hosted remote debugging service that gives you a console URL for a device without any server of your own. The difference is architectural, not cosmetic. A hosted service terminates the session on someone else's infrastructure and you accept their retention and access model. PageSpy inverts that: you install @huolala-tech/page-spy-api or run the ghcr.io/huolalatech/page-spy-web image, and the session data lands in the ./log and ./data volumes you mounted.

That trade is real in both directions. Self-hosting means you own the uptime, the port, and the upgrade cycle, and the README does not describe a hosted tier. In exchange, nothing about the debugging session leaves your network, which matters when the serialized arguments contain user data or internal identifiers.

A second alternative is the platform's own remote inspection tooling, for example the debugging facilities shipped with a Mini Program host or a mobile OS. Those are closer to the runtime and require no extra service, but the README's premise is that they are awkward on small screens and truncate logs. PageSpy's answer is a desktop-sized console rendering the same data, which is a UI argument rather than a capability argument. If your platform's inspector already gives you a full console on a desktop, the case for adding a service weakens.

Maintenance, releases and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-09-18. The release cadence visible in the release list is roughly one version every two to three weeks across v2.4.8 on 2026-08-04, v2.4.9 on 2026-08-25 and v2.4.10 on 2026-09-18. The package.json version is 2.4.10, matching the newest release tag.

Upgrade cost is worth reading carefully. The SDK packages are versioned independently of the web console, which is why the README carries a separate badge for the Browser, WeChat, Alipay, UniApp, Taro and Harmony SDKs plus the API. The repository has an upgrade:sdk script that runs `yarn upgrade -P '@huolala-tech/*' -L --ignore-optional`, so the maintainers' own workflow is to pull all @huolala-tech packages to their latest versions at once. If you pin SDK versions in your application, you are diverging from that workflow and should expect to test each platform package separately.

Licensing is MIT, per both the LICENSE file and the package.json license field. MIT permits commercial use and modification with the copyright notice retained. That is a statement about the licence text, not advice about your situation; if you redistribute a modified build, read the file yourself.

The README points contributing questions at CONTRIBUTING.md, which exists in English, Chinese and Japanese alongside the three README translations. The changelog.md file at the repository root is where release notes live, and the README does not describe a rollback procedure for a deployed API server.

Editorial conclusion

Adopt PageSpy if your bugs happen on devices you cannot attach a debugger to, and you are willing to run the page-spy-api service yourself. Skip it if you need session recording, replay or a managed backend; the README documents neither. Before rolling it out, install @huolala-tech/page-spy-api locally, open port 6752, and confirm which SDK package matches your runtime.

Frequently asked questions

Official sources

1. HuolalaTech/page-spy-web on GitHub
2. License: MIT
3. Project website
4. README
5. Releases