Shioaji Pro's stop-loss triggers run in the browser tab, not on the server

Stop-loss and take-profit triggers are monitored by the page

Of everything in this terminal, the single most important sentence for a live trader is in the safety notes: stop-loss and take-profit are client-side trigger orders, monitored only while the page is open.

The mechanism is described in the chart features. You place them on the chart as a dashed line, they are cancellable, and when the price is reached the trigger sends a market order.

That last part is the risk. A client-side trigger has no existence when the tab is closed, when the browser is suspended, when the machine sleeps, or when the connection drops and the price moves while the page is reconnecting. The order is not at the exchange; it is a conditional in JavaScript that has not fired yet.

The neighbouring features are more reassuring. Stop-loss brackets can be set to fire automatically after a position fills, so the two-step sequence of fill then protection does not depend on you being present for the second step. There is a kill switch with a per-order cap, a daily loss cap, and a one-click order lock. Double-pressing escape cancels everything. Positions can be closed or reversed in one action, and unfilled orders can be resized.

The disconnect behaviour completes the picture: when the stream reconnects it re-subscribes every product automatically, and while disconnected the order buttons are locked on their own. So the terminal refuses to let you trade into a broken connection, which is the right default and does not help with the trigger problem above.

The install path is short and the whole thing runs on one machine. A node runtime and a package manager, a copy of the broker's own command line client installed as a tool, and then the server:

shioaji server start
shioaji server check

A status subcommand alongside the start command is the one to reach for when nothing is streaming, because it answers whether the problem is the server or the browser.

Flash orders are locked and the server starts in simulation

Two defaults are worth internalising before anything else.

The first is the environment. The server starts in simulation mode, which the documentation calls paper trading, and orders in that mode do not move real money. Switching to production is a flag on the start command and requires a CA certificate to be configured first, with an explicit instruction to test the whole thing in simulation before doing so.

The interface makes the state visible rather than leaving it to memory. A badge in the title bar shows simulation in one style and production in another, and the production badge is red. That is a small design decision with a large payoff: there is no moment where you have to remember which mode you are in.

The second default is the flash order panel, the ladder where clicking a price submits immediately. It ships locked and has to be enabled by hand. The safety switch is part of the feature rather than a setting you are expected to find, and there is a mode that tiles several watchlist symbols into multiple panels at once, which is the version to treat with the most suspicion.

Chart click-to-order is described as one-shot, so it does not stay armed the way the flash panel does.

The remaining line of the safety section is the obvious one and worth repeating because it is the only one with legal weight: every order placed in production is a real trade and you bear the risk yourself.

The manifest says zero point zero and the tags say zero point one fifty

The package manifest is not the source of the version, and it says so.

The version field reads 0.0.0. The release tags on the repository are three minor series ahead of nothing, at a released 0.1.50 with two earlier ones in the preceding two weeks. So the manifest has never tracked the releases and there is nothing in it that changed.

There is a reason it can stay at zero. The package is marked private, which means it is never published to a registry, so the version field has no consumer. The version that identifies a build is the release tag.

For anyone tracking the project, the tags are the only version signal available, and they are moving quickly: three releases inside a fortnight in the published record.

The repository also carries a file whose only job appears to be pinning something else, a file with the broker's own client version in its name. That suggests the terminal tracks a specific version of the command line client, which makes sense given that the client is the thing providing the API and the local server.

Together those three things, the private manifest, the moving tags, and the pinned client version file, are the three numbers to record if you want to reproduce an installation.

Nine desktop plugins and a feature flag client in a web only repository

The readme is emphatic that the desktop shell is not in this repository, that the interface is fully open source, and that cloning and building gives you a complete web terminal.

The dependency list tells a different story at the edges. Nine packages from the desktop toolkit appear in the runtime dependencies: the core bridge, and plugins for dialogs, filesystem, HTTP, notifications, processes, the shell, a key value store, and the updater. The build tooling for that toolkit is a development dependency alongside the TypeScript compiler and the test runner.

None of that contradicts the readme. It means the same source tree compiles for both targets, so the desktop-only imports are resolved at build time and the web build simply never reaches them. The cost is that a web-only installation pulls nine packages it does not use.

The other unexplained entry is an experimentation client from a feature flagging service, in the runtime dependencies with no mention anywhere in the readme. If you self-host this terminal, that is a third party in the dependency graph that the documentation does not account for.

The analytics variable makes the picture clearer rather than murkier. There is an optional environment variable for a web analytics measurement identifier, and the example file says explicitly that it is used only for an app open event and a heartbeat event, and only so that the analytics realtime view can show how many people are active in the last few minutes. That is a narrow, disclosed use, and it is off unless you set the variable.

An uploaded custom app lives in the server's memory

The terminal can be built and pushed into a running Shioaji server as a built-in app rather than served separately. The build step sets a base path, and then a script collects the built files and posts them to an endpoint.

What the documentation says about the result is the part to note: the uploaded app is stored in the server's memory, so after the server restarts you have to upload it again.

That is a reasonable design for a local single-user server, and it has a clear operational consequence. If you deploy this way, a server restart, a crash, or a deliberate restart to switch environments takes your app with it. There is no persistence step and no startup hook described.

The same section tells you what the app's own persistence is like, indirectly. There is a server management interface in the desktop build that can start, stop, and restart the server, show health and the process identifier and port, show when the token expires, and take your API key, which is stored in the local application data folder. So the credential lives on disk in one place and the front end lives in memory in another.

For a personal workstation setup that is fine. For anything you expect to survive a reboot, the upload step belongs in your start-up sequence.

AGPL with a commercial exit and a label gated fork pipeline

The licence is the strongest copyleft variant of the GNU family, and the readme spends more words on it than on most of the features.

The permissions are the ordinary ones: use, modify, learn from, and fork freely.

The condition is the part that matters for a trading terminal, because it explicitly covers network service. Any modification or derivative based on the project, including hosting it as a web service for other people, has to be published in full under the same terms.

The exit is explicit too. If you want a commercial use that is not open sourced, you contact the brokerage to negotiate a commercial licence, and the readme describes the arrangement as dual licensing.

External contributions are covered in the same section. Submitting a pull request means you agree to licence your contribution under the same terms and to grant the maintainers the right to include it in dual-licensed distributions. So the contributor agreement is one sentence long and it is a licence grant, not a code of conduct.

One process detail that will bite a first-time contributor: the continuous integration run for the desktop build on a forked pull request requires a maintainer to add a specific label before it executes. A fork that appears to have a failing or hanging pipeline has usually not been approved yet.

Custom indicators run in a worker that is told to block infinite loops

The charting side is the deepest part of the terminal and the part anyone building on it will care about most.

There are twenty-one built-in indicators. On the main chart: moving averages, a channel, a parabolic stop and reverse, and a trend overlay. In separate sub-panels: the usual oscillators. They come with a picker in the style of a charting application you have used, a settings window, and live values in the chart legend rather than a separate readout.

Custom indicators are the interesting part. You write them in JavaScript against a function library, declare your outputs with a plotting call or a horizontal line call, and the terminal detects the output lines itself so you do not have to register them. They then get the same treatment as built-ins: settings, styling, and saving as favourites.

The safety mechanism is the sentence worth quoting. Validation runs in a web worker sandbox, and the sandbox automatically blocks infinite loops.

That matters more than it first appears. User indicator code is arbitrary code running in the same origin as an application that holds brokerage credentials and can place orders. A worker isolates the execution from the interface thread, which stops a frozen chart, and the loop guard stops the worker itself from spinning forever.

What it does not do is stop the code from reaching the network or the page's own state. The isolation is about responsiveness and termination, not about permissions.

Editorial conclusion

Shioaji Pro is worth looking at if you trade Taiwan equities or futures through this broker and want a terminal you can modify, because the interface, the quote stream, and the order path are all in an open repository under a strong copyleft licence. Read the safety section before you connect a real account, because two behaviours are browser-side: stop-loss and take-profit orders are client-side triggers that only monitor while the page is open, and the order buttons lock themselves automatically when the connection drops. Both are documented, both are reasonable, and both fail in the same direction. Before you fork it commercially, read the licence: any modification served over a network must be published under the same terms, and a commercial licence is negotiated separately. And before you expect the desktop build, the agent features, or the backtester, note that those ship as release binaries and are not in the repository.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Sinotrade/shioaji-pro-app on GitHub