# Open MCT: NASA's Web Framework for Mission Control Displays

> Open MCT is a JavaScript framework for building telemetry visualization and operations interfaces. It installs from npm, runs locally on port 8080, and extends through plugins, but it is a framework you build on, not a ready-made console.

**nasa/openmct** — A web based mission control framework. 

- Repository: https://github.com/nasa/openmct
- Website: https://nasa.github.io/openmct/
- Stars: 13,143 · Forks: 1,494
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nasa-openmct

## What Open MCT Solves, and Who It Is Built For

Open MCT (Open Mission Control Technologies) is a web based framework for visualizing telemetry data on desktop and mobile devices. It is developed at NASA's Ames Research Center, and the README states it is used by NASA for data analysis of spacecraft missions and for planning and operation of experimental rover systems. That origin matters: the interface patterns come from operations rooms, where an engineer watches live values, timelines, and imagery rather than scrolling a dashboard.

The README frames the audience explicitly. It calls Open MCT "a generalizable and open source framework" that "could be used as the basis for building applications for planning, operation, and analysis of any systems producing telemetry data." The operative word is basis. This is not an application you deploy and point at a data source. It is the substrate for one, and the work of connecting your telemetry, defining your object types, and composing your displays falls to you.

That places it in a narrow category. Teams building satellite ground software, rover operations tools, test range instrumentation, or industrial supervisory displays have a genuine fit. Teams that want a general purpose analytics dashboard will find the abstraction heavier than the problem.

## The Plugin Architecture and What It Implies

Open MCT is extended through plugins. The README defines a plugin as "a group of software components (including source code and resources such as images and HTML templates) that is intended to be added or removed as a single unit." It also notes that most of the core codebase is itself written as plugins, which is the more informative detail: the extension mechanism is not a bolt-on, it is how the product is assembled.

The practical consequence is that anything you add, a new visualization, a new telemetry source adapter, a custom staleness indicator, follows the same registration path the core uses. The repository ships an example directory with concrete cases: example/dataVisualization, example/eventGenerator, example/exampleStalenessProvider, example/exampleTags, example/exampleUser, example/faultManagement, example/generator, and example/imagery. These are the closest thing to reference implementations in the tree, and they map to recognizable operations concerns (faults, staleness, imagery) rather than generic web app demos.

The API documentation lives in API.md at the repository root, with a section on plugins and a section titled "Starting an Open MCT application." That file, plus the separate openmct-tutorial repository the README points to, is where the actual integration contract is defined. The README itself does not restate the API, and it should not be read as a substitute for it.

## Installing Open MCT and Running It Locally

The README gives a four step local setup. It requires Git and Node.js, and it warns that the instructions assume a non-root user, citing developer reports of problems running these steps with root privileges. That warning is worth taking literally; installing as root is a known friction point in this project's own issue tracker.

First, clone the source:

```bash
git clone https://github.com/nasa/openmct.git
```

The README marks the next step optional. It installs the Node version pinned by the repository's .nvmrc file via nvm:

```bash
nvm install
```

Then install development dependencies. The README directs you to check the package.json engine field for tested and supported Node versions; the repository root contains a .nvmrc file and the package.json declares an engines constraint.

```bash
npm install
```

Finally, start the development server:

```bash
npm start
```

When the server is up, the README says Open MCT is accessible by pointing a browser at http://localhost:8080/. The build tooling is npm and webpack.

There is one packaging detail that affects how you consume this. The README notes that if you build a project with Open MCT as a git dependency rather than an npm dependency, an extra step is required: because ignore-scripts is enabled in the repository to reduce supply chain attack risk, developers using it as a git dependency must run npm run build manually. The README's own recommendation is to use Open MCT as a prebuilt npm package rather than building from GitHub. For most consumers that is the shorter path, and the package.json confirms the published entry points: dist/openmct.js for both import and require, with types at dist/types/index.d.ts.

## Where Open MCT Is the Wrong Choice

The framework's scope is telemetry visualization and operations, and the README does not claim otherwise. If your requirement is a general business intelligence dashboard, a marketing analytics view, or a CRUD admin panel, Open MCT's object model and plugin ceremony add work without adding value. You would be learning an API designed around time series and mission objects to render tables.

A second limitation is that the repository does not give you a deployment story. The README covers building and running locally, the test suites, and the plugin mechanism. It does not document production hosting, authentication backends, or persistence. The example/exampleUser directory suggests user handling is something you implement, not something the framework provides out of the box. Teams expecting a turnkey multi-tenant operations platform will be disappointed, and the README is silent on that expectation rather than managing it.

Third, the project describes itself as fast moving and states it does its best to test and support a wide range of browsers, operating systems, and NodeJS APIs, with the supported list published in the browserslist key of package.json. Fast moving plus a plugin API means upgrade work is a real budget line, not a one-time cost. The release history bears this out: v4.1.0 and v4.2.0 landed on the same day in February 2025, and v4.3.1 arrived in August 2026. Anyone pinning an old minor version should expect to schedule migration work rather than assume drop-in compatibility.

## How Open MCT Compares to Grafana and Similar Tools

The natural comparison is Grafana, and the difference is in what each assumes about your data. Grafana starts from a query: you configure a data source, write a query against it, and bind the result to a panel. Its unit of work is the panel and the dashboard, and its extension surface is data sources and panel plugins.

Open MCT starts from an object tree and a telemetry API. You define what the things in your system are, register providers that supply their current and historical values, and the framework's views render them. The plugin examples in the repository reflect this: a staleness provider, a fault management example, an imagery example. These are operations concepts, not chart types. The README's framing, that Open MCT could be the basis for applications for "planning, operation, and analysis," is a statement about building a tool, whereas Grafana's model is a statement about querying one.

That makes Open MCT heavier to start and more specific in what it produces. If your data is already in a time series database and you want charts in an afternoon, Grafana is the shorter route. If you are building an operator console where the objects, their relationships, and their live state are the product, Open MCT's object model is the reason to pick it, and the reason the initial work is larger.

## Testing, Maintenance Cost, and Licensing

The repository carries real test infrastructure, and it is worth knowing what you inherit. Unit tests use Jasmine run by Karma, invoked with npm test, and the suite loads any script ending in Spec.js under src; the convention is that src/foo/Bar.js is tested by src/foo/BarSpec.js. End-to-end, visual, and performance tests use Playwright through @playwright/test, with separate commands: npm run test:e2e:ci, npm run test:e2e:visual, and npm run test:perf. Test files live under e2e/tests/ and match the *.e2e.spec.js pattern. Security analysis runs through CodeQL on each commit.

That is a meaningful maintenance surface. If you fork or vendor the code, you are also taking on a Karma and Playwright toolchain, not just a library. If you consume the npm package, you inherit the framework and leave the test harness behind, which is another argument for the npm route the README recommends.

On licensing, the README displays an Apache 2.0 badge linking to apache.org, and the repository root contains LICENSE.md. The repository metadata supplied for this project records the license as NOASSERTION, which means the automated classifier did not resolve a standard SPDX identifier. Those two signals do not contradict each other, but they do mean the license file is the authority and the badge is not. Read LICENSE.md before you ship, and if your organization has strict license review, treat the NOASSERTION classification as a flag to resolve internally rather than a detail to skip. Nothing here is legal advice; it is a note about where the discrepancy sits.

## Conclusion

Adopt Open MCT if you need a browser-based operations interface for telemetry and are prepared to write plugins against its API, and prefer the prebuilt npm package over building from the GitHub source. Do not adopt it expecting a finished console: the repository ships a framework and examples, not a deployable mission system. Before committing, read API.md and the plugin tutorials, confirm your Node version against the package.json engine and browserslist keys, and check that the Apache 2.0 license terms in LICENSE.md fit your distribution plan.

## FAQ

### What is Open MCT?

Open MCT (Open Mission Control Technologies) is a web based mission control framework for visualizing telemetry data on desktop and mobile devices, developed at NASA's Ames Research Center. The README describes it as a generalizable open source framework that can serve as the basis for applications for planning, operation, and analysis of systems producing telemetry data.

### Which software does NASA use?

The README states that Open MCT is used by NASA for data analysis of spacecraft missions and for planning and operation of experimental rover systems. It is developed at NASA's Ames Research Center and is open source on GitHub under nasa/openmct.

### Is NASA open source?

Open MCT is published as an open source project by NASA, with its source at github.com/nasa/openmct and an Apache 2.0 license badge displayed in the README. The repository root also contains a LICENSE.md file.

### What is mission control software?

Open MCT is described as a mission control framework for visualization of telemetry data, used by NASA for data analysis of spacecraft missions and for planning and operation of experimental rover systems. The README says it can serve as the basis for applications for planning, operation, and analysis of any system producing telemetry data.

## Sources

- [Issues](https://github.com/nasa/openmct/issues)
- [nasa/openmct on GitHub](https://github.com/nasa/openmct)
- [Project website](https://nasa.github.io/openmct/)
- [README](https://github.com/nasa/openmct/blob/master/README.md)
- [Releases](https://github.com/nasa/openmct/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nasa-openmct