Infinite Monitor: an AI agent that writes, builds and serves each dashboard widget as its own React app
Monitor anything in real time
At a glance
- What is it?
- Infinite Monitor is an MIT-licensed Next.js dashboard builder where an AI agent generates a self-contained React widget per request, builds it with Vite inside a Secure Exec V8 isolate, and serves the static output into an iframe on an infinite canvas. The core judgement: the sandbox-plus-build pipeline is the interesting part, and it also sets the project's operational floor at Node.js 22.
- Who is it for?
- Adopt Infinite Monitor if you want an AI agent to produce throwaway or exploratory React panels and you are comfortable running Node.js 22 with a provider API key, accepting that widget code is generated rather than reviewed. Do not adopt it if you need audited, version-pinned widgets, a server-side key model, or reproducible builds, because the README describes Vite builds inside a Secure Exec isolate and keys held in browser localStorage.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: dashboards that need code you have not written yet
Most dashboard tools give you a fixed catalogue of panels. You pick a chart, point it at a data source, and you are done, as long as your data fits the shape the tool anticipated. Infinite Monitor takes the opposite position. The README describes it as "an AI-powered dashboard builder" where you "describe the widget you want in plain English and an AI agent writes, builds, and deploys it in real time." The target user is someone who already knows what they want on screen but does not want to scaffold a React project, wire a charting library, and write a fetch layer for each panel. The topics attached to the repository (ai-agents, osint, sigint, dashboard) point at the audience the author has in mind: people assembling monitoring views over external data, where the panel you need today did not exist yesterday. That is a narrower and more honest pitch than "build any dashboard". If your panels are stable and your data is already in a warehouse, a conventional BI tool will cost you less attention.
What actually happens between the prompt and the pixels
The README's four-step flow is short but the architecture diagram underneath it is the real specification. Each widget is a full React app, not a config object. When you click Add Widget and describe what you want, the agent writes files, Vite builds them, and the built output is served as static HTML. The build runs inside a Secure Exec sandbox, which the README describes as a V8 isolate, and it explicitly notes "No Docker required". That single sentence is the design decision that separates this from container-per-widget approaches: isolation comes from the V8 isolate rather than from a container runtime, which is why the prerequisite list asks for Node.js 22 specifically, citing Secure Exec's `isolated-vm` native addon. State lives in SQLite through Drizzle ORM, holding widgets, layouts and files. The client is Next.js 16 with React 19, and a Zustand store persisted to localStorage holds the canvas state. Widgets render as iframes on a canvas with pan, zoom, minimap and grid-snapped placement. The agent also gets dashboard context: the README states each widget's agent "can see what other widgets exist on the same dashboard and read their source code", which is meant to produce complementary components rather than duplicates. That is a real mechanism, not marketing, and it is also where the model's context budget will bite on a large dashboard.
Getting it running: three commands and one env file
The setup path in the README is deliberately plain. Clone the repository, then create `.env.local` with at least one provider key. The example given is `ANTHROPIC_API_KEY=sk-ant-...`, with commented alternatives `OPENAI_API_KEY=sk-...` and `GOOGLE_GENERATIVE_AI_API_KEY=...`. The README points at `.env.example` for the full list of supported environment variables, and that file is the authoritative source rather than the README text. Then `npm install` followed by `npm run dev`, and the app is at `http://localhost:3000`. Two constraints are worth reading twice. First, Node.js 22 or later is required, and the stated reason is the `isolated-vm` native addon that Secure Exec depends on. On a machine with an older Node, the install step is where this will surface. Second, keys can be entered in the chat sidebar instead of the environment, and the README says they are then stored in browser localStorage and sent to the server only for the duration of a request. There is also a community-maintained Electron distribution at mehdiraized/infinite-monitor-desktop for macOS, Windows and Linux, which the README describes as tracking this repository as its upstream source. That distribution is a separate project with its own release cadence; treat it as such.
The sandbox, the threat scan, and where the trust boundary sits
Two security mechanisms appear in the README. The first is the Secure Exec V8 isolate, which runs the generated code and the Vite build. The second is Brin threat scanning: the README states that every external URL is scanned through Brin, and that "web search results and CORS proxy requests with a threat score below 30 are blocked." That is a concrete, checkable rule, and it is also a rule you should expect to argue with. A numeric threshold applied to a third-party scoring service means some legitimate endpoints will be refused, and the README does not describe an override path. The trust boundary itself is the part I would flag hardest. The agent writes the widget code, and that code then runs in an iframe and fetches from external APIs through a CORS proxy. The isolate protects the host from the build. It does not tell you whether the generated fetch calls, chart transforms or embedded URLs are correct or safe for the data they touch. You are reviewing generated code after the fact or not at all, and the README offers no review gate between build and render. On a local-only dashboard over public data that is a reasonable trade. On anything touching internal endpoints it is not.
Where the approach costs you: generated code, cold builds and provider coupling
The README promises iteration "in seconds" when the agent rewrites and rebuilds a widget. It does not give a build-time figure, and the pipeline it describes (write files, run Vite, serve `dist/`) has a floor that a config-driven panel does not: a bundler runs on every change. On a dashboard with many widgets, each iteration is a separate build inside a V8 isolate, and the README says nothing about caching, incremental builds or a build queue. Treat build latency as unverified until you measure it on your own machine. The second cost is provider coupling in a subtle direction. The README advertises 15 providers and 35+ models with per-conversation switching, which sounds like freedom, but the quality of the generated widget is the model's quality. A cheap model that writes plausible-looking React with a wrong data shape produces a panel that renders and lies. Nothing in the described flow validates the widget's output against the data it fetched. The third cost is that the widget template is fixed: React 18, Tailwind, Recharts, MapLibre GL, Framer Motion, date-fns, Lucide and shadcn/ui. That is a generous starting set, and it also means a widget that wants a different charting library depends on the agent successfully installing one inside the sandbox.
The alternative worth comparing: Grafana with hand-written panels
The closest thing to a like-for-like comparison is Grafana, and the difference is where the code comes from. In Grafana you write a panel plugin or a data source plugin once, in TypeScript, against a documented plugin SDK, and the same artifact is reused across every dashboard and every environment. Infinite Monitor generates that artifact per widget, per conversation, and stores the files in SQLite. Grafana's model gives you version control, code review, and a plugin that behaves identically after a redeploy. Infinite Monitor's model gives you a panel in the time it takes to describe it, with no repository to maintain, at the cost of having no repository to review. Grafana also assumes a server-side data source configuration; Infinite Monitor's README describes keys in browser localStorage, which is a different operational posture. If your panels are long-lived and your team has TypeScript capacity, Grafana's plugin path is the cheaper one over a year. If your panels are exploratory and short-lived, or you are one person assembling a view over public data, the generation path is the one that gets you a working screen today.
Maintenance cost, licence, and what the release cadence tells you
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is a permissive starting point, and it is not legal advice; if you are embedding this in a product, read the MIT text and check how the bundled dependencies are licensed, because the widget template pulls in a long list of them. The release history shows v0.0.4, v0.0.5 and v0.0.6 within roughly two weeks in March and April 2026, and the last push is dated 2026-04-05. That is a fast, early-stage cadence on a 0.0.x line, which in practice means the upgrade surface is the whole application. There is no migration guide in the supplied material, and the SQLite schema is managed through Drizzle, so a schema change between versions is something you would discover by reading the diff. The deployment story is a GitHub Actions workflow that runs `railway up`, requiring `RAILWAY_TOKEN` and `RAILWAY_SERVICE_ID` as repository secrets, with the README warning that the project token is not the same as an account or workspace token and must be pasted with no quotes and no surrounding whitespace. If you self-host, budget for reading release notes before each bump rather than assuming a patch will drop in.
Editorial conclusion
Adopt Infinite Monitor if you want an AI agent to produce throwaway or exploratory React panels and you are comfortable running Node.js 22 with a provider API key, accepting that widget code is generated rather than reviewed. Do not adopt it if you need audited, version-pinned widgets, a server-side key model, or reproducible builds, because the README describes Vite builds inside a Secure Exec isolate and keys held in browser localStorage. Before committing, verify three things yourself: that `isolated-vm` compiles on your Node version, that your chosen provider appears in `.env.example`, and how Brin's threat-score threshold of 30 behaves against the APIs your widgets call.
Community notes