OpenAlgo: a self-hosted algo trading platform with 36 broker plugins

The problem OpenAlgo solves: strategy code that outlives a broker SDK

Most retail algo trading code is written against one broker's Python SDK. That is fine until the broker changes an endpoint, throttles a call, or you move accounts. The README frames OpenAlgo as a platform rather than a bridge, and the distinction matters: the broker-specific work is pushed into plugins that expose normalized API shapes, so a strategy talks to `/api/v1/` instead of to Zerodha or Fyers directly. The README lists 36 plugins, 35 securities integrations plus Delta Exchange for crypto derivatives.

The intended audience is broad on purpose. There is a REST surface for external platforms (TradingView, Amibroker, ChartInk, Excel, Google Sheets, and language clients in Python, Java, Go, .NET, Node.js, MetaTrader, GoCharting and N8N), a Python host for people who write scripts, a Flow builder for people who do not, an AI agent for people who would rather ask, and an options suite for derivatives traders. One self-hosted instance shares the active broker session and the market-data infrastructure across all of them.

That breadth is also the first thing to be skeptical about. A platform that serves a no-code trader and a Python quant from the same process is making a bet that the shared services are worth the coupling. The README is explicit that optional capabilities still vary by adapter and broker account, so the normalized contract is a floor, not a guarantee.

How the broker abstraction and market data actually fit together

The architecture visible in the repository is a Flask application with a React 19 frontend, plus a separate WebSocket proxy. The README states the unified WebSocket server defaults to port 8765, and that it uses a ZeroMQ message bus to normalize streaming data across brokers, with subscribe calls for LTP, Quote or Market Depth per symbol. Automatic reconnection and failover handling are listed as part of that layer.

On the request side, the README describes a maintained contract of 57 REST method and path pairs under `/api/v1`, grouped into order management (place, modify, cancel, basket orders, smart orders with position sizing), portfolio (positions, holdings, order book, trade book, funds), market data (real-time quotes, historical data, Level 5 market depth, symbol search) and advanced calls (option Greeks, margin calculator, synthetic futures, auto-split orders).

The repository layout backs this up. There are separate top-level directories for `broker/`, `blueprints/`, `restx_api/`, `services/`, `database/`, `db/`, `sandbox/`, `mcp/` and `strategies/`. The Python Strategy Host runs scripts with process isolation and IST start and stop scheduling, which means a runaway strategy should not take the web process with it. Docker Compose mounts named volumes for `db`, `log`, `strategies`, `keys` and `tmp`, so those are the stateful parts you have to think about when backing up or migrating.

Installing OpenAlgo with Docker Compose and placing a first order

The README points to the Getting Started page at docs.openalgo.in for installation and to a separate Upgrade page for upgrades. Python 3.12 or newer is required. The repository ships a `docker-compose.yaml` that builds from the local `Dockerfile` and publishes two ports.

services:
  openalgo:
    image: openalgo:latest
    ports:
      - "${FLASK_PORT:-5000}:5000"
      - "${WEBSOCKET_PORT:-8765}:8765"
    volumes:
      - openalgo_db:/app/db
      - openalgo_strategies:/app/strategies
      - ./.env:/app/.env

The Compose file also pins the container timezone and caps the thread pools that numeric libraries spawn, which is what keeps a multi-strategy container from exhausting process limits.

    environment:
      - TZ=Asia/Kolkata
      - OPENBLAS_NUM_THREADS=${OPENBLAS_NUM_THREADS:-2}
      - OMP_NUM_THREADS=${OMP_NUM_THREADS:-2}
      - NUMBA_NUM_THREADS=${NUMBA_NUM_THREADS:-2}
      - STRATEGY_MEMORY_LIMIT_MB=${STRATEGY_MEMORY_LIMIT_MB:-1024}
    shm_size: ${SHM_SIZE:-512m}

Compose defines a healthcheck against `http://127.0.0.1:5000/auth/check-setup`, so you can poll that path to know when the app is ready to accept a login rather than guessing. The web UI then lives on port 5000 and the streaming proxy on 8765 by default.

Before any live call, the README says order workflows from the REST API, hosted strategies and Flow can use Analyzer Mode. Treat that as the first real use: connect a broker, place an order in Analyzer Mode, and confirm the response shape you get back matches what your strategy expects. The API key material lives under `/api/v1/` and the repository keeps it in the `keys/` volume, which is why that volume is mounted separately in Compose.

Where OpenAlgo is the wrong tool

The most concrete limitation is exchange and broker coverage. All 36 plugins are Indian securities brokers plus Delta Exchange for crypto derivatives. If your account is with a broker outside that list, the unified API is unavailable to you, and writing a new plugin means implementing the adapter contract yourself. The README also warns that exchange coverage, authentication, market-data entitlement and GTT support vary by adapter and broker account, so two users on the same version can have different working feature sets.

Running costs are real. Docker Compose sets thread limits for OpenBLAS, OMP, MKL, NUMEXPR and Numba, and exposes a `STRATEGY_MEMORY_LIMIT_MB` variable with an example of 256 MB for a 2 GB container running five strategies. That is a project telling you strategies are memory-hungry and the defaults are tuned for a host, not a small VPS. The Compose file also requests `shm_size` for scipy and numba work. Self-hosting here means capacity planning, not just `docker run`.

The Dockerfile comments explain that the base image moved to Debian 13 trixie because bullseye and bookworm security support had ended. That is a good sign of maintenance, but it also means older pinned images in your own registry may fail to rebuild cleanly if they still reference the drained package pools.

Finally, the AI agent can place orders, but the README states it does so only with explicit approval on every single order. If you want fully unattended agent-driven execution, that is a design boundary, not a configuration gap.

OpenAlgo compared with a hosted algo platform or a plain broker SDK

The realistic alternatives fall into two groups. The first is a hosted algo platform that runs your strategies on someone else's infrastructure and holds the broker session for you. The trade-off is control: you do not manage the database, the WebSocket proxy or the upgrade cycle, but you also cannot inspect the process that touches your orders, and your strategy lives inside their runtime.

The second is a plain broker SDK. Writing directly against one broker's Python library is the shortest path to a working script. The difference in approach is where the abstraction sits. With an SDK, the broker's data structures are your data structures, and a broker migration is a rewrite. With OpenAlgo, the broker is behind `/api/v1/` and a WebSocket proxy on 8765, so the migration is a plugin swap, at the cost of running a Flask app, a message bus and six data stores yourself.

OpenAlgo's own answer to the second group is the Python Strategy Host under `/python`: paste a script into the in-browser editor, schedule it on IST start and stop times, and run several in parallel with process isolation. That is closer to a small internal job runner than to a library, which is the honest way to read the project. You are adopting an application, not importing a package.

Licence, upgrades and the maintenance you are signing up for

OpenAlgo is AGPL-3.0. The practical consequence for a self-hoster is that if you modify OpenAlgo and let users interact with it over a network, the licence's network clause is the part to read carefully with your own counsel. Building private strategies that call the API is a different question from modifying the platform itself, and the repository does not answer that for you.

The project is not archived and the last push was on 2026-09-10, so the codebase is moving. Recent releases include openalgo-strategy-rms-agent (v2.0.2.3) on 2026-09-06, openalgo-eventlet-stability-security (v2.0.2.2) on 2026-08-29 and openalgo-flow-upgrade (v2.0.2.1) on 2026-08-21. The names are informative: one release is explicitly about eventlet stability and security, and another about strategy risk management. `pyproject.toml` pins `openalgo==2.0.5` among its dependencies, and the project version there is 2.0.2.5.

That cadence has a cost. Three releases in under a month means you should expect to read release notes before upgrading rather than pulling `latest` on a whim, and the README's Upgrade Instructions page exists for that reason. The Compose file pins `TZ=Asia/Kolkata` and schedules strategies in IST, so a host in another timezone will still run on Indian market hours, which is the correct default for this broker list but worth knowing before you debug a scheduler.

Editorial conclusion

Adopt OpenAlgo if you already run Python strategies against a single Indian broker and want the same code to survive a broker switch, or if you want options analytics and a webhook endpoint in the same process. Do not adopt it if you need a vendor to hold your credentials, if your broker is not among the 36 plugins, or if you cannot host a Flask app with a persistent database and a WebSocket port. Before committing, verify three things: that your broker plugin supports the specific calls you need (the README notes optional capabilities vary by adapter), that your account has the market-data entitlements the analytics pages assume, and that you are comfortable with AGPL-3.0 obligations for whatever you build on top.

Frequently asked questions

Official sources

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