OpenStock puts a market dashboard behind personal accounts
OpenStock combines company search, saved watchlists, market news, and TradingView panels in a Next.js 15 application. Better Auth handles email and password accounts, MongoDB stores users and watchlists, and Finnhub supplies symbol search, company profiles, and news. The result resembles a personal market home page more than an analysis terminal. You can move quickly between a watchlist and a stock detail page, but you cannot place a trade. The README explicitly says the project is not a brokerage.
The feature that separates it from a static stock screen is scheduled personalization. Inngest reacts to a new account and runs a daily news-summary job based on saved symbols. Nodemailer sends the messages, and a supported AI provider can write the welcome introduction. That makes sense for a developer studying a full web stack or building an internal market portal. It also means the dashboard depends on more than the 1.6 MB checkout suggests.
Free data leaves holes in some international charts
The project documents support for more than 30 exchanges, then gives the qualification that matters. Finnhub's free tier can delay non-US prices by 15 minutes or more, limits calls, and excludes some asset classes. TradingView's free widgets may refuse charts for symbols on exchanges such as India's NSE and BSE. Open issue 83 records that exact message for an NSE stock on the hosted demo.
OpenStock still lets a user find some affected companies through Finnhub, save them, and read available profile or news data. The interactive chart and technical indicators can remain unavailable. That split is easy to miss if your test list contains only US tickers. Anyone deploying the app for a regional audience should make an exchange-by-exchange acceptance list before promising coverage. Paid provider access or a different chart source may be necessary.
What happened when we ran it
Our sandbox installed 999 npm packages in 42 seconds, leaving 924 MB on disk. Vitest completed in 2 seconds: 79 tests passed, none failed, and 4 were skipped out of 83. Those are useful checks for the code paths the suite covers, and the repository does contain a tests directory. Our scan found 0 CI workflow files, so the checkout did not show GitHub Actions running the same suite for each change.
The production build failed after 18 seconds. The final error says Next.js could not collect page data for /, followed by stack frames inside generated .next/server/chunks/ssr files. That tail does not identify the original exception, so it would be wrong to blame a missing secret, MongoDB, or Turbopack from this evidence alone. The practical result is simpler: commit 4a485f0 did not produce a deployable build in our fresh Node 22 container.
Npm audit reported 71 known vulnerabilities across the installed tree: 5 critical, 19 high, 45 moderate, and 2 low. We did not turn those counts into exploit claims. They do make dependency review a required step before exposing the app. The project had 10,306 source lines across 121 files, so tracing the failed home-page collection and auditing reachable dependency paths is a bounded job, though it is still work the adopter must do.
A useful deployment needs several outside services
The minimum working path needs Node.js 20 or newer, MongoDB, a Better Auth secret, and a Finnhub key. Docker Compose can start MongoDB beside the app, and the repository has both a Dockerfile and a Compose file. Open issue 36 asks for a published image because users currently build it themselves. That distinction matters for updates: you own the image build as well as the database volume.
Email and automation expand the list. Local Inngest runs separately, production Inngest needs a signing key, and Nodemailer is configured around Gmail unless you change the transport. Gemini, MiniMax, or Siray credentials are optional for AI text. The README also warns that variables beginning with NEXT_PUBLIC_ reach the browser. Treat the sample environment file as a wiring guide, then decide which features you can disable before collecting secrets for every integration.
AGPL-3.0 is part of the deployment decision
OpenStock uses AGPL-3.0, and its README spells out the hosted-service consequence: if you modify and deploy it, you must release that source and credit the authors. That can suit a personal server, a public community project, or a company comfortable returning changes. It can conflict with a proprietary product whose advantage sits in modifications to this application. Check that policy before writing private adapters around the 999-package install.
The data providers bring separate terms. Finnhub rate limits and TradingView widget restrictions do not disappear because the application code is open. OpenStock can spare you from designing the account, watchlist, and dashboard layers, but it does not grant market-data rights. The README's own warning about delayed quotes should remain visible to users who may otherwise mistake a polished chart for trade-ready data.
Active commits do not replace a passing release process
GitHub showed 15,767 stars, 29 open issues and pull requests combined, and a last push on September 19, 2026. Recent activity includes provider work and fixes, so this is not a dormant codebase. GitHub returned no latest release, however, and our scan found 0 CI workflows. Users therefore lack a tagged release trail and visible repository automation to balance the failed build we measured.
Use OpenStock as a well-documented starting point if its dashboard is close to the product you want and you can own the repair work. Do not treat 79 passing tests as a deployment certificate. The home page still has to build, the 71 audit findings need triage, and your target exchanges need direct checks against the provider tiers you will actually pay for.