Infinite Monitor: an AI dashboard builder that compiles each widget in a V8 sandbox

The problem Infinite Monitor picks, and who it is actually for

Most dashboards are built once and then rot. You want a chart of one feed, a map of another, a table of a third, and the work of standing up a React app, a build step and a deploy for each of them is disproportionate to how long the insight stays useful. Infinite Monitor's pitch is that you describe the widget in plain English, an AI agent writes the React code, installs dependencies, builds it, and the result renders live in an iframe on a canvas. The README frames the target domains as cybersecurity, OSINT, trading and prediction markets, which is a fair summary of the kind of work where the data sources change weekly and the visualisation is disposable.

The person this fits is an analyst or engineer who can read React but does not want to write it for the fourth time this month. The person it does not fit is a team that needs a shared, versioned dashboard product, because the widget source is generated per request and stored as files in SQLite rather than as code in a repository you review.

How a described widget becomes a running iframe

The architecture diagram in the README splits the system into four parts. The client is Next.js 16 with React 19, with a Zustand store persisted to localStorage, an infinite canvas that supports pan, zoom, minimap and grid-snapped placement, and a chat sidebar. The server is Next.js API routes; AI chat goes through the Vercel AI SDK against whichever provider you configured, and widget files are stored in SQLite through Drizzle ORM. There is also a CORS proxy for widget API calls, which matters because a widget running in an iframe cannot call arbitrary origins directly.

The part worth understanding is the widget runtime. Each widget runs in a Secure Exec sandbox, described in the README as a V8 isolate rather than a container. The agent writes files, Vite builds them, and the built output is served as static HTML. The README states no Docker is required, which is the main operational difference from sandboxing approaches that spin a container per build.

Every widget starts from a template that includes React 18, Tailwind CSS, Recharts, MapLibre GL, Framer Motion, date-fns, Lucide icons and the shadcn/ui components. Note the version split: the host app is on React 19, the widget template on React 18. That is a deliberate isolation choice, but it means a snippet you copy from the host codebase may not drop into a widget unchanged.

One feature deserves attention because it changes agent behaviour rather than output format. Each widget's agent can see the other widgets on the same dashboard and read their source, so it builds complementary components instead of duplicating one. In practice that is what stops you ending up with three near-identical price charts on one board.

Installing Infinite Monitor and building a first widget

The README lists two prerequisites: Node.js 22 or higher, which it ties explicitly to Secure Exec's isolated-vm native addon, and an API key from any supported provider. Clone the repository and enter it.

git clone https://github.com/homanp/infinite-monitor.git
cd infinite-monitor

Next, create .env.local with at least one provider key. The README gives this example, and .env.example in the repository root lists the full set of variables, including OPENROUTER_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY, XAI_API_KEY, MISTRAL_API_KEY and others.

# Pick any provider — or add multiple
ANTHROPIC_API_KEY=sk-ant-...
# OPENAI_API_KEY=sk-...
# GOOGLE_GENERATIVE_AI_API_KEY=...

Then install and start the dev server.

npm install
npm run dev

Open http://localhost:3000. The repository also ships a Makefile with a setup target that runs npm install and a dev target that runs npm run dev, plus an all target that does both in sequence. The Makefile's clean target removes .next, node_modules and data/widgets.db, which is the fastest way to reset local state if a widget ends up in a bad condition.

Once the app is open, the flow from the README is: click Add Widget, describe what you want, and wait while the agent writes the React code, installs dependencies and builds it in the sandbox. The widget then renders live in an iframe. Iteration happens through the chat sidebar, and the README says the agent rewrites and rebuilds in seconds. You can also enter provider keys directly in the chat sidebar rather than in .env.local, and switch models per conversation.

Where the sandbox boundary is thin, and where it is not

The security section makes two claims that are narrower than they first read. The first is local-first storage: API keys are held in the browser's localStorage, sent to the server only for the duration of a request, and never persisted server-side. That is a real property, and it is also the reason Infinite Monitor is a poor fit for a shared deployment where several people use one instance. A key entered in the sidebar belongs to that browser profile, not to the server, so there is no central place to rotate it or to scope it per user.

The second is Brin threat scanning: external URLs are scanned through Brin, and web search results and CORS proxy requests with a threat score below 30 are blocked. A numeric threshold is a coarse control, and the README does not describe what happens to a legitimate URL that trips it, nor whether the threshold is configurable. Treat it as a filter, not a guarantee.

There is a third boundary the README does not discuss at all: what the agent can reach from inside the V8 isolate. The README calls the sandbox secure and says no Docker is required, but it does not enumerate the filesystem, network or environment access available to generated widget code. If your threat model includes generated code, that gap is the thing to resolve before running this against anything sensitive.

A more mundane failure mode: because each widget is a full React app with its own dependencies, a dashboard of ten widgets is ten builds and ten dependency trees. The README does not document a shared dependency cache, so the cost of many small widgets is not obviously lower than the cost of one larger one.

Running Infinite Monitor as a desktop app, and the Railway path

There are two ways to run this beyond npm run dev, and they have different owners. For a desktop install, the README points to a community-maintained Electron distribution at mehdiraized/infinite-monitor-desktop, with builds for macOS, Windows and Linux and releases published in that separate repository. The README is explicit that the desktop project tracks this repository as its upstream source and adds packaging in its own repo. That means a desktop bug may be a packaging bug, and the fix will not appear in this repository's history.

For a server deployment, the deploy workflow at .github/workflows/deploy.yml runs railway up through the Railway CLI. Two repository secrets are required. RAILWAY_TOKEN must be a project token from Project then Project settings then Tokens, scoped to the environment you deploy to, and the README warns it is not the same as an account or workspace token from Account then Tokens. RAILWAY_SERVICE_ID is the target service ID, or the service name if the CLI accepts it for your project. The README adds a specific instruction: paste the token once with no quotes and no leading or trailing whitespace, and it notes that an Invalid RAILWAY_TOKEN error follows from getting that wrong.

The .env.example file also exposes share and publish settings: DURABLE_STREAM_BASE_URL, which defaults to https://stream.tonbo.dev, and SHARE_ID_SECRET for deriving stable share IDs. The README does not document rollback for a Railway deploy, so plan for that separately.

How Infinite Monitor differs from Grafana and from coding agents

The obvious comparison is Grafana. Grafana's model is a fixed plugin ecosystem plus a query language: you pick a panel type and bind it to a data source, and the panel cannot become something the plugin author did not anticipate. Infinite Monitor inverts that. There is no panel catalogue; the agent writes a React app per widget, so the ceiling is whatever the model can produce against the template's libraries. The cost of that flexibility is that you cannot audit a widget by knowing which plugin it uses, and two widgets that look identical may have entirely different source.

A second comparison is to background coding agents. Those take a repository and a task and open a pull request you review before merge. Infinite Monitor's agent writes, builds and serves the result immediately, with iteration through chat rather than review. That is faster for a throwaway widget and worse for anything that needs to be reproducible, because the README does not describe a diff or approval step before a widget goes live on the canvas.

Licence, version and what maintenance looks like

Infinite Monitor is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository's LICENSE file is the authoritative text; nothing here is legal advice. The practical implication is that you can vendor the code, but the generated widget source is a separate question the licence does not address, and the README does not either.

On maintenance: the repository is not archived. The most recent release listed is v0.0.6 from 2026-04-01, following v0.0.5 on 2026-03-29 and v0.0.4 on 2026-03-19. The last push to the default branch was on 2026-04-05. The package.json version field reads 0.1.0 while the releases are still in the 0.0.x series, so do not read the package version as a stability signal. The README does not publish a support policy, a deprecation schedule or a migration guide between releases, so an upgrade is a manual exercise: read the changelog at CHANGELOG.md and expect to re-check the widget template, since the postbuild script scripts/prebuild-template.mjs runs after every npm run build.

Editorial conclusion

Infinite Monitor suits engineers who already hold an Anthropic, OpenAI or similar key and want throwaway analytical widgets without wiring a frontend each time. It does not suit anyone who needs a stable plugin API or server-side secret handling, because widget API keys live in localStorage and the agent rewrites source on request. Before adopting it, check that Node is at version 22 or higher, because the isolated-vm native addon used by Secure Exec will not install otherwise, and read .env.example to confirm the provider you intend to use is listed there.

Frequently asked questions

Official sources

1. homanp/infinite-monitor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases