Traccar Web: the React and MapLibre dashboard that most people mean when they say Traccar

A front end that deliberately contains no back end

The README is unusually clear about the boundary of this repository, and that boundary is the first thing to understand.

It is the browser-based tracking dashboard for Traccar, a free and open source GPS tracking platform. It is a React, Material UI and MapLibre single-page app that talks to the Traccar server over its REST API, providing the live map, reports, geofences and device management UI that most people mean when they say Traccar. The server is a separate project, and the front-end-only rule is stated plainly: for the back-end server, see the main Traccar repository.

Then comes the practical consequence, which decides whether you need this repository at all. You don't need to build this yourself to use Traccar, because the server repository already bundles a built copy. This repository is for contributing to or customizing the UI itself.

That last sentence is the whole adoption decision. If you want to run a GPS tracking platform, install the server and you have the dashboard. If you want to change the dashboard, this is where you work, and the work is a JavaScript project talking to an HTTP API.

The project is licensed under Apache License, Version 2.0, with the text in LICENSE.txt at the root of the repository. The team listed in the README is Anton Tananaev and Andrey Kunitsyn. The last push was on 2026-10-14, and the repository has no GitHub releases, so the shipped version of the dashboard is tracked in the package manifest rather than in a release list.

npm start and npm run build are the whole development loop

The development section is short, and it names the proxy behaviour that makes local work possible.

npm install
npm start

This starts a local dev server, and the README identifies it as Vite, that proxies API requests to a running Traccar server. The proxy is the important part. A single-page app that talks to a REST API on a different origin needs either a same-origin backend or a dev-time proxy, and this is the second, so the local dev server stands in front of a real Traccar server you run yourself. The README points to the web app build documentation for the full setup details, including how to point it at your own server, which is the first thing to read when setting up.

Building a production bundle is one command:

npm run build

The script definitions in the package manifest confirm what those two commands do and add three more. The start script is `vite --host`, so the dev server binds beyond localhost, which is what makes it reachable from another machine or a container. The build script is `vite build`. Then there is `generate-pwa-assets`, which runs pwa-assets-generator with a minimal preset against public/logo.svg, and the two lint scripts, `eslint --max-warnings 0 .` and `eslint --fix --max-warnings 0 .`. The `--max-warnings 0` in both is the setting that makes the lint step a gate rather than advice.

The manifest also lists a browser matrix. Production builds target the browserslist `defaults`, while development targets the last one version of Chrome, Firefox and Safari, which is a sensible split, since the production bundle is the one that has to work on whatever machine a dispatcher is sitting at.

The dependency set says what the dashboard actually does

The package manifest is the most informative document in the repository, and reading it tells you the feature set of the product without opening a single component.

The map stack is MapLibre, with `maplibre-gl` at 6.14.0, `maplibre-google-maps` as a Google Maps wrapper, and `pmtiles` for the tiled archive format. There are also two Mapbox packages that carry a different name, `@mapbox/mapbox-gl-draw` and `@mapbox/mapbox-gl-rtl-text`, which is the drawing tool and the right-to-left text plugin, both used on top of the MapLibre renderer.

The interface is Material UI, with `@mui/material` and `@mui/icons-material` at 9.5.0, `@mui/lab`, and the `@emotion` packages for styling. On top of that sit `stylis` and `stylis-plugin-rtl`, so the styling layer handles right-to-left locales, which matters for a product used across many countries.

State and routing are Redux Toolkit with react-redux, and react-router-dom at 7.18.4. React itself is 19.3.0 with react-dom, and the manifest sets the package to `"type": "module"` and marks it private.

Then there are the features the dependencies only make sense together. `recharts` is the charting library, `exceljs` and `file-saver` are for report export to a spreadsheet, `dayjs` is the date library, `@tmcw/togeojson` converts between GeoJSON and other formats, and the `@turf/circle` package is a Turf function for drawing a radius. The `gcoord` and `wellknown` packages handle coordinate conversion, and the `react-qr-code` and `@yudiel/react-qr-scanner` packages put QR codes into the app in both directions, which in a fleet context is device pairing and identification.

The repository root shows a second, simpler application and a build toolchain

Three entries in the root listing deserve a second look, because they tell you about work that happens outside the main app.

The first is the `simple/` directory, sitting next to `src/` and `public/`. A second directory of application code alongside the main one usually means a reduced interface, a demo, or a build without some of the heavier dependencies. The README does not describe it, which means deciding what it is for requires reading the code, and it is a reasonable thing to look at before choosing where to start contributing.

The second is the toolchain. The root carries an eslint.config.js using the flat config style with `@eslint/js` and `@eslint-react/eslint-plugin`, a .prettierrc.json for formatting, an .editorconfig, and a .vscode/ directory. The Vite React plugin is `@vitejs/plugin-react-swc`, so the JSX transform runs through SWC rather than Babel, which is the faster path and explains why there is no Babel dependency.

The third is a `.env` file at the root and a `.npmrc`. A committed .env in a repository is worth a glance before you start, because it usually holds the development-time configuration the app expects, and the Vite dev server reads that file. The README does not enumerate those values, and the build documentation is where the full picture lives.

There is also a .tx/ directory, which is the directory Transifex uses for translation files, a strong hint that the interface is translated through that service, and public/ holds static assets including the logo.svg that the pwa-assets-generator preset consumes.

Where Traccar Web is the wrong repository to start

Three misunderstandings are easy to make, and the README prevents them by accident rather than by design.

The first is thinking this is a GPS platform. It is a dashboard. Everything in the repository exists to display what the Traccar server already knows, to let a user issue commands through the REST API, and to export what the server produced. Protocol handling, device drivers, position storage and the geofence engine live in the server project, and a team that needs to change how a device reports its position is editing a different codebase.

The second is building it when you only need it. The server repository already bundles a built copy, so a deployment that installs the server gets this interface without a JavaScript build step. A front-end fork is only worth its cost when the change is genuinely in the UI, which is the case the README identifies as the reason this repository exists.

The third is expecting a modern SaaS dashboard stack. The dependency list is React 19, MUI 9 and Redux Toolkit, and the app is a single-page app served to a browser. There is no server-side rendering in the manifest, no API layer of its own, and no database. That keeps the deployment simple, since the built bundle is static files, and it also means anything that has to happen before the page loads has to happen on the Traccar server.

One last practical point. The version in the manifest is 6.16.0, and it tracks the Traccar release line rather than a web-specific one, so the interface and the server move together. The dashboard is therefore coupled to the server version you deploy, and an interface that expects a newer API endpoint will not work against an older server. The repository has no GitHub releases of its own, so the server's release notes are the place to read about what changed.

Editorial conclusion

Traccar Web is worth adopting when you run a Traccar server and want a dashboard you can adjust, and it is a good starting point for a bespoke fleet interface, because the layer is thin and it does nothing but call the REST API. It is the wrong repository to fork for a tracking product that needs offline maps, custom protocol handling or backend logic, since the server lives in a separate project, and it is the wrong thing to build if you only need the standard interface, since the server repository already bundles a built copy. Before starting, read the build web app documentation for how the dev server proxies API requests to your own server, and check the dependency set, where MapLibre, MUI and Recharts are the load-bearing pieces.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. traccar/traccar-web on GitHub