Traccar: one Java server, 200 protocols, and a REST API in front of it

This repository is the server, not the product you look at

The first thing to understand about the Traccar repository is that it is the back end. The overview says plainly that this repository contains the Java-based back-end server, and then points at the other parts of the platform that live elsewhere:

- the Traccar web app, the browser-based tracking dashboard, in its own repository - the Traccar Manager app, a mobile app for viewing your tracked devices, in its own repository - the Traccar Client app, one of a set of mobile apps for tracking mobile devices themselves

There is also a `traccar-web` entry at the root of the tree, which is the submodule that brings the dashboard into a build.

So when you read "Traccar" in a feature list or a marketplace, you are usually looking at the deployment of this server plus the separate dashboard and apps. The scope of what this repository covers is: accepting device connections, decoding them, storing positions, and serving an API.

More than 200 protocols and 2000+ device models, out of the box

The compatibility claim is the product. The description says Traccar supports more than 200 GPS protocols and more than 2000 models of GPS tracking devices, and the overview repeats that it handles them out of the box.

That phrase, out of the box, is doing real work. It means the protocol decoders are in the server already, not that you write one. For a tracker whose manufacturer speaks a documented protocol over TCP or UDP, the expectation is that the server understands it without you writing glue.

The other half of that claim is device models rather than protocols, because several manufacturers use the same protocol across many models, and a tracker can also differ in how often it reports, whether it buffers offline positions, and what its identifier looks like.

The repository does not enumerate all of them on its front page, so if your specific device is the deciding factor, the place to check is the project's documentation site rather than this README.

The quick start is two commands and lands on port 8082

Getting a server running with a production-grade MySQL database is the Docker Compose path, and it is two lines:

curl -o compose.yaml https://raw.githubusercontent.com/traccar/traccar/master/docker/compose/traccar-mysql.yaml
docker compose up -d

The first command fetches a compose file from the repository's own docker directory, and the second brings it up. Traccar will be available on port `8082`.

Three details are worth noting. The compose file you download is a real artifact in the repository under `docker/compose/`, not a snippet invented for the README, so you can read it before running it. The database in it is described as production-grade MySQL, which tells you what the project considers a real deployment.

For everything else, the README points at the Docker documentation for other configuration options, and there is a live demo server you can try without installing anything.

It stores in any major SQL database and exposes a REST API

Two architectural choices define how you build on top of Traccar.

The first is the database. The overview says it works with any major SQL database, which is what you want if you already have Postgres or MySQL in place and do not want a second data store for positions.

The second is the interface. Traccar provides an easy to use REST API, and the repository root carries an `openapi.yaml`, which means the API contract is written down in a machine-readable form in the same tree as the code.

That combination is the reason to run your own server rather than use hosted tracking: you own the database, so the position history is in a system you can query with your own tooling and keep under your own retention policy. The cost is that every device protocol, report parsing, and dashboard behaviour is something you now operate.

The feature list is the scope of what the server does with those positions: real-time GPS tracking, driver behaviour monitoring, detailed and summary reports, geofencing, alarms and notifications, account and device management, and email and SMS support.

Building the server from source needs its own documentation

There is no build section in the README beyond a link. The Build heading sends you to the build from source documentation on the official website, and there is no Maven or Gradle command printed here.

The tree explains why there is not. This is a Gradle project, with `build.gradle`, `settings.gradle`, the `gradlew` and `gradlew.bat` wrappers, a `gradle/` directory, and `src/` for the code. It also has `.gitmodules` alongside a `traccar-web` entry, so the front end comes in as a submodule during a source build. Other root directories include `schema/`, `templates/`, `setup/`, `tools/`, `docker/`, `debug.xml` and `openapi.yaml`.

The `gradlew` wrappers mean you are not expected to have a matching Gradle version installed.

The two named maintainers are Anton Tananaev and Andrey Kunitsyn, and the licence is Apache License 2.0.

Self-hosting is the default, managed hosting is the alternative

The overview states who Traccar is built for, and the list is more specific than "trackers": fleet operators, GPS tracking resellers running their own white-label platform, and individuals tracking their own devices.

The reseller case is the interesting one, because it is the reason the separation into a server, a dashboard, and apps matters. A reseller wants to run the server under their own name, which the Apache 2.0 licence permits, and the README links both self-hosting for free and official managed hosting for anyone who would rather not run a server.

The mobile side has two distinct pieces that are easy to confuse. The Traccar Manager app is for viewing your tracked devices, while the Traccar Client app is one of the apps for tracking the mobile device itself, that is, for using a phone as the tracker. The README notes there is a set of these client apps.

Support runs through the project forums and the documentation site, both linked from the README.

Releases are versioned 6.x, and the server version moves on its own

The release history is steady releases within a major line: v6.17.0 on 2026-11-01, v6.16.0 on 2026-09-27 and v6.15.3 on 2026-08-26, with the last push to master on 2026-11-01.

So the server is on version 6, and the three newest releases are roughly a month apart. For an operator that means the question is not whether there are updates but which release you pin, and the fact that the dashboard is a separate repository is what makes that question interesting.

The number to remember from the quick start is the port. Traccar listens on 8082 in the compose file the README points you at.

Other root directories worth knowing about for a source build are `templates/` and `schema/`, which sit alongside `src/`.

Editorial conclusion

Traccar suits a fleet operator, a GPS reseller running a white-label platform, or an individual tracking their own devices who wants the server rather than a hosted service. It does not suit you if you only wanted a phone tracker, since the app that reports a mobile device's location is a separate repository, and it does not suit you if you cannot run a database, because the quick start path is a production-grade MySQL under Docker Compose. Verify two things before you commit: that your specific tracker speaks one of the 200-plus protocols the server already handles, which is the whole compatibility story and the README does not enumerate, and which port you expose, because the quick start puts it on 8082.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes