OpenFrame OSS Frontend: an MSP console split across three state systems

Where this repository sits in the OpenFrame ecosystem

OpenFrame OSS Frontend is the primary web application for the OpenFrame platform, a unified, AI-driven interface for managed service providers. The positioning in the README is that it replaces expensive proprietary MSP software with open-source alternatives, bringing device management, ticketing, monitoring, scripts and AI assistance into a single cohesive operational interface. It is built and maintained by Flamingo, and the README describes it as the human-facing layer of the OpenFrame ecosystem, connecting backend services into an AI-first MSP experience. That last phrase sets the scope precisely: this repository is the presentation and orchestration layer, and the services it orchestrates live elsewhere. The repository description is shorter still, OpenFrame Frontend for OSS repository, which is a good summary of the licensing and the audience.

Twelve feature areas in one console

The feature table reads like a product spec rather than a list of modules. Device management offers a unified device model, a remote shell, a file manager and remote desktop via MeshCentral. Customer management carries per-organization AI configuration, guardrails templates and aggregated device counts. Ticketing provides Kanban boards, AI-assisted replies, approval workflows and assignment management, and the knowledge base handles articles, folders and attachments. On the AI side there are two separate assistants: Mingo AI for technicians, a streaming assistant with tool execution, context awareness and approval flows, and Customer AI, called Fae, which is embeddable for client-facing portals. Monitoring covers fleet MDM policies and osquery live query campaigns. There is a script library with scheduling and execution history, audit logs with cursor-based pagination, settings and billing for tenant config, SSO, API keys and subscriptions, a step-by-step onboarding flow, and runtime-configurable feature flags through Zustand.

Three state systems, each used where it fits

The state management section is the most instructive part of the README because it shows a team making a deliberate division of labour rather than picking one library. Server state uses TanStack Query v5, for REST API calls, optimistic mutations and cursor pagination. GraphQL fragments use Relay v20, for logs, scripts and notifications, with streaming and pagination. Client UI state uses Zustand v5, for feature flags, onboarding, the Mingo chat and device filters. The distinction is not arbitrary. REST calls that need optimistic updates or cursor pagination are a natural fit for a query cache, whereas Relay's fragment model with its normalised store and its subscription support is a better answer for a streamed log view, and global UI state that several unrelated parts of the tree read is a plain store. Three libraries is a cost, and this is where the cost is justified.

The stack and what the heavier dependencies are for

The core dependency table lists Next at 16.2.4 for server-side rendering with the App Router, React 19.2.0, react-relay at 20.1.1 for the GraphQL fragment system, TanStack Query at 5.90.16, Zustand at 5.0.8 and Tailwind CSS at 3.4.17. Two of the entries are there because of specific features rather than general application needs. @xterm/xterm at 6.0.0 is the terminal emulator behind the remote shell, and @monaco-editor/react at 4.7.0 is the editor behind the script library. zod at 4.3.6 handles runtime schema validation, which is worth noting in a project that validates across process boundaries with Relay and REST. The last entry is the shared component library, @flamingo-stack/openframe-frontend-core, which the README describes as the shared UI component library and which also provides the shared ESLint configuration that the lint scripts reference.

How the frontend talks to the backends

The architecture diagram shows the frontend in the middle with four different kinds of connection. There is a GraphQL endpoint at /api/graphql to the API service core, a REST path at /chat/api to the AI and chat service, OAuth 2.0 to the authorization service, and two proxied tool paths, one to the fleet MDM server and one to MeshCentral. The API service core sits on a data layer of MongoDB, Cassandra and Apache Pinot, and the chat service sits on a stream layer of Kafka and NATS. The path split is a security decision as much as an architectural one, since the two tool endpoints are reached through the frontend's own server rather than being called directly from the browser.

The app directory is organised by feature domain

The web app lives in apps/web, with the Tauri desktop and Capacitor mobile shells that bundle it in apps/desktop and apps/mobile, and the code is organised by feature domain under apps/web/src/app. The domains listed are customers, devices, tickets, knowledge-base, logs-page, monitoring, scripts, settings, mingo, and onboarding, alongside a lib directory holding the API, auth, Relay and MeshCentral code and a stores directory for the Zustand global state. Splitting by domain rather than by type is the convention that keeps a feature's components, hooks and queries together, and the fact that the README draws it as a diagram rather than describing it in prose suggests it is a convention contributors are expected to follow.

Running it locally

The prerequisites are Node.js 24, the version in the .nvmrc, with its bundled npm, and Git, and there is a prerequisites guide in the docs directory for the full details.

# 1. Clone the repository
git clone https://github.com/flamingo-stack/openframe-oss-frontend.git
cd openframe-oss-frontend/apps/web

# 2. Install dependencies
npm install

# 3. Configure environment
cp .env.example .env.local
# Edit .env.local with your backend URLs

# 4. Start the development server
npm run dev

Then you open the local development server in a browser. The minimum environment variables are all prefixed for the browser, and there are four of them: the tenant host URL, the shared host URL, the app mode, which the example sets to oss-tenant, and the app URL. The README points you at the environment configuration documentation for the real backend URLs, which is the file to read for anything beyond a local run.

Where OpenFrame OSS Frontend is the wrong choice

Four limits apply. It is coupled to the OpenFrame backend services by design, since it is the presentation and orchestration layer for them, so a team wanting a standalone admin panel for their own data gets a frontend with no backend to talk to. The three-state approach is coherent but it means three libraries to learn, three sets of caching and invalidation semantics to reason about, and a reviewer has to know which of them a given query lives in. The dependency list is heavy for a console, with a full GraphQL client, a query cache, a terminal emulator and a code editor in the bundle, which is fine for an internal operations tool and wrong for a public marketing site. And the licensing is the one to read first: the licence field on the repository carries a custom classification that GitHub cannot label, the badge names a Flamingo AI Unified licence version 1.0 rather than a standard one, and the SECURITY.md and CONTRIBUTING.md files imply a specific relationship with the maintainers that you need to understand before you build on it.

Editorial conclusion

Use OpenFrame OSS Frontend if you are building on the OpenFrame backend services and want the provider-side console rather than assembling one, because the device, ticketing and monitoring surfaces are already wired to the API service, the chat service and the authorization service. Do not adopt it as a standalone admin panel, since every screen depends on the surrounding OpenFrame services. Verify first which app you are running, because the web app in apps/web and the Tauri desktop and Capacitor mobile shells are separate builds, that your Node version matches the 24 in .nvmrc, and that you read the licence file itself, since the licence field on the repository carries a custom classification GitHub cannot label and the badge names a Flamingo AI Unified licence rather than a standard one.

Frequently asked questions

Official sources

1. flamingo-stack/openframe-oss-frontend on GitHub
2. Issues
3. README
4. Releases