Northstar: a Java quantitative trading platform for Chinese futures markets

What Northstar is built to do

Northstar is described as a professional grade quantitative trading software for futures, stocks, forex and crypto trading scenarios, implementing automatic trading, and it supports both fully automatic and semi-automatic use.

The platform is aimed at three groups: professional quantitative traders, full stack technical enthusiasts, and small private fund technical teams. A demo version of the site is published for evaluation.

The feature set is organised around a trading day. Programmatic trading covers module management, strategy writing in Java, an indicator framework, run state visualisation, automatic risk control, capital isolation, strategy performance measurement and strategy circuit breaking. Simulated account trading supports local simulation against live market data, with both manual and programmatic trading, and it also supports local simulation over historical playback, which is described as equivalent to replay training, plus account performance statistics.

Beyond that there is historical market data playback across six major markets, domestic futures, A-shares, Hong Kong stocks, US stocks, crypto and forex, with minute level precision history available for a fee. The front end console provides a single tenant monitoring dashboard, gateway and module configuration, chart visualisation, log search and a Chinese and English language switch. An AI assistant can connect to mainstream large model platform APIs, with existing integrations for Deepseek, Kimi and OrcaRouter. Alert notifications go out through WeCom and email. Custom gateways let you connect to more exchanges yourself, and the project supports private deployment.

The strategic context is the Chinese market. The repository description positions it as an open source Java alternative to the established commercial futures trading platforms, and it acknowledges that lineage in the acknowledgements, crediting the author of redtorch, from which it retains a small amount of source, and the author of klinechart for the K-line front end library and related technical support.

The event driven plugin architecture and the module layout

The project architecture is event driven with plugin style development, and the repository layout makes that concrete.

The northstar-main/ module is the server, and the documentation states that the northstar project is the server side, which includes the web monitoring console. The tree also holds northstar-api/, northstar-copilot/ for the AI assistant, northstar-gateway-playback/ and northstar-gateway-sim/ for the playback and simulation gateways, northstar-strategy-example/ as a strategy example, and northstar-doc/. The pom.xml at the root is the multi module build file, and startup.sh is the launch script, with env.sh and env.ps1 for environment setup.

The web console is a separate thing and this matters. The documentation states that the front end project is not open source, and that you can build your own console with the help of a large model, or pay to buy it. The northstar-monitor-next entry in the tree is a git submodule, which is how a component that is not open source still appears in the build.

The gateway concept is the extension point. Two gateways are documented as examples, a CTP gateway and an OKX gateway, each living in its own repository under the NorthstarQuant organisation. The CTP gateway is the path into the Chinese futures market, and the OKX gateway is the path into crypto. The gateways are separate projects on purpose, so the platform core does not have to know about any particular exchange.

The database choice is deliberately light. The documentation says the database is H2, because historical market data depends mainly on a data service and locally only a small amount of account configuration information is kept. That is an important architectural statement: Northstar is not a system that stores years of ticks on your own disk.

Backtesting, chart analysis and the strategy workflow

The backtesting capability is described in three tiers: large scale batch backtests, fast backtests, and high precision backtests. Two further features support the same workflow. Chart analysis offers multiple charts in one column, multi period linkage, common indicators and drawing tools, custom indicators written as JavaScript scripts, and placing orders by drawing on the chart.

Two details in the documentation change how you write a strategy. When writing strategy logic, if you need time properties you must use the timestamp carried by the TICK market data, otherwise backtests will be inaccurate. And the server clock should be set to Beijing time, because an inaccurate clock affects market data reception.

The strategy side is Java. The documentation states that the user needs to develop their own trading strategies and needs a certain level of Java basics, and the northstar-strategy-example/ module in the tree is where an example lives. Custom indicators are JavaScript scripts, so the two extension languages are different, one for strategy logic and one for chart indicators.

There is also a substantial disclaimer at the top of the documentation, which is worth taking seriously as a signal about the project's stance. The project is technical sharing only and does not constitute trading advice, and the user must understand the trading risks and the relevant legal provisions before trading and is responsible for their own behaviour. The same disclaimer is repeated near the end, where it states that the project is technical sharing and is not responsible for trading behaviour.

Running environment, memory requirements and the deployment notes

The documentation's deployment guidance is short and specific. It suggests using a Linux cloud server, or a Windows system, and states that the macOS system does not support the CTP and XTP dynamic libraries. That is a hard platform limit, not a preference, and it rules out a Mac for anyone trading through those gateways.

The memory note is equally concrete. The project uses a cache, so the maximum heap memory should not be less than 2G, otherwise there will be an OOM. The server is a Java application with a multi module Maven build, launched through startup.sh with the environment prepared by env.sh or env.ps1.

Two operational warnings deserve attention. The documentation advises against restarting the program during trading hours, because market data is received in real time and a restart causes that day's K-line data to be missing. And it notes that master is not a stable version, with the stable version to be identified by tag. For a system that connects to a live market, that second point is the one to plan around, since a development branch is exactly what you do not want to run against money.

Private deployment is listed as a product feature, so running the platform on infrastructure you control is an intended mode rather than a workaround.

Where Northstar is the wrong tool

The first limit is the open source boundary, and it is the one most likely to surprise. The server is open source under the GPL-3.0 licence, but the front end console is not, and the documented options are to build your own console, presumably with the help of a large model, or to pay for one. If your requirement is a complete, supportable product, this repository alone does not give you that.

The second limit is that the platform does not include strategies. The documentation is explicit that the user develops their own trading strategies. So Northstar is infrastructure: gateways, backtesting, risk control, monitoring and alerting, with an empty strategy layer that you fill. For a team that wants a finished trading system, the work you have to do is most of the interesting part.

The third is the historical data cost. Minute level precision historical market data is available but has to be purchased, and the history itself depends on a data service rather than being in your local database. That is a reasonable commercial model, but it means the backtesting and replay features are not self contained.

The fourth is platform reach. macOS is excluded because of the CTP and XTP dynamic libraries, so a developer on a Mac cannot run the full stack locally.

Compare that with the commercial platforms the project positions itself against, which sell a finished, supported product in exchange for a licence fee. The difference in approach is that Northstar gives you the Java server, the gateway plugin model and the risk and monitoring layer, and leaves the console and the strategies to you, so the trade is licence cost against work and support.

Licence, the log and notification pipeline, and the upgrade path

Northstar is released under the GPL-3.0 licence, with the LICENSE file at the repository root. The strong copyleft terms matter here in a specific way. If you distribute a modified version of the server, you have to publish the corresponding source, and the obligations of the bundled components come on top of that. The repository also carries an AGENTS.md file at the top level, which suggests the project expects an agent to work with it. Read the LICENSE file yourself and take your own advice on how the terms apply to a private deployment inside a company, because running the software for your own trading is a different question from distributing it.

Logging is separated by design. Platform logs and module logs are isolated, and the console can control the log printing level in real time, which is the difference between a service that floods you and one you can debug during a session. Alerts go out through WeCom and email, and the strategy monitoring view in the console is one of the screenshots the documentation highlights.

On upgrades, the guidance is unambiguous: use a tag rather than master. The repository publishes no GitHub releases, so the tags in the repository are the reference points. The last push was on 2026-10-11, so the tree is current, and the CHANGELOG-style record is not something the documentation points to, so reading the tag differences is on you.

The repository also uses git submodules, visible in the .gitmodules file and in the northstar-monitor-next entry, which means a clone has to initialise submodules to be complete. That is a small operational step, and it is also a reminder that the console component is a separate artefact with its own update cycle.

Editorial conclusion

Northstar fits a quantitative trader or a small technical team that already writes Java, wants a private deployment of a futures trading stack, and is prepared to run the server side of the platform themselves. It does not fit a team that needs a complete product out of the box, because the web console is not open source and must be built or bought, and it does not fit a Mac user because the CTP and XTP dynamic libraries are unsupported there. Before adopting it, check the tag rather than the master branch, size the JVM heap at 2G or more because of the cache, and confirm your own trading strategy code covers what the platform does not, since the maintainers state that strategy development is the user's job.

Frequently asked questions

Official sources

1. dromara/northstar on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README