OpenStock: a self-hosted Next.js stock tracker backed by Finnhub and MongoDB

What OpenStock actually replaces, and for whom

OpenStock is aimed at people who want a market dashboard they control rather than a subscription seat. The README frames it as "an open-source alternative to expensive market platforms" and lists the jobs it does: real-time prices, personalized alerts, and company insights. The audience is implicit in the Open Dev Society manifesto that sits above the technical sections, which talks about paywalled knowledge and tools locked in subscriptions. That is a community and self-hosting audience, not a trading desk.

The honest scope is narrower than the pitch. The README carries its own disclaimer: OpenStock is community-built and not a brokerage, and market data may be delayed based on provider rules and your configuration. So the product is a viewer and an alerting layer over someone else's data feed. If you need order routing, positions, or a feed with contractual latency guarantees, this is the wrong layer of the stack entirely. If you want a Next.js app you can read end to end and run on your own box, the scope is right.

The stack behind the dashboard: Next.js, Better Auth, MongoDB, Finnhub, TradingView

The architecture is a conventional Next.js App Router application with a server-side data layer, and the README names every component. Next.js 15.5.7 with React 19 handles routing and rendering, shadcn/ui and Tailwind CSS 4 handle presentation, Better Auth handles sessions, MongoDB (through both the official driver and Mongoose) handles persistence, Finnhub supplies market data, and TradingView widgets supply charts and market views. Background work runs through Inngest, and Nodemailer sends mail.

That split matters when you debug. Quotes and company fundamentals come from Finnhub over HTTP, so anything wrong with a price is a provider problem or a key problem before it is a code problem. Charts are TradingView widgets, which means the visual layer is embedded rather than drawn from your own data, and the README does not describe an offline fallback for them. Alerts are the part that is genuinely yours: they are persisted in MongoDB and delivered by an Inngest function that calls Nodemailer, so a self-hosted deployment needs both a reachable MongoDB and a working Inngest setup for the alert path to fire. The repository layout reflects this, with app/, components/, hooks/, lib/, database/, middleware/ and types/ at the top level, plus an __tests__/ directory and a vitest.config.ts for the test runner.

Installing OpenStock with Docker Compose

The repository ships a docker-compose.yml with two services. The openstock service builds from the local Dockerfile, publishes port 3000, and reads variables from a .env file. The mongodb service runs the mongo:7 image, publishes port 27017, and keeps data in the mongo-data volume. The compose file sets MONGO_INITDB_ROOT_USERNAME to root and MONGO_INITDB_ROOT_PASSWORD to example, and adds an extra_hosts entry mapping mongodb to host-gateway so the app container can reach the database.

Start it from the repository root:

docker compose up -d

Compose builds the image, starts MongoDB with a healthcheck that runs mongosh --eval "db.adminCommand('ping')", and waits for that check before starting the app. When both containers report healthy, the dashboard is on http://localhost:3000. Because the app reads .env, you must create that file before the first run or the container starts without configuration.

The Dockerfile itself is a plain node:20-alpine build: it copies package*.json, runs npm install, copies the project, runs npm run build, exposes 3000 and starts with npm start. The comments in the file note that pnpm is an option if you swap the install and start commands.

For local development without Docker, the package.json scripts are the entry point:

npm install
npm run dev

The dev script runs next dev --turbopack. The test script runs vitest run, and test:db runs node scripts/test-db.mjs, which is the quickest way to confirm your MongoDB connection string works before blaming the app.

Environment variables you have to supply before anything renders

The README has a dedicated Environment Variables section, but the cleaned text does not enumerate the keys, so treat .env as something you populate from the repository's own documentation rather than from this article. What the README does establish is which integrations need credentials. Finnhub is the market data provider, so a Finnhub API key is required for quotes and company insights. MongoDB needs a connection string, and the compose file's default credentials are root and example against the mongodb host on port 27017, which you should change for anything reachable from outside your machine. Better Auth needs its own configuration to issue sessions, and Nodemailer needs SMTP credentials for alert emails to leave the system.

This is the least documented part of the project and the place where a first deployment most often stalls. If the app builds and starts but shows no prices, the Finnhub key is the first thing to check. If sign-in fails, look at Better Auth before the database. If alerts never arrive, the Inngest function and the mail credentials are the two moving parts, and the README does not describe a fallback queue.

Where OpenStock breaks down: data latency, provider dependence and alert delivery

The first limitation is stated by the project itself. Market data may be delayed based on provider rules and your configuration. That sentence should govern how you use the app. A delayed quote is fine for a personal watchlist and misleading for anything timed. The delay is a function of your Finnhub plan, not of the code, so no amount of self-hosting removes it.

The second is provider dependence. Every price, and by extension every alert, depends on one external API. If Finnhub changes its terms, rate-limits you, or you exceed your plan's request budget, the dashboard degrades to empty states. The README documents no secondary provider, so there is no failover path to configure.

The third is the alert pipeline. Alerts are stored in MongoDB and dispatched through Inngest with Nodemailer. That is three dependencies for one feature: a database write, a durable function runner, and an SMTP server. Any one of them being unreachable means the alert silently does not arrive. The README does not document retry semantics or a dead-letter path for failed sends, so you should test the alert path deliberately on your own deployment before relying on it.

Finally, there is no release history in the repository. The last push was on 2026-09-21, which is current, but with no tagged releases you are tracking the main branch. Upgrades mean pulling commits, not bumping a version.

OpenStock compared with a hosted tracker or a plain Finnhub script

The realistic alternative is not another open-source dashboard. It is a short script against the Finnhub API that writes quotes to a file or a database and mails you when a threshold is crossed. That approach gives you exactly the data path and nothing else: no Next.js build, no MongoDB, no Inngest, no TradingView embed. It is a few dozen lines and it will not break when a UI dependency updates. What you lose is everything OpenStock adds on top: authentication for multiple users, a persisted watchlist, a charting layer, and a UI that a non-programmer can use.

The second alternative is a commercial market platform, which is the thing the README positions against. The difference in approach is stark. A commercial platform owns the data contract, the latency guarantee and the support relationship, and charges for it. OpenStock hands you the application and leaves the data contract to your Finnhub plan. You are trading money for operational work and licence obligations.

If your goal is a shared dashboard for a club, a classroom or a small community, the OpenStock approach earns its complexity because the auth, persistence and UI work is already done. If your goal is a personal price alert, the script wins on every axis that matters.

AGPL-3.0, upgrades and the cost of running your own copy

OpenStock is licensed AGPL-3.0, and the README states the consequence in plain terms: if you modify, redistribute, or deploy it, including as a web service, you must release your source code under the same licence and credit the original authors. That reaches further than many self-hosters expect. Running a modified OpenStock for other people over the network is the trigger, not distributing binaries. The repository includes a LICENSE file at the top level alongside a Security section in the README, but the README does not describe a security disclosure process in detail, so read the file itself rather than assuming a policy. None of this is legal advice; if the licence affects a commercial plan, have someone qualified read it.

Upgrade cost is the other recurring expense. With no tagged releases, the project is consumed from the main branch. The dependency list is broad and current, spanning Next.js 15.5.7, React 19.1.0, Tailwind CSS 4, Better Auth 1.3.x, Inngest 3.47.x, Mongoose 8.19.x and the MongoDB driver 6.20.x. Each of those moves on its own schedule, and the Dockerfile installs with npm install rather than a frozen lockfile step, so a rebuild can pull newer minor versions than the ones you tested. Pinning is on you.

The operational floor is three services: the Next.js container, MongoDB, and whatever Inngest needs to run the alert functions, plus an SMTP account. On a single small host that is manageable, but it is not a static site, and the README does not claim otherwise.

Editorial conclusion

Adopt OpenStock if you want a readable Next.js codebase for a personal or community market dashboard and you are comfortable supplying your own Finnhub key and MongoDB instance. Do not adopt it as a system of record for trades, and do not fork it into a closed product: AGPL-3.0 requires that modified deployments, including a hosted web service, publish their source under the same licence. Before you commit, verify three things in the repository: whether MARKET_SUPPORT.md covers the exchanges you care about, whether the alert path in the Inngest functions depends on a scheduler you are willing to run, and whether the Finnhub plan you hold permits the request volume your user count implies.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Open-Dev-Society/OpenStock on GitHub
4. Project website
5. README