Self-Host PanWatch for Remote Access with Localtonet

How this PanWatch deployment works

PanWatch combines a browser-based workspace with portfolio management, market monitoring, alerts, reports, paper trading, and AI-assisted research. It covers mainland China, Hong Kong, and United States stocks, along with listed ETFs. Its workflows include watchlists, holdings, quotes, candlesticks, opportunities, and configurable notifications. PanWatch is also an installable Progressive Web App, so a compatible browser can add the interface to a mobile home screen after the site is reachable.

The deployment has two independent layers. Docker runs PanWatch and stores persistent application data in the named volume panwatch_data, mounted at /app/data inside the container. The preferred network configuration publishes container port 8000 as 127.0.0.1:8000 on the host. You first open http://127.0.0.1:8000, create PanWatch credentials, configure an AI provider, and confirm that the application works.

After local verification, the Localtonet client on the same host establishes an outbound connection to one of our relay servers. A Localtonet HTTP tunnel points to 127.0.0.1 on port 8000 and provides a public HTTPS address for authorized remote use. This workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

Why local verification comes first

A tunnel can make a reachable local service available remotely, but it cannot repair an application that is stopped, listening on the wrong address, waiting for first-start initialization, or rejecting its own configuration. Testing PanWatch locally creates a clear troubleshooting boundary. If http://127.0.0.1:8000 fails on the host, investigate Docker and PanWatch. If the local page works but the public address fails, investigate the Localtonet client, selected device, tunnel state, Process Type, and local target.

Prerequisites and platform scope

Use a machine that can run Docker and remain online whenever PanWatch or its scheduled tasks are needed. The PanWatch quick-start path assumes a working Docker installation. The Compose alternative additionally requires the docker compose command. The available project evidence does not establish a PanWatch-specific operating-system compatibility list, so confirm that Docker itself is supported and operating correctly on the chosen host.

Docker needs network access to retrieve the PanWatch image. On first startup, PanWatch can also download Chromium's headless shell for browser-based features such as screenshots. That download is stored in the mounted volume under the default path /app/data/playwright and can take several minutes.

For AI-assisted research, prepare a service supported by PanWatch's AI Services interface. The project documents OpenAI-compatible providers and local models through Ollama. Provider addresses, model names, credentials, costs, rate limits, and availability vary. Obtain the exact values from the provider you select, and never put a real provider credential into a public command, screenshot, tunnel name, or support post.

You also need a Localtonet account, a device-specific AuthToken, and a currently available relay server or region selected from the dashboard. AuthTokens identify client devices and must be treated as secrets. Relay choices and server codes are account-specific and time-sensitive, so this tutorial does not hardcode either value.

Supported Localtonet installation path used in this guide

Localtonet provides downloads for Windows, Linux, macOS, Docker, and Android. To keep the installation instructions reproducible without mixing platform-specific procedures, the command sequence below is scoped to a supported Debian or Ubuntu host using the x64 DEB package. The current package path requires systemd 247 or newer and OpenSSL 3, such as Debian 12 or Ubuntu 22.04 and newer.

If your PanWatch host uses another supported platform or CPU architecture, select the matching client from the Localtonet documentation and download page and follow the platform-specific instructions shown there. Do not install an x64 package on an ARM64 host.

Choose the correct timezone before creating schedules

PanWatch uses the container's TZ environment variable for background schedules and notification quiet hours. The image defaults to Asia/Shanghai and does not automatically detect the host timezone. Use an appropriate IANA timezone such as UTC or America/New_York if the default does not match the wall-clock context intended for automation.

The browser timezone separately controls interface timestamps and alert expiry inputs. This distinction matters when the Docker host, the exchanges being monitored, and the browser are in different regions. Decide which wall-clock timezone should control scheduled automation, then set TZ deliberately during deployment.

Choose Docker Run or Docker Compose

Both methods below use the same image, restart policy, timezone variable, loopback-only port binding, and persistent volume. Docker Run is convenient for a single command. Docker Compose records the deployment in a file, which can make later review and recreation easier. Do not run both methods simultaneously with the same container name and host port.

The project evidence identifies both sunxiao0721/panwatch:latest and the versioned image sunxiao0721/panwatch:0.18.1. The examples use latest to follow the current quick start. If your operational policy requires a fixed release, replace only the image tag with a version you have reviewed. Do not assume that 0.18.1 will remain the newest release.

Choose the Docker network binding before installation

Docker port publishing is an important security boundary. The PanWatch project quick start uses -p 8000:8000. In a normal Docker configuration, omitting the host IP publishes the port on all host interfaces. That commonly makes PanWatch reachable through the host's LAN addresses, not only through localhost. Depending on the host, cloud security rules, upstream firewall, and network topology, it can also create broader exposure than intended.

When Localtonet runs on the same host as PanWatch, broad host exposure is unnecessary. Docker can publish the service only on the IPv4 loopback address by using -p 127.0.0.1:8000:8000. PanWatch still receives traffic on container port 8000, while the host accepts connections only through 127.0.0.1:8000. The same-host Localtonet client can reach that endpoint directly.

When the Localtonet client runs on another device

A separate client device cannot reach the PanWatch host's loopback address. In that architecture, publish PanWatch on the host's specific LAN address, represented in this guide as <PANWATCH_LAN_IP>. For example, the Docker Run shape is -p <PANWATCH_LAN_IP>:8000:8000. Replace the placeholder with an address actually assigned to the PanWatch host.

Binding to a LAN address makes PanWatch available to devices that can route to that interface and are permitted by the host firewall. Restrict inbound TCP port 8000 to the Localtonet client device where your firewall supports source restrictions. Do not open that port on the router, and do not expose it broadly through a cloud firewall. Verify from the separate client device that the LAN endpoint is reachable before configuring the tunnel.

This guide uses the same-host, loopback-only model for all primary commands because it creates the narrowest local exposure and the simplest target. The separate-device substitutions are called out where they differ.

Install PanWatch with Docker

Option A: Docker Run

docker run -d \
  --name panwatch \
  --restart unless-stopped \
  -e TZ=Asia/Shanghai \
  -p 127.0.0.1:8000:8000 \
  -v panwatch_data:/app/data \
  sunxiao0721/panwatch:latest

Docker may need time to download the image. First startup can take additional time while PanWatch downloads Chromium's headless shell into the mounted volume. Do not assume the service failed simply because the page is unavailable immediately after the container command returns.

Option B: Docker Compose

Create a Compose file in a directory retained for this deployment. This definition applies the same loopback-only binding:

services:
  panwatch:
    image: sunxiao0721/panwatch:latest
    container_name: panwatch
    environment:
      TZ: "Asia/Shanghai"
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - panwatch_data:/app/data
    restart: unless-stopped

volumes:
  panwatch_data:

docker compose up -d

If you later change environment.TZ, run docker compose up -d again to recreate the container with the updated definition. Keep the named data volume during that recreation.

Separate-client port substitution

Only if the Localtonet client must run on another LAN device, replace the loopback mapping with a specific address assigned to the PanWatch host:

ports:
  - "<PANWATCH_LAN_IP>:8000:8000"

Apply a host firewall rule that permits the separate Localtonet client to reach TCP port 8000 while denying unnecessary sources. Firewall syntax varies by operating system and policy manager, so use the supported mechanism for your host. Avoid replacing the placeholder with 0.0.0.0 unless broad interface binding is a deliberate and reviewed requirement.

Optional: skip the first-start browser download

The PanWatch image includes Playwright's system dependencies, but Chromium's headless shell is downloaded on first startup. If you do not need browser features such as screenshots, PanWatch documents PLAYWRIGHT_SKIP_BROWSER_INSTALL=1 to skip that download.

For Docker Run, add this environment argument before the image name:

-e PLAYWRIGHT_SKIP_BROWSER_INSTALL=1

For Compose, add it under the existing environment section:

environment:
  TZ: "Asia/Shanghai"
  PLAYWRIGHT_SKIP_BROWSER_INSTALL: "1"

Create your PanWatch account and configure AI

On the Docker host, open http://127.0.0.1:8000. The loopback-only mapping intentionally prevents another LAN device from opening the page directly. If the host has no graphical browser, use a local browser through an administrative access method you already trust, or temporarily use the separate-client LAN model with an appropriately restricted firewall.

On first use, create PanWatch login credentials. Use a strong, unique password and complete this step before starting a public tunnel. PanWatch can contain portfolio information, watchlists, alerts, provider configuration, research output, and notification integrations, so the dashboard should not be treated as a public, anonymous site.

The main guided tour opens on first sign-in and covers stocks, quotes, AI setup, and a first analysis. Required steps cannot be skipped, but the tour can be paused and resumed. Progress survives browser changes and service restarts. If you close the tour, reopen it from the Guide center.

Understand the available PanWatch workflows

The Guide center includes material for opportunities, paper trading, the assistant, daily tasks, and data sources. Each guide keeps its own progress and can be replayed. You do not need to configure every feature before enabling remote access. Establish login protection, verify basic market data and AI connectivity, and only then enable automation or external notification channels.

PanWatch can search stocks and listed ETFs by code or name. The asset type is stored with each instrument. For a fund whose provider name does not identify it as an ETF, select ETF explicitly. ETF deep analysis uses fund-specific context rather than substituting company financial statements. The documented implementation does not yet supply fund holdings, NAV, fees, and tracking error as structured data. Paper trading also retains its existing market rules and cost model and does not model ETF-specific T+0 exceptions or fee schedules.

These limitations matter when interpreting generated research and simulated performance. Self-hosting controls where the application runs, but it does not make incomplete market data complete or turn AI-generated output into guaranteed financial guidance.

Verify PanWatch before creating a tunnel

Verification should cover the container state, bound host address, HTTP endpoint, authentication flow, persistence, timezone choice, and AI connection. This creates a known-good baseline before remote networking is introduced.

Check the container

docker ps --filter name=panwatch

If the container is absent, include stopped containers:

docker ps -a --filter name=panwatch

Review startup output if the container exits, repeatedly restarts, or remains unavailable:

docker logs panwatch

Confirm the published address

Inspect the container's published ports:

docker port panwatch

For the preferred deployment, the result should indicate that container port 8000 is published through 127.0.0.1:8000. If it shows 0.0.0.0:8000, the service is broadly bound on IPv4 interfaces. Recreate the container with the loopback mapping before proceeding with the same-host design.

Check the local web endpoint

http://127.0.0.1:8000

Open that address on the Docker host. Confirm that the login page loads, that you can sign in, and that dashboard navigation works. With the loopback-only mapping, do not expect http://<PANWATCH_LAN_IP>:8000 to work from another device.

For the separate-client model, perform a second test from the Localtonet client device using http://<PANWATCH_LAN_IP>:8000. If that test fails, correct the Docker binding, route, or host firewall before creating the tunnel.

Check account and provider behavior

Sign out and sign back in to confirm that the credentials work. In Settings → AI Services, make sure the selected default model passes its test. If you changed a model or notification-channel configuration, run its test again. Then execute the first analysis intentionally and confirm that the result remains visible.

Check persistence

Create only a non-sensitive test setting or temporary watchlist entry, then restart the container:

docker restart panwatch

After the service returns, sign in and verify that the test data remains. This confirms that the named volume survives a normal container restart. It is not a backup test. The supplied project evidence defines the persistent volume location but does not define a complete backup and restoration procedure, so use a Docker volume backup method appropriate to your environment and validate restoration separately.

Install Localtonet and create the HTTP tunnel

An HTTP tunnel is appropriate because PanWatch provides a browser-based HTTP service. The preferred architecture installs Localtonet on the PanWatch host and targets 127.0.0.1:8000. The instructions below first install the supported Debian or Ubuntu x64 package, then reproduce the dashboard workflow.

Install the Localtonet client on Debian or Ubuntu x64

sudo apt install ./localtonet-linux-x64.deb

Edit the token file as root. Do not place the real token in shell output, this article, or a shared screenshot. After saving it, run:

sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-config

If the configuration check succeeds, start the service:

sudo systemctl enable --now localtonet.service
sudo journalctl -u localtonet.service

These instructions use the normal tunneling service, not VPN Manager. If you are using Windows, macOS, ARM64 Linux, Docker, or another supported client path, follow the matching installation procedure in our current Localtonet documentation.

Create and start the HTTP tunnel

Custom-domain DNS requirements can change and are not established by the PanWatch project evidence. If you select Custom Domain, follow the current instructions displayed by Localtonet before changing DNS records. Do not guess record types or target values.

Understand the tunnel lifecycle

A configured tunnel is not automatically available. The selected Localtonet client must be connected, and the tunnel must be running. Remote access ends if the PanWatch container stops, the host loses connectivity, the Localtonet client disconnects, or the tunnel is stopped. Deleting a tunnel removes its configuration, while stopping it preserves the configuration for later use.

This allows PanWatch to continue operating locally while its public route is stopped. Scheduled PanWatch tasks can continue according to the application configuration, but the stopped tunnel no longer forwards remote requests to the service.

Routine operation, restart, and update workflow

Keep the host online, monitor available storage, retain the named volume, review logs when behavior changes, and test the loopback endpoint after updates before relying on remote access.

Start, stop, and restart Docker Run deployments

docker stop panwatch
docker start panwatch
docker restart panwatch

The unless-stopped policy allows Docker to restart the container after daemon or host restarts unless it was explicitly stopped. It does not guarantee that the host, Docker daemon, application, external market data, AI provider, or network will always be available.

Operate a Compose deployment

docker compose stop
docker compose start
docker compose restart

Apply changes to the saved Compose definition with:

docker compose up -d

Review logs

docker logs --tail 200 panwatch

Follow new output while reproducing a problem with:

docker logs -f panwatch

Avoid sharing unreviewed logs publicly. They can contain operational details, provider errors, instrument identifiers, or information associated with your installation.

Update carefully

The latest image tag can point to a newer image over time. Pulling that tag and recreating the container is an application update, not merely a restart. Review the selected PanWatch release, preserve the panwatch_data volume, and establish a tested backup appropriate to your Docker environment.

docker compose pull
docker compose up -d

After recreation, run docker port panwatch and confirm that the loopback-only binding remains in place. A version-pinned deployment can use a reviewed release tag instead of latest. The evidence for this guide confirms that sunxiao0721/panwatch:0.18.1 was published, but select the appropriate release at deployment time rather than assuming it remains current.

Troubleshooting PanWatch and remote access

The container name is already in use

docker ps -a --filter name=panwatch

The existing container may be an earlier PanWatch installation that should be started, repaired, or intentionally replaced. Do not remove it until you understand whether it uses the persistent data volume and whether its configuration is still needed.

Port 8000 is already allocated

Another process may already be listening on 127.0.0.1:8000. Identify the listener and decide which service should own the port. If you intentionally select another host port, change only the host side of the mapping, such as 127.0.0.1:8080:8000. Local verification and the Localtonet target must then use port 8080, while PanWatch still listens on port 8000 inside the container.

The page is unavailable immediately after startup

Confirm that the container is running and review docker logs panwatch. First startup may take several minutes while Chromium's headless shell is downloaded into /app/data/playwright. Confirm that the host has outbound network access. If PLAYWRIGHT_SKIP_BROWSER_INSTALL=1 was configured, browser features such as screenshots will not have the downloaded browser component.

PanWatch works on the host but not from another LAN device

This is expected with 127.0.0.1:8000:8000. The mapping intentionally accepts only host-local connections. Keep this model when Localtonet runs on the same host. If a separate Localtonet device is required, recreate PanWatch with the host's specific LAN address in the mapping and apply a restrictive host firewall policy.

The separate Localtonet client cannot reach PanWatch

From that client device, test http://<PANWATCH_LAN_IP>:8000. If it fails, check that the address is assigned to the PanWatch host, Docker is bound to that address, the devices have a valid route, and the host firewall permits the client source. Do not create the tunnel until this direct LAN test works.

The AI service test fails

Recheck Settings → AI Services. Confirm the provider endpoint, credentials, selected model, quota, and outbound reachability using the provider's current requirements. The Localtonet HTTP tunnel publishes the PanWatch web interface, while PanWatch's provider connection is a separate outbound application request.

Schedules run at the wrong time

Check the container's TZ value. Interface timestamps and alert expiry inputs use the browser timezone, while background schedules and quiet hours use the container timezone. After changing TZ, recreate the container and review every scheduled wall time.

PanWatch works locally but not through Localtonet

1. Confirm that PanWatch still opens on the exact target address and port.
2. Confirm that the Localtonet client service is running.
3. Confirm that the AuthToken's device appears connected in the dashboard.
4. Confirm that the HTTP tunnel uses the intended Process Type.
5. For a same-host client, confirm the local target is 127.0.0.1 and port 8000.
6. For a separate client, confirm the target is the PanWatch host's LAN address, not localhost.
7. Confirm that the tunnel has been started rather than merely created.
8. Test the currently assigned public address.

On a separate client device, 127.0.0.1 and localhost refer to that client device, not to the PanWatch host. This is one of the most common target-address mistakes.

Remote access stopped after a restart

Check every lifecycle component. The host must be online, Docker must be running, PanWatch must be running, the Localtonet client must be connected, and the tunnel must be started. The container's restart policy does not start a stopped tunnel or repair a client authentication problem.

Security and privacy checklist

Remote access changes the threat model of a local dashboard. PanWatch may contain portfolio details, alerts, model configuration, reports, and integration settings. Treat its public address, application credentials, provider credentials, and Localtonet AuthToken as sensitive.

Apply least privilege to the host, Docker access, provider accounts, notification channels, firewall policy, and users permitted to sign in. Docker control commonly carries extensive authority over the host, so do not grant Docker access merely because someone needs to use PanWatch.

Review image updates before applying them. A mutable tag is convenient but less predictable because it can resolve to a newer image. A versioned tag makes the selected release explicit, but pinning also means later fixes are not adopted automatically.

Frequently asked questions