OpenAlgo: A Self-Hosted Flask and React Trading Platform With 36 Broker Plugins

The Problem OpenAlgo Targets: Strategy Code Trapped Inside One Broker Adapter

Most retail algorithmic trading setups break at the same seam. You write a strategy against one broker's Python SDK, and the strategy is now welded to that SDK. Switching brokers means rewriting order placement, position queries, historical data calls and the WebSocket subscription logic. OpenAlgo's answer is a normalized contract: 57 REST method and path pairs under /api/v1, plus a unified WebSocket proxy server on port 8765 by default, with 36 broker plugins behind them. The README lists 35 securities integrations plus Delta Exchange for crypto derivatives. The audience is specific. It is the trader who already has a broker account in that list, runs their own machine or VPS, and would rather own the execution path than rent it. The README also positions the project as more than a bridge: it describes four trading surfaces sharing one active broker session, one market-data infrastructure and six operational data stores. That claim is the interesting part, because a shared session is exactly what makes multi-surface trading convenient and what makes failure modes non-local.

Five Surfaces, One Broker Session: How the Pieces Connect

The architecture visible in the README is a Python Flask backend with a React 19 frontend, and five entry points layered on top. The REST API at /api/v1/ is the external contract, aimed at TradingView, Amibroker, ChartInk, Excel, Google Sheets, and clients in Python, Java, Go, .NET, Node.js, MetaTrader, GoCharting and N8N. The Python Strategy Host at /python lets you paste a script into an in-browser CodeMirror editor, schedule it on IST start and stop times, and run several strategies in parallel with process isolation and real-time logs. Flow at /flow is a node editor built on xyflow/React Flow, with condition nodes exposing true/false and yes/no edge handles and {{var}} interpolation with list indexing. The AI Agent at /agent reads market data through OpenAlgo's own services and, per the README, can place orders only with explicit approval on every single order. The Options Trading Suite at /tools holds twelve analytical tools including Strategy Builder, Option Chain, IV Smile, Max Pain, Vol Surface, GEX dashboard, OI Tracker and Straddle PnL simulator. The connective tissue is ZeroMQ: the README describes a ZeroMQ-based message bus for normalized data distribution, with automatic reconnection and failover handling. That is a sensible choice for fanning one broker feed out to several consumers, and it is also the component whose health determines whether all five surfaces degrade together.

Getting It Running: Python 3.12, the /api/v1 Contract and the 8765 WebSocket

The hard constraint is stated plainly in the README: Python 3.12 or newer. That is not a soft recommendation, and it rules out older distributions where 3.12 is not packaged. The repository lists a PyPI package named openalgo, and the README's Quick Links point to an Installation Guide and a separate Upgrade Guide under docs.openalgo.in, so installation and upgrade are documented as distinct procedures rather than one script. The README does not reproduce the install commands inline, so treat the documentation site as the source of truth for the exact sequence. What the README does give you is the shape of the integration surface. External platforms call /api/v1/ for order management (place, modify, cancel, basket orders, smart orders with position sizing), portfolio queries (positions, holdings, order book, trade book, funds), market data (real-time quotes, historical data, Level 5 market depth, symbol search) and advanced operations including an option Greeks calculator, margin calculator, synthetic futures and auto-split orders. Streaming clients connect to the unified WebSocket proxy, port 8765 by default, and subscribe to LTP, Quote or Market Depth per symbol. Order workflows from the REST API, hosted strategies and Flow can pass through Analyzer Mode before live execution, which is the feature to understand first if you are migrating from a setup where nothing sits between a signal and a live order.

Plugin Count Is Not Plugin Parity

Thirty-six plugins sounds like breadth. The README undercuts that reading in a single sentence: exchange coverage, authentication, market-data entitlement, GTT support and other optional capabilities vary by adapter and broker account. It repeats the caveat for the options tools, noting that those pages use the active broker connection and that broker market-data entitlements and exchange coverage still apply. This is the honest framing, and it is also the main practical risk. A normalized API shape does not mean normalized behaviour. Two traders on different plugins can run the same strategy script and get different results, not because the code changed but because one adapter exposes Level 5 depth and the other does not, or one supports GTT orders and the other does not. The README's own phrasing about "optional operations varying by adapter" confirms this is a known design boundary rather than a bug. If you are evaluating OpenAlgo, the question is not how many brokers are listed. It is which operations your broker's adapter actually implements, and that answer lives in the per-broker documentation, not in the plugin count.

Where the Design Bites: Shared Sessions and Self-Hosting

The unified session is the selling point and the single point of failure. Because the REST API, the Python host, Flow and the options pages all reuse the active broker connection, a broker-side logout or a token expiry does not take down one surface. It takes down all of them. The README notes automatic reconnection and failover handling on the ZeroMQ bus, which addresses transport-level drops, but reconnection logic cannot restore an expired broker session credential. Anyone running this unattended needs to think about how the active session is refreshed and what happens to a scheduled strategy when it is not. The second constraint is the self-hosting decision itself. There is no hosted tier described in the material, so the operational burden (process supervision, log retention, upgrades, and the fact that your strategy scripts sit on a machine you administer) is yours. The README leans into this, describing the Python host as needing "no external server, no Docker, no cron", which is true in the sense that scheduling is built in, but it does not remove the requirement that something keeps the Flask process alive. Third, the AI agent is deliberately gated: orders require explicit approval on every single order. That is a reasonable default, and it also means the agent is not an unattended execution path. If your use case is fully hands-off automation driven by a model, this design does not provide it.

Alternatives: What Changes If You Drop the Unified Layer

The obvious comparison is going direct. Use your broker's own Python SDK and skip the abstraction. The difference is concrete: you get every broker-specific feature the moment it ships, including proprietary order types and any data entitlement your account carries, with no adapter in between to lag or to omit an operation. You also write your own order routing, your own WebSocket reconnection, your own scheduling, and you rewrite all of it if you change brokers. OpenAlgo's value is precisely the thing you give up in that trade: one contract across 36 plugins, a shared market-data bus, and a browser-based strategy host with IST scheduling and process isolation. A second comparison is the hosted algo platform, where someone else runs the process. That removes the self-hosting burden and the AGPL-3.0 question, and it also removes your ability to read the execution code, to keep strategy logic on your own hardware, and to run the options analytics suite against your own broker session. OpenAlgo sits between these two: more abstraction than the direct SDK, more control than a hosted service, and more operational responsibility than either.

Licence, Upgrades and What the AGPL-3.0 Means for a Modified Instance

OpenAlgo is licensed AGPL-3.0. That is a strong copyleft licence with a network clause, which matters here because the whole product is designed to be reached over a network. If you run an unmodified instance for yourself, the practical effect is minimal. If you modify OpenAlgo and let other users interact with it over a network, the AGPL's source-availability obligation is the thing to read carefully, and the right move is to read the licence text and, where the stakes are real, talk to a lawyer. Nothing in this review is legal advice. On maintenance, the release cadence visible in the repository is frequent and narrowly scoped: openalgo-strategy-rms-agent v2.0.2.3, openalgo-eventlet-stability-security v2.0.2.2, and openalgo-flow-upgrade v2.0.2.1, all within roughly three weeks in August and September 2026. The naming tells you something useful. One release is a stability and security fix to the Eventlet layer, which is the concurrency mechanism under Flask. Another is a risk management agent. Another touches Flow. That pattern suggests active development across surfaces rather than a project resting on a single maintainer's spare time, and it also means upgrade cost is real: the README maintains a separate Upgrade Guide, and a platform that shares one broker session and six data stores across five surfaces is not something you upgrade casually mid-session. Budget for reading release notes before each bump, particularly anything touching Eventlet.

Editorial conclusion

Adopt OpenAlgo if you already trade through one of its 36 broker plugins, want to keep strategy code on your own hardware, and can accept AGPL-3.0 obligations. Do not adopt it if you need a hosted service with an uptime commitment, or if your broker is not on the plugin list. Before committing, verify three things against docs.openalgo.in: that your specific broker adapter supports the operations you need, since exchange coverage, authentication, market-data entitlement and GTT support vary by adapter; that your Python environment is 3.12 or newer; and how you intend to handle the AGPL-3.0 network-copyleft clause if you plan to expose a modified instance to other users.

Official sources

1. License: AGPL-3.0
2. marketcalls/openalgo on GitHub
3. Project website
4. README
5. Releases