KeepTrack renders 50,000 satellites in a WebGL 2.0 globe, and runs offline in a browser

The pitch is accessibility to orbital analysis, not a satellite catalogue viewer

KeepTrack.space is described in the repository as TypeScript astrodynamics software for non-engineers, with 3D visualisation of satellite data and the sensors that track them, and the project description in the package manifest calls it complex astrodynamics tools designed for non-engineers to make learning about orbital mechanics and satellite operations more accessible.

The project overview says it aims to make orbital analysis tools accessible to all, providing a simplified and streamlined experience for learning and interacting with satellites and space debris. It is built from the ground up with custom WebGL 2.0 shaders, an internal orbital mechanics library and a high-performance render loop, and the README says plainly that this is a lot more than just dots around a globe.

The named users are what make the scope concrete. It is used by EPFL's Cosmos Archaeology project, referenced in a StarTalk video, by the 18th Space Defense Squadron, and by ethicallyHackingspace. The header describes it as professional satellite tracking for everyone, and the features list leads with tracking 50,000+ satellites in real time, a 5 MB core app that loads in under two seconds, simulation of 2.5 million debris objects at 60fps, work on mobile, tablet and desktop, and being free, open source and able to run offline.

The three audiences in the Who Is KeepTrack For section are operations centres, education and outreach, and the use cases differ sharply. An operations centre wants popup alerts when satellites pass through sensor coverage, needs to find when sensors can see priority satellites in seconds, and wants to simulate new launches and model breakups and debris fields. A classroom wants hands-on interaction, Xbox controllers for demonstrations and AAA video game quality graphics. An outreach programme wants to embed KeepTrack on a website for free and show satellite designs in orbit before launch.

Orbital mechanics lives in a separate library, OOTK

The technology stack is where the engineering decisions are visible, and one entry stands out.

The stack is TypeScript for type-safe development with ES6+ modules, WebGL 2.0 for hardware-accelerated 3D rendering, OOTK as the orbital mechanics library, Web Workers for background orbit calculations so the UI does not block, Webpack for module bundling and optimization, and Materialize CSS as the UI framework, which the README notes is being modernized.

OOTK is the author's own library, at github.com/thkruz/ootk, and it is worth separating from the application. The application is the 3D globe, the sensor cones, the pass predictions, the debris field. The library is the maths underneath. A project that needs orbital mechanics as a dependency would use OOTK; a project that needs the visualisation uses KeepTrack.

Web Workers are the other load-bearing decision. Propagating orbits for 50,000 objects, and simulating 2.5 million debris objects, is arithmetic that would stall the main thread if it ran there. Moving it off-thread is what makes the 60fps debris claim plausible, and it is why the render loop and the physics loop can be designed independently.

The browser requirement is WebGL 2.0, with Chrome 56 or later, Firefox 51 or later, Safari 15 or later and Edge 79 or later. That is a floor worth checking, because WebGL 2.0 is not available everywhere, and the README is honest that the app needs it.

Building it is pnpm, and the build is a script pipeline

The prerequisites are Node.js 18 or later, npm or pnpm, and git. The quick start is five commands:

# Clone the repository
git clone https://github.com/thkruz/keeptrack.space
cd keeptrack.space

# Install dependencies (this repo uses pnpm; `corepack enable` will provide it)
pnpm install

# Build the project
pnpm run build

# Start development server
pnpm start

The app is then at http://localhost:5544. There is a first-run cost to know about. The app will download the satellite catalog, about 5 MB, on first load, which takes approximately 30 seconds.

The scripts in the package.json show what the build is actually made of, and it is not a bundler invocation. There is a setenv step that runs a TypeScript script, a prebuild step that pulls submodules, syncs plugins with a skip-locales flag and generates translations, and then the build itself runs build-manager.ts with a production flag. There are parallel profiles for the same pipeline, including a pro profile, a celestrak profile and an embed profile, each differing only in the profile flag passed to the build manager. The pro build is the commercial edition's tooling, which the README says lives outside this repository.

The development command list is unusually complete for a browser application. Alongside start, build, lint and lint:fix there is a test suite, and a set of SonarQube commands: sonar:up starts a local offline SonarQube server in Docker, sonar runs the tests with coverage and then analyses against it, and sonar:down stops it. The stated purpose is running the same static analysis the project uses, fully offline and self-hosted, with only Docker installed, and no account setup, token juggling or cloud service.

Commands that deliberately refuse to run, and the mesh viewer that does not

Two entries in the script list are worth reading closely, because a project that explains why a command will not work is telling you something about its boundaries.

pnpm run pro dispatches the commercial edition's tooling, which lives outside this repository, so the command just explains itself here. Nothing in the open-source build depends on it.

The publishing steps, upload:sourcemaps and release, push to infrastructure the project owns. They stop with a note about the missing credential, and the README says to point them at your own Cloudflare account if you want to run your own deployment. So the deployment target is Cloudflare, and the open-source build deliberately does not ship the credentials to push there.

The third command is pnpm run mesh-viewer, and it is the most interesting of the three. It serves a standalone viewer that renders any OBJ and MTL through the engine's exact mesh pipeline, covering layout, scale, shader and log depth, and the README explains why: this is how models are checked before they ship. The scripts scripts/mesh-viewer/capture-meshes.ts and capture-angles.ts take headless verification shots through the same viewer.

That is a good piece of engineering practice. A 3D engine that renders a satellite model is only as good as its mesh handling, and a viewer that runs the exact production pipeline on an arbitrary OBJ file is how you catch a scale or depth problem before it appears in the app. The scripts directory also holds the plugin index, which is how the external-plugins.json mechanism is synchronised.

The open source build and the commercial edition are separate builds of one codebase

The repository layout is large and structured, and it shows a project with a serious release process and an embedded product.

There are build/ and scripts/ directories holding the build manager and the plugin tooling, src/ for the application, public/ for static assets, docs/ for documentation, test/ and a playwright.config.ts for end-to-end tests, schemas/, configs/, auth/, biome-plugins/ and a biome.json for linting and formatting, a typedoc.json for API documentation, a vitest.config.ts and vitest.external.config.ts for the unit test suites, and the pnpm-workspace.yaml that defines the workspace.

The release process is visible in the configuration. There is a .releaserc.json for semantic release, a .auto-changelog directory with a changelog.hbs template, a .sonar-project.properties file, a docker-compose.sonar.yml for the offline analysis, a .deepsource.toml, a .sonarlint/ directory for editor integration, a .husky/ directory for git hooks, a CITATION.cff file, a SECURITY.md and a CODE_OF_CONDUCT.md.

The .env.example shows the runtime configuration surface, and it is a short file. It points at the settings TypeScript file with SETTINGS_PATH, the favicon, the loading screen CSS, the style CSS, the logo paths, then sets MODE=development and IS_PRO=false, and finally the API key with KEEPTRACK_API_KEY.

The MODE and IS_PRO flags are the mechanism by which one codebase produces both an open source build and a commercial one. The package scripts confirm the profiles, with build:pro, build:celestrak and build:embed each passing a different profile to the build manager. The version is 13.12.0, the last push was on 2026-10-15, and the releases have been arriving regularly, with 13.12.0 on 2026-10-07 after 13.11.1 and 13.11.0 in September.

Where KeepTrack is the wrong tool

The first wrong-tool case is a team that wants orbital mechanics as a dependency. The application is the product here, and the maths lives in OOTK, which is a separate project with its own maintenance. If you need to compute orbits inside an existing product, integrate OOTK and build your own interface, and use KeepTrack as the reference implementation of what that can look like.

The second is a hardware-constrained environment. The whole design leans on WebGL 2.0, custom shaders and a Web Worker doing the orbit propagation for tens of thousands of objects. A device without WebGL 2.0 gets nothing, and the offline capability, which the README lists as a feature for restricted environments, still assumes a machine with a capable GPU.

The third is a non-browser deployment. There is no server component in the repository, and the API key mechanism points to a hosted service at keeptrack.space. A team that needs to run this inside its own network with its own data pipeline is looking at something this repository does not describe.

The fourth is the licence. It is AGPL-3.0, and the README does not describe an exception process for embedding it in a proprietary product. AGPL obligations reach a server that serves a modified version over a network, which is a materially stricter position than MIT or Apache for a commercial deployment, and a school or company that wants to modify it and host it needs to understand that before starting.

One more point of context. The README has a Use of AI section in its table of contents, so the project addresses AI-assisted development directly, and the repository includes an AGENTS.md for working with coding agents.

Editorial conclusion

KeepTrack.space fits an educator, outreach programme or operations analyst who needs an interactive 3D view of satellite passes, sensor coverage and debris fields without installing anything, and it does not fit a team that wants to embed orbital mechanics into an existing product. Before adopting it, check the WebGL 2.0 requirement, since Chrome 56, Firefox 51, Safari 15 and Edge 79 or later are listed, and note the AGPL-3.0 licence, which matters if you intend to modify it and serve it as a network service.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. thkruz/keeptrack.space on GitHub