Getting started
IndicaView is a hosted service. There is nothing to install and nothing to self-host: open the workspace in a browser and you are working.
Signing in is optional. A guest reaches the chart, the optimizer and the analysis workspace with no account at all. An account adds a profile and a security tab, and it is where your credit balance and billing details will live once usage metering is switched on. See Authentication.
Running it locally (development)
Everything below this line is for developing IndicaView, not for using it. The sections describe how to bring the project up on a workstation so you can change it and run the test suites.
The project has two runtimes: Node.js for the browser application and Python for the command-line track. The browser half works on its own; you only need Python if you want sweeps, hyperparameter search or prop-firm evaluation.
Prerequisites
| Tool | Version | Needed for |
|---|---|---|
| Node.js | 20.x LTS (20.19.0 pinned by the installer) | The browser workspace, the optimizer, pinets-cli |
| npm | 10.x | Package installation |
| Python | 3.11+ | Sweeps, hyperopt, prop-firm evaluation |
| uv | 0.4+ | Python environment and dependency resolution |
package.json enforces node >=20.0.0 and npm >=10.0.0.
Route 1 — the scripted installer (Windows)
scripts/install.ps1 brings the whole environment up without administrator rights. It
installs everything under %LOCALAPPDATA%\Tools and adds those directories to your user
PATH, so nothing touches system directories.
Why the installer edits your user PATH, and why a new terminal is then required
The tools land in %LOCALAPPDATA%\Tools, a per-user location, so putting them on your PATH
means appending to the user PATH and nothing else. There is no machine-wide write and no
administrator prompt. Node.js 20.19.0 and the uv 0.4.18 binary are both installed that way.
A process captures its environment when it starts. The PowerShell window you ran the installer
in is already holding the old PATH, so it cannot see the append even though the value has
been written. A new terminal is a new process, and it reads the updated value — until you open
one, Node and uv stay unresolvable in that window.
From a normal PowerShell in the project root:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass.\scripts\install.ps1In order, it:
- Forces TLS 1.2 for the session (older PowerShell defaults break downloads from nodejs.org, GitHub and python.org).
- Downloads Node.js 20.19.0 portable and puts it on your user
PATH. - Downloads the uv 0.4.18 single-file binary and puts it on your user
PATH. - Installs Python 3.11 through
uv python install. If that fetch fails it falls back to the python.org 3.11.9 embeddable build. - Runs
npm installin the project root. - Creates
.venvwithuv venvand installsrequirements.txtinto it. - Runs a sanity gate:
pinets-cli --version, then the offline-only pytest subset (test_dataset,test_orchestrator_ranking,test_pine_lookahead,test_license_hygiene).
What the sanity gate runs, and what it does not cover
Two things, in that order:
pinets-cli --version
# then the four offline modules:
test_dataset
test_orchestrator_ranking
test_pine_lookahead
test_license_hygieneThe second is selected to stay offline: none of it reaches the network. The full pytest
suite is wider — it also contains the pinets-cli integration tests, which execute real
subprocesses and take noticeably longer.
So a green gate is a fast environment check, not a suite result. It does not exercise the CLI integration path, and nothing it does tells you that path works. For that, the full suite.
Route 2 — manual
If you already have Node 20 and Python 3.11 installed, this is the whole thing.
What the manual route genuinely skips
It is not the scripted install minus the downloads. Route 1 does four things that have no equivalent here:
- Forces TLS 1.2 for the session, because older PowerShell defaults break downloads from nodejs.org, GitHub and python.org.
- Downloads the portable Node.js 20.19.0 and the uv 0.4.18 binary and puts both on your
user
PATH. - Installs Python 3.11 through
uv python install, falling back to the python.org 3.11.9 embeddable build if that fetch fails. - Runs the sanity gate.
What both routes share is the work that decides whether the app runs: npm install with its
vendor step, a .venv with requirements.txt installed into it, and the launch step.
Everything else in Route 1 is provisioning you are supplying from elsewhere.
1. JavaScript dependencies
npm installThis is where the vendored browser bundles come from. A postinstall hook runs
scripts/copy-vendor.js, which copies prebuilt bundles into app/vendor/:
| Bundle | Source | Licence |
|---|---|---|
vela.global.js | @luxalgo/vela | LuxAlgo |
vela-pinets.global.js | @luxalgo/vela-pinets | LuxAlgo |
echarts.min.js | echarts | Apache-2.0 |
monaco/ and vs/ | monaco-editor | MIT |
app/vendor/ is git-ignored and regenerated on every install — it is never committed.
Every install rebuilds `app/vendor/`, and none of it is in the repository
The postinstall hook runs scripts/copy-vendor.js on every npm install, copying
vela.global.js, vela-pinets.global.js, echarts.min.js and the Monaco editor’s
monaco/ plus its mirrored vs/ into app/vendor/.
Because the directory is git-ignored, it is never committed and a clone never carries it.
npm run dev runs the vendor step as well, before it serves app/. A clean checkout plus
npm install is enough to get every bundle back.
Monaco’s worker-spawning code builds URLs like /vendor/vs/base/… directly,
while the AMD loader maps vs to ./vendor/monaco. To make both
paths resolve from a plain static server, the vendor script also mirrors
monaco/ to a sibling vs/. If the editor loads but its workers
404, this mirror is the thing to check.
Verify the CLI is available:
npx pinets-cli —versionnpx pinets-cli —help# AGPL — local use only2. Python environment
uv venvuv pip install -r requirements.txtrequirements.txt covers the orchestrator (pandas, numpy, pyarrow, polars, plotly), config
loading (pyyaml), HTTP (requests), dotenv support, Optuna for hyperparameter search, and
pytest.
3. Launch the workspace
npm run devThat runs the vendor step and then http-server app -p 8080 -c-1. Open
http://localhost:8080 .
npx http-server app -p 8080 -a 127.0.0.1 -c-1start.bat in the project root is a convenience launcher: it pre-checks that http-server
is installed and that port 8080 is free before starting it. It does not pass -a.
4. Optional — the Windows launcher
.\start.batOptional configuration
Nothing is required, but .env is the place for overrides. Copy the template:
Copy-Item .env.example .env.env is git-ignored (.env.local and .env.*.local too), so it is safe for real values.
The full variable list is in Environment variables.
Verifying the install
# Browser half: does the vendor step work, and does the page serve?
npm run dev
# then, in another shell:
curl -I http://localhost:8080/
# CLI half: does a real run complete?
npx pinets-cli run app/strategies/ema_cross.pine \
--symbol BTCUSDT --timeframe 60 --candles 1000 --warmup 200 \
--format full --quiet --clean > out.json
# Python half: does the test suite pass?
.\.venv\Scripts\python.exe -m pytest -qThe full pytest suite includes the pinets-cli integration tests, which
execute real subprocesses and take noticeably longer than the offline subset the installer
runs. Use the offline subset for a quick gate and the full suite when you actually want to
verify the CLI path.
Where things land
<project root>/
app/vendor/ vendored bundles (git-ignored, regenerated)
.venv/ Python environment (git-ignored)
.env your local config (git-ignored)
data/ohlcv_cache/ cached Parquet datasets (git-ignored)
results/<run-id>/ sweep artifacts (git-ignored)
propfirm/firms_cache/ cached firm directory (git-ignored)Every generated artifact lives in an ignored directory, so a clean checkout plus
npm install is always enough to recover.
Next
- Quickstart — run your first backtest, then your first optimizer run.
- Troubleshooting — if a step above failed.