OpenBB Financial Data Platform
1. Project Introduction
OpenBB is an open-source financial data platform with the core philosophy of "connect once, use anywhere" — integrating any data source and serving multiple application scenarios through a unified API. This project is deeply localized on top of the open-source OpenBB framework to adapt it to the Chinese A-share market, and is deployed as an online service.
Online Access
- Project site: https://openbb.astock.com.cn/
Localization Highlights
- The upstream framework mainly targets international markets; this project fills the A-share data gap through a localization solution
- All market data is stored and read locally, independent of external data sources, keeping the service stable and controllable
2. Core Capabilities
| Domain | Description |
|---|---|
| Data acquisition | Stocks, cryptocurrencies, macroeconomics, futures/options, ETFs/indices, news |
| Data analysis | Technical indicators (SMA/EMA/RSI/MACD/BOLL etc.), financial metrics (P/E, P/B, ROE, DCF), quantitative backtesting, portfolio optimization, risk-return analysis |
| AI integration | LangChain tool functions, MCP server support |
| Multi-endpoint access | Python API, REST API, Jupyter Notebook, Excel add-in, CLI |
| Visualization | K-line charts, technical indicator charts, interactive dashboards |
3. A-Share Localization
- Full local market data: 2,348 Shanghai and 2,951 Shenzhen stocks, 5,299 in total, with daily and minute K-lines
- Stock code autocomplete: prefix-triggered candidates with keyboard navigation and configurable limits
- Exchange auto-detection: Shanghai (600/601/603/605/688/689) and Shenzhen (000/001/002/003/300/301) recognized by code prefix
- Technical indicator computation: common indicators and visualization on local data
- Online dashboards: data dashboard, momentum strategy, portfolio optimization (2~10 stocks across markets) and per-stock lookup pages
4. Uptime and Stability
The online site has been running long-term: the current server has run 106 days 21 hours, core services with zero restarts, and the historical best is 154 days of continuous operation.
4.1 Key Stability Metrics (2026-08-31 measured)
| Metric | Value |
|---|---|
| Server continuous run | 106 days 21 hours |
| Core service restarts | 0 |
| Site full-chain availability | home / dashboard / direct dashboard all 200 |
| System load | very low (load average ≈ 0.1) |
| Security patches | 4 high-risk CVEs fixed in the last half year |
| Overall rating | Stable (A-) |
4.2 Historical Faults & Review
- 2026-05-16 dashboard 502 fault: after a server reboot the dashboard service did not auto-start; fixed with managed auto-start hosting. No recurrence for 106 days.
- Lesson learned: manual process start-up is only temporary; automated hosting truly solves "dies on reboot".
4.3 Security Hardening
| Vulnerability | Status |
|---|---|
| NGINX Rift (CVE-2026-42945) | ✅ Upgraded to 1.30.1, immune |
| Copy Fail (CVE-2026-31431) | ✅ Kernel upgraded to 6.1.172-1 |
| Dirty Frag series (CVE-2026-43284/43500) | ✅ Kernel upgraded to 6.1.172-1 |
4.4 Current Main Risk
Disk usage at 97% is the main short board (a capacity issue rather than stability); cleaning old logs and historical backups will sustain long-term stable operation.
5. System Runtime Architecture
5.1 Architecture Source
The following architecture information was generated by Archify from analysis of the project's real deployment structure. Every module maps to an actually running component, giving the diagram a verifiable, explainable diagram-to-deployment correspondence.
- Full interactive architecture diagram (Archify HTML output): Open architecture diagram
Interactive diagram notes
Open the link above to view the full interactive architecture diagram, supporting node search, route tracing, semantic views, theme switching, zoom/pan and presentation playback.
5.2 Architecture Overview
5.3 Core Components
| Component | Type | Role |
|---|---|---|
| Browser / Frontend | External | Streamlit Web UI |
| Streamlit Frontend | Frontend | pages + layout |
| FastAPI Platform API | Backend | REST + command runner |
| Market Data Services | Backend | equity / crypto extensions |
| Data Sync Service | Backend | provider interface + fetch |
| Upstream Data Sources | External | providers / GitHub feed |
| Local Data & Snapshot | Database | config + local cache |
| Scheduler / Cron Jobs | Backend | automated refresh |
5.4 Data Flow and Connections
| Connection | Direction | Description |
|---|---|---|
| HTTPS | Browser / Frontend → Streamlit Frontend | User entry point |
| REST API | Streamlit Frontend → FastAPI Platform API | Frontend calls backend APIs |
| data requests | FastAPI Platform API → Market Data Services | Issues data requests |
| snapshot | Market Data Services → Local Data & Snapshot | Writes snapshots |
| trigger sync | FastAPI Platform API → Data Sync Service | Triggers data sync |
| fetch market data | Data Sync Service → Upstream Data Sources | Fetches upstream market data |
| upstream feed | Upstream Data Sources → Local Data & Snapshot | Upstream data flows in locally |
| heartbeat | Scheduler → FastAPI Platform API | Periodic health probe |
| market checks | Scheduler → Market Data Services | Periodic market checks |
5.5 Three Operational Perspectives
User Entry
- Streamlit pages serve the interactive UI over HTTPS.
- Requests reach the FastAPI Platform API and the command runner.
Data Path
- The provider layer fetches market data from upstream sources.
- Results are cached locally as snapshots for fast reads.
Automation
- Scheduled jobs trigger sync and market checks.
- Sync keeps local snapshots aligned with the upstream feed.
The diagram includes two views: Primary runtime flow (user-facing requests pass through the Streamlit UI, the FastAPI Platform API, market data providers, and local snapshots) and Data sync path (upstream data flows through the provider layer into local snapshots, driven by scheduled automation).
6. Security & Compliance
- Open-source compliance: follows the upstream project's AGPLv3 license
- Data localization: all market data stored locally, sensitive data never leaves the server
- Timely security: major disclosed vulnerabilities checked and fixed on the same day
- Auditability: complete operation logs for post-hoc tracing
This document is the public introduction of the OpenBB project, focusing on features, stability and system architecture. Internal implementation details and tuning parameters are internal research materials and are not displayed here.
