27 min read

Set Up tick-stock-panel Dev Mode with Localtonet

Install and verify tick-stock-panel in development mode, then provide remote HTTP access to its FastAPI web app with Localtonet.

A local FastAPI application connected through an HTTP tunnel to a remote browser.
tick-stock-panel runs locally while Localtonet carries remote HTTP requests to the development server.
Self-Hosting Tutorials ยท tick-stock-panel ยท Localtonet ยท 2026

Run the React and FastAPI development stack locally, verify each service, and publish the appropriate HTTP endpoint only when remote access is required

tick-stock-panel is a self-hosted stock research and quantitative analysis workspace built with a React frontend and FastAPI backend. This guide explains the documented development workflow, the simpler Docker Compose deployment path, local verification, routine operations, and common startup problems. After the application works locally, we show how to connect its HTTP service through Localtonet without configuring inbound router port forwarding, opening a public firewall port, setting up a VPN, or requiring a public IP address. Because the project is intended for learning and research and its public-access security model is not established by the available project documentation, the guide also treats remote exposure as a deliberate security decision rather than an automatic installation step.

๐Ÿ”’ Verify locally before enabling remote access ๐ŸŒ FastAPI on port 3018 and development frontend on port 3011 โšก Development scripts and Docker Compose workflows

What tick-stock-panel runs in development mode

tick-stock-panel, also identified as TSP in its repository, is a self-hosted workspace for Chinese A-share stock selection, monitoring, analysis, and backtesting. Its documented architecture separates presentation from application services. React 18, Vite, and TypeScript provide the frontend, while FastAPI provides the backend application layer. The project also uses components such as Polars, DuckDB, Parquet storage, Pydantic, APScheduler, and server-sent events in its broader architecture.

That separation matters when installing the project. In documented development mode, two local HTTP services are started. The backend is available at http://localhost:3018, while the development frontend is available at http://localhost:3011. Developers can use the separate processes while editing and debugging the code.

The documented Docker Compose path presents a simpler browser entry point at http://localhost:3018. For remote access to the integrated application, this single-container HTTP interface is the clearest evidenced target. It avoids making assumptions about whether a remote browser loading the development frontend on port 3011 can also reach the separate backend correctly under every frontend configuration.

โš›๏ธ React development frontend Development mode starts the frontend at http://localhost:3011. This is the browser-facing development server used while working on the frontend.
๐Ÿ FastAPI backend The backend starts at http://localhost:3018. It supplies the application service layer, including the project's REST and server-sent event architecture.
๐Ÿ“ฆ Docker Compose deployment The repository documents docker compose up --build as the container-based startup command and identifies port 3018 as its local browser entry point.
๐Ÿ”Œ Optional integrations The project supports multiple data-source capabilities and an optional OpenAI-compatible AI interface. The exact credentials and settings depend on the services selected by the operator.
Research software is not investment advice

The project describes itself as a personal open-source project for learning and research, not as investment software or a market quotation application. It expressly disallows commercial use and does not position itself as an AI stock recommendation or price-limit prediction product. Review the repository license, usage notices, data-source terms, and applicable financial-data rules before operating it.

Prerequisites for development and container installation

Select your installation path before installing dependencies. The native development workflow requires language runtimes and package managers on the host. The Docker Compose workflow instead requires Docker with Compose support. Both paths require a copy of the repository and a local environment file derived from the included example.

Requirements for native development mode

The documented development requirements are Python 3.11 or newer, Node.js 20 or newer, uv, and pnpm. Git is also needed if you plan to clone the repository with the commands shown below. Install each tool through its official distribution channel for your operating system.

Confirm that the tools resolve in the same terminal session from which you will run the project. These checks report the installed versions without modifying the system:

git --version
python --version
node --version
uv --version
pnpm --version

On systems where Python 3 is exposed as python3 rather than python, use the command appropriate to that installation:

python3 --version

The reported Python version must be 3.11 or newer, and Node.js must be 20 or newer. If a terminal still shows an older version after an upgrade, close and reopen the terminal, then inspect the executable search path. Multiple Python or Node.js installations are a frequent reason that a version check differs from the version an operator expected to use.

Requirements for Docker Compose

For the container workflow, install a current Docker environment that provides the docker compose command. Confirm that both the Docker client and Compose subcommand are available:

docker --version
docker compose version

Docker must also be running. A successful version check proves that the command-line client exists, but it does not necessarily prove that the Docker engine is available. If startup later reports that it cannot connect to the daemon or engine, start Docker and repeat the command.

Host and network preparation

Ensure that ports 3011 and 3018 are not already occupied if you plan to use native development mode. The Compose path requires its documented host entry point on port 3018 to be available. The available project evidence does not establish supported port-remapping procedures, alternate environment variables, or alternate development ports, so this guide does not invent them. If a collision exists, stop the conflicting service or consult the current repository configuration before changing project files.

Data-source and optional AI functionality can require credentials or service-specific configuration. Do not paste secrets into shell history, source control, screenshots, support messages, or Localtonet tunnel settings. The repository includes .env.example as the configuration template, but the values appropriate for your selected data sources must come from those services and the current project documentation.

Keep the environment file private

The .env file may contain credentials or other sensitive configuration. Confirm that it is excluded from commits before making changes, and never place a Localtonet device token in this project file unless current Localtonet documentation explicitly calls for that workflow. Localtonet device tokens identify client devices and must not be exposed or guessed.

Choose the right installation mode

Comparison of native development mode and Docker Compose installation paths.
Development mode runs from the source environment, while Docker Compose runs the application in a container.

The native development path and the Docker Compose path serve different goals. Use the development scripts when modifying backend or frontend code and when you need the two development services. Use Compose when the immediate goal is to run and access the application through the documented single HTTP entry point.

Mode Required tools Documented local addresses Best fit
Native development on Linux or macOS Python 3.11+, Node.js 20+, uv, pnpm, and a shell capable of running dev.sh Backend on localhost:3018; frontend on localhost:3011 Editing, debugging, and testing the split frontend and backend stack
Native development on Windows Python 3.11+, Node.js 20+, uv, pnpm, and PowerShell for dev.ps1 Backend on localhost:3018; frontend on localhost:3011 Windows-based development using the repository's provided PowerShell script
Docker Compose Docker with the docker compose command Integrated browser entry point at localhost:3018 Running the documented container build with one clear local HTTP target

This article covers both modes, but they should normally be treated as alternatives. Do not start both simultaneously on the same host unless you have intentionally changed and validated the relevant port bindings. Otherwise, both paths will attempt to use port 3018.

Recommended path for a single remote application endpoint

If your main objective is to operate the application and then reach it through Localtonet, use Docker Compose and verify http://localhost:3018. If your objective is active source development, use the native scripts and keep the frontend and backend roles distinct. Exposing only the development backend does not automatically prove that the complete frontend will work remotely.

Install and start tick-stock-panel in development mode

The repository provides dev.sh for a shell-based environment and dev.ps1 for PowerShell. These scripts are the documented development entry points. Because the available evidence does not define a complete supported manual replacement for everything the scripts perform, use the provided script instead of guessing separate backend and frontend installation commands.

1

Clone the repository

Open a terminal in the parent directory where you want to store the project, clone the public repository, and enter the new directory.

git clone https://github.com/shy3130/tick-stock-panel.git
cd tick-stock-panel
2

Create the local environment file

Copy the repository's .env.example file to .env. On Linux or macOS, run:

cp .env.example .env

In PowerShell on Windows, run:

Copy-Item .env.example .env
3

Review the environment configuration

Open .env in a local text editor and review the available settings. Configure only the data sources and optional integrations you understand and intend to use. Preserve the variable names and syntax from the example. This guide does not supply guessed credentials, undocumented variables, or universal values because the correct configuration depends on the current project version and selected services.

4

Run the development script

On Linux or macOS, launch the provided shell script from the repository root:

bash dev.sh

On Windows, launch the provided PowerShell script from the repository root:

.\dev.ps1
5

Wait for both development services

Keep the terminal open and watch the startup output. Development mode is expected to provide the backend at http://localhost:3018 and the frontend at http://localhost:3011. Do not create a public tunnel while either service is still failing, restarting repeatedly, or reporting dependency errors.

What the two addresses mean

Port 3011 is the development frontend. Open it in a browser on the host to test the React interface. Port 3018 is the FastAPI backend address documented by the project. A response from one port does not prove that the other process is healthy, so test both.

Browser developer tools are useful during this phase. If the page loads but data-dependent panels fail, inspect the browser console and network requests, then compare them with the backend terminal output. A frontend page rendering successfully can coexist with failed API calls, missing data-source credentials, or backend exceptions.

Stop development mode cleanly

When the script is running in the foreground, return to its terminal and use Ctrl+C. Wait for the processes to exit before starting Docker Compose or rerunning the script. If a later startup says that port 3011 or 3018 is already in use, an earlier process may still be running.

Run tick-stock-panel with Docker Compose

Docker Compose is the documented quick-start deployment path. It builds the project from the repository and starts the service with a browser-accessible interface at http://localhost:3018. This is also the most straightforward endpoint to connect through an HTTP tunnel after local verification.

1

Open the repository directory

If you have not already cloned the project, clone it and enter its directory. If you completed the development setup, stop the development services before continuing so that port 3018 is available.

git clone https://github.com/shy3130/tick-stock-panel.git
cd tick-stock-panel
2

Copy the environment template

Create .env from .env.example. Use the command for your shell.

cp .env.example .env
Copy-Item .env.example .env
3

Review the configuration

Inspect .env before building. Add only the settings required for the data sources and optional integrations you have chosen. Keep all credentials private and out of version control.

4

Build and start the Compose application

Run the documented command from the repository root:

docker compose up --build

The initial build can take longer because Docker must build the image and obtain required components. Keep the terminal open and review the output for failures.

5

Open the local application

After startup completes, open http://localhost:3018 in a browser on the Docker host. Verify the page locally before adding Localtonet.

Routine Compose operations

When Compose is attached to the current terminal, its logs are displayed directly. Stop the foreground process with Ctrl+C. To remove the containers and network created by the Compose project, run the standard Compose shutdown command from the repository directory:

docker compose down

To inspect service status or recent output while troubleshooting, standard Compose commands include:

docker compose ps
docker compose logs

Be cautious with Docker commands that remove volumes or delete host data. The available project evidence does not establish which application data is persistent under every version of the Compose configuration. Back up important data and inspect the current docker-compose.yml before using destructive cleanup options.

Verify the application before exposing it

Terminal and local browser checks confirming that tick-stock-panel is running.
Confirm the FastAPI process and local page response before creating a public tunnel.

Local verification separates application problems from tunnel problems. A Localtonet HTTP tunnel forwards requests to a local IP address and port reachable by the Localtonet client. It cannot make an application healthy if the service is stopped, listening on a different port, failing during startup, or blocked from the client device.

Development-mode verification

Open both documented addresses from a browser on the host:

  • http://localhost:3011 for the React development frontend
  • http://localhost:3018 for the FastAPI backend

Confirm more than the presence of a browser tab. Check that the frontend renders, navigation works, and expected requests do not fail continuously. Some stock-data or AI-assisted features may remain unavailable until their corresponding services are configured. That is different from the application itself failing to start.

Docker Compose verification

Open http://localhost:3018 on the Docker host. Confirm that the application interface loads and that Compose is not reporting repeated restarts or fatal exceptions. If the browser reports a connection refusal, check docker compose ps and the terminal output before changing any Localtonet settings.

Test from the Localtonet client device

The Localtonet client must run on the same device as tick-stock-panel or on another device that can reach it over the local network. If both run on the same machine, 127.0.0.1 and port 3018 are the natural target for the Compose service. If the client runs elsewhere, use the tick-stock-panel host's reachable private IP address rather than 127.0.0.1, because loopback always refers to the device on which the client is running.

Before creating the tunnel from a separate client device, open the target address from that device's browser. For example, if tick-stock-panel is reachable at a private address such as 192.168.1.50, test http://192.168.1.50:3018. That address is only an example. Use the actual private address assigned to your host.

Use the right endpoint for the intended result

In native development mode, port 3018 is the FastAPI backend and port 3011 is the frontend development server. The available evidence does not establish every cross-origin, host-allowlist, websocket, or frontend API-origin behavior for remote development access. For a complete browser application through one evidenced endpoint, use the Docker Compose interface on port 3018. If you intentionally tunnel the split development services, test their remote interaction and review current project configuration rather than assuming that one tunnel covers both ports.

Connect tick-stock-panel through Localtonet

Remote HTTP traffic passing through Localtonet to the local tick-stock-panel FastAPI service.
The public endpoint forwards HTTP requests through Localtonet to the FastAPI service on localhost.

Complete this section only after the selected local URL works. With Localtonet, our client application establishes an outbound connection to a Localtonet relay server. The resulting HTTP tunnel provides a public HTTPS address for the local HTTP target without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

Creating a tunnel does not mean it is running. After configuring it, you must start it. The public address remains available only while the selected Localtonet client device is connected and the tunnel is running.

The steps below use the Docker Compose endpoint at 127.0.0.1:3018 when Localtonet and tick-stock-panel run on the same host. Substitute a locally reachable private IP only when the Localtonet client runs on another device.

1

Install and run the Localtonet client

Install our client application on the device that can reach tick-stock-panel. Use the current installer for that operating system and keep the client running. Exact installation commands can vary by operating system and client version, so obtain them from the current Localtonet download or documentation interface rather than using an unverified command.

2

Authenticate or select the client device

Use the device-specific authentication token associated with the client that will run the tunnel. Do not paste the token into this article's example commands, the tick-stock-panel repository, or a public support message. Confirm that the intended device appears connected before proceeding.

3

Select an available relay server

Choose a currently available Localtonet relay server or region from the dashboard. Available server codes and regions can change and may vary by plan, so use the values shown in the current product instead of copying a hardcoded value from a tutorial.

4

Create an HTTP tunnel for the local service

Create an HTTP tunnel and set its local target to the address reachable from the Localtonet client. For Docker Compose on the same host, use local IP 127.0.0.1 and local port 3018. If the client is on another device, use the verified private IP of the tick-stock-panel host and port 3018. HTTP tunnels can use a generated subdomain, a selected subdomain where supported, or a custom domain. Consult the current dashboard and documentation before configuring custom-domain DNS.

5

Start the tunnel

Select Start after checking the target. Tunnel creation alone does not activate it. Once the tunnel is running and the client is connected, copy the assigned public HTTPS URL from the dashboard.

6

Test the public address safely

Open the assigned URL from a separate browser session or another network. Verify that the intended application loads and that no administrative, credential, or configuration data is unexpectedly exposed. When testing is complete, stop the tunnel unless continuous remote availability is genuinely required.

For the current interface and exact field sequence, consult our Localtonet HTTP tunnel documentation. Dashboard options, available regions, process types, and plan availability should always be confirmed against the current product.

Which local port should you tunnel?

Local target What it represents Remote-access guidance
127.0.0.1:3018 with Docker Compose The documented integrated browser entry point Preferred for the clearest single-endpoint workflow in this guide
127.0.0.1:3018 in development mode The FastAPI backend Use when remote backend access is specifically required and its security implications are understood
127.0.0.1:3011 in development mode The React development frontend Do not assume it provides a complete remote application without validating backend routing and development-server behavior
private-host-ip:3018 tick-stock-panel on another LAN device Use only when the Localtonet client can already reach that private address locally

Security considerations before public access

A service bound only to localhost is not equivalent to a service available through a public URL. Once an HTTP tunnel is running, internet clients that know or discover the assigned address may be able to send requests to the application. TLS at the public tunnel edge protects transport to that edge, but it does not create application authentication, authorization, or safe account permissions inside tick-stock-panel.

The available project evidence does not establish a built-in public-hostname configuration, built-in TLS setup, or a complete authentication and authorization model intended for internet exposure. We therefore do not claim that a default tick-stock-panel installation is safe for unrestricted public use. Review the running version, its authentication behavior, sensitive pages, API routes, uploaded or generated data, and configured integrations before starting a tunnel.

๐Ÿ” Protect credentials Keep data-source, AI-provider, and Localtonet credentials out of source control, logs, screenshots, browser-visible configuration, and shared support messages.
๐Ÿ‘ค Apply least privilege Use service accounts and credentials with only the permissions required by the application. Do not reuse personal or administrative secrets where a narrower credential is available.
โฑ๏ธ Limit exposure time Start the tunnel only when remote access is needed. Stop it after testing, maintenance, or a temporary sharing session is complete.
๐Ÿงช Separate development from stable use Development servers can reveal debugging information or behave differently from an integrated deployment. Prefer the verified Compose endpoint for this remote-access workflow.
Do not expose an unaudited finance application casually

Before sharing the public URL, verify whether the application requires authentication and whether every reachable route is appropriate for the intended users. If adequate access controls are not available or have not been verified, keep the tunnel stopped. A hard-to-guess URL is not a substitute for authentication, least privilege, IP restrictions, or other deliberate access controls.

Use test data first

Perform initial remote tests with non-sensitive configuration and data whenever possible. Confirm that pages do not reveal API credentials, local file paths, internal hostnames, debug traces, personal watchlists, or proprietary datasets. Check browser network responses as well as visible pages, since an API can return more information than the interface displays.

Understand the tunnel lifecycle

The Localtonet public address depends on two active components: the Localtonet client must remain connected, and the tunnel must remain started. Stopping tick-stock-panel while leaving the tunnel running normally results in a public endpoint that cannot reach its local target. Stopping the tunnel removes public access even if the local application continues running.

For temporary access, a clean shutdown order is to stop the Localtonet tunnel first, then stop tick-stock-panel. This reduces the period during which a public endpoint points to an application that is being restarted, upgraded, or reconfigured.

Troubleshooting development, Docker, and tunnel problems

The development script reports that a command is missing

Recheck all documented native prerequisites in the same terminal:

python --version
node --version
uv --version
pnpm --version

Confirm Python 3.11 or newer and Node.js 20 or newer. If a tool was installed after the terminal opened, restart the terminal. On systems with several runtime managers or installations, verify that the expected executable appears first in the shell's search path.

PowerShell will not run dev.ps1

First confirm that the terminal is in the repository root and that dev.ps1 exists. PowerShell script execution can also be affected by the host's execution policy. Do not disable organizational security controls broadly. Follow the policy approved for your device, or use an authorized development environment. The project evidence supplied for this guide does not prescribe a specific PowerShell policy change.

The shell script fails immediately

Run it explicitly through the shell from the repository root:

bash dev.sh

Check the first error rather than only the final exit message. Typical categories include a missing prerequisite, an unsupported runtime version, a failed package download, or invalid environment configuration. The exact fix depends on the reported error, so avoid deleting environments or lockfiles without understanding what failed.

Port 3018 is already in use

Stop any previous development script or Compose process. Do not run native development mode and the default Compose configuration simultaneously because both documented workflows use port 3018. If the conflict comes from an unrelated application, stop that application or inspect the current tick-stock-panel configuration for an officially supported port change. This guide does not provide an undocumented remapping.

The frontend opens on port 3011 but data does not load

Verify that the backend is running at http://localhost:3018. Review the browser console, failed network requests, backend terminal output, and .env configuration. A functioning frontend development server does not prove that the backend, external data sources, or optional AI services are working.

Docker Compose cannot connect to Docker

Start the Docker engine or desktop application, then run:

docker compose version
docker compose ps

If the client exists but cannot contact the engine, resolve that host-level Docker problem before rebuilding tick-stock-panel.

The Compose build fails

Read the earliest meaningful error in the build output. Confirm that the repository checkout is complete, the current directory contains docker-compose.yml and Dockerfile, Docker has sufficient local resources, and required package registries are reachable. Avoid repeatedly rebuilding without identifying whether the failure is a network, disk, dependency, or configuration issue.

Local access works but the Localtonet URL does not

Check the workflow in order:

  1. Confirm tick-stock-panel still responds locally on port 3018.
  2. Confirm the Localtonet client is connected.
  3. Confirm the correct device token was selected without exposing the token.
  4. Confirm the HTTP tunnel targets the right local IP and port.
  5. Confirm the tunnel was started, not merely created.
  6. Use the currently assigned public URL shown by the dashboard.

If the Localtonet client runs on a different device, do not use 127.0.0.1 as the tick-stock-panel target. On that client device, loopback points back to the client itself. Use the application's verified LAN address and ensure the client device can open it before testing the tunnel.

The public page loads but some actions fail

Compare the public browser's network requests with a local working session. The separate development frontend and backend may require origin or host behavior not established in the available documentation. If this occurs while tunneling port 3011, switch back to local-only development testing or use the documented Docker Compose interface at port 3018. Do not guess permissive cross-origin or host settings, especially on a publicly reachable service.

The tunnel stopped unexpectedly

Verify that the Localtonet client device is online and that its client application remains connected. A tunnel is available only while the selected client is connected and the tunnel is running. Also check whether the host slept, restarted, changed networks, or stopped the application. Then verify local access again before restarting the tunnel.

An update changed the setup behavior

Stop public access before upgrading. Review the current repository's README, environment template, Compose configuration, and scripts for changes. Back up any important local data and configuration before rebuilding. The available evidence does not establish a universal migration procedure or persistence guarantee for every release, so do not assume that replacing containers or removing volumes is harmless.

Frequently asked questions

What are the required versions for tick-stock-panel development mode?

The documented native development requirements are Python 3.11 or newer, Node.js 20 or newer, uv, and pnpm. Use dev.sh on a compatible shell-based system or dev.ps1 with PowerShell on Windows.

Which ports does tick-stock-panel use?

In development mode, the FastAPI backend is documented at http://localhost:3018 and the React frontend at http://localhost:3011. The Docker Compose quick start uses http://localhost:3018 as its browser entry point.

Should I use development mode or Docker Compose?

Use native development mode when editing or debugging the React and FastAPI code as separate services. Use Docker Compose when you want the documented integrated application entry point on port 3018. Compose is the clearer choice for the single-endpoint Localtonet workflow in this guide.

Which tick-stock-panel port should I expose with Localtonet?

For the integrated Docker Compose application, target port 3018. In native development mode, port 3018 is the FastAPI backend and port 3011 is the frontend development server. Do not assume that exposing only port 3011 provides a complete remote application without validating its backend routing and origin behavior.

Does Localtonet require router port forwarding or a public IP?

No. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, a public IP address, firewall changes, or VPN setup. The client must remain connected and the tunnel must be running for the public address to work.

Does the public Localtonet URL automatically add user authentication?

Do not assume that it does. An HTTP tunnel makes the configured local target reachable through a public HTTPS address, but transport exposure is separate from application authentication and authorization. Verify tick-stock-panel's current access controls before enabling public access. If suitable controls have not been confirmed, keep the tunnel stopped.

Can the Localtonet client run on another computer?

Yes, provided that computer can reach the tick-stock-panel host over the local network. Configure the tunnel with the application's actual private IP address and port 3018. Do not use 127.0.0.1 unless the client and application run on the same device.

Can I run Docker Compose and native development mode together?

Not with the documented default ports, because both workflows use port 3018. Treat them as alternative startup paths unless you have reviewed the current project configuration and intentionally implemented a supported port change.

Connect your verified tick-stock-panel service with Localtonet

Start with a working local installation, target the verified HTTP endpoint on port 3018, and keep the tunnel active only for as long as remote access is needed. Our outbound tunnel workflow lets you reach the service without opening an inbound router port or requiring a public IP address.

Get Started Free โ†’

Localtonet is a secure multi-protocol tunneling and proxy platform designed to expose localhost, devices, private services, and AI agents to the public internet supporting HTTP/HTTPS tunnels, TCP/UDP forwarding, mobile proxy infrastructure, file server publishing, latency-optimized game connectivity, and developer-ready AI agent endpoint exposure from a single unified control plane.

support