Short version. Traccar is a device gateway — Java, Apache-2.0, 200+ protocols — and Routly does not replace it; Routly reads from it. If you need protocol decoding, keep Traccar. If you need trips classified, fuel theft separated from burn, driver scores and per-customer reports, that is the layer above it.
Traccar is very good at the job it does, and Routly does not replace that job — it reads from Traccar. If you arrived here to replace it, the honest answer is that you probably want to keep it.
What Traccar is
An open-source server under Apache-2.0, a decade old, that speaks over two hundred device protocols and turns whatever a tracker emits into positions. It ships a web interface, basic reports and geofences with it. For a large number of fleets that is the whole requirement, and it costs nothing.
Its protocol coverage is the thing nobody should try to rebuild. Teltonika, Queclink, Concox, Ruptela, Suntech, Meitrack, the long tail of Chinese OEM firmwares that each interpret their own spec slightly differently — Traccar has absorbed a decade of that, and every one of those decoders exists because somebody hit the edge case in production.
When Traccar alone is enough
Do not buy something you do not need. Traccar on its own is the right answer when:
- You want live positions and a track history, and little else.
- One fleet, one set of users, no customers of your own to isolate.
- Nobody is asking for fuel-theft detection, driver scoring or scheduled reports.
- You are comfortable in the database when a question comes up that the interface cannot answer.
If that describes you, close this page. Adding a second system to a setup that already answers your questions is how you end up maintaining two.
Where people run out of it
The pattern is consistent. Traccar keeps decoding devices perfectly well, and the gap opens on the layer above it — the part a fleet manager or a paying customer actually looks at.
Trips that mean something commercially
Traccar records positions and can compute a route. What a business needs is a trip with a start address, an end address, a purpose and a number that goes on an expense claim. Classification — business, personal, commute — is the difference between a track log and something an accountant will accept.
Fuel, including the theft
Fuel level is just another sensor value until something interprets it. A tank going from 400 to 320 litres over a shift is consumption; the same 80 litres disappearing in four minutes at 02:00 in a yard is a drain. Separating the two is a rule about rate of change against ignition state and position, and it is the single feature that most often pays for a fleet platform in the first quarter.
Driver behaviour as a score
Harsh braking and speeding arrive as events. A fleet manager cannot act on ten thousand events; they can act on a ranked list of drivers. Aggregation, weighting and a trend over weeks is a different job from detection.
Reports that arrive without anyone opening a browser
Built, saved, scheduled, and emailed as CSV, Excel or PDF on a Monday morning. The report nobody has to remember to run is the one that changes behaviour.
It stays single-tenant, and permissions show it
Traccar’s own forum is the honest source here: users report permission limits when a manager tries to create users, and performance questions once device counts climb into the thousands. Neither is a flaw; both are the shape of a system built for one fleet being asked to behave like a platform for many.
Many fleets in one deployment
The moment you have customers rather than vehicles, you need each of them isolated: their own users, their own geofences, their own reports, and their own logo on what you send them. Retrofitting that onto a single-tenant system is the expensive kind of rewrite.
Traccar and Routly, side by side
Honest about where each wins:
| Traccar | Routly | |
|---|---|---|
| Device protocols | 200+, decoded directly | None — reads from a gateway |
| Licence | Apache-2.0 | AGPL-3.0, or commercial |
| Live map and track history | Yes | Yes |
| Trip classification | No | Business, personal, commute |
| Fuel drain detection | No | Separated from ordinary burn |
| Driver scoring | Raw events | Aggregated per driver |
| Scheduled reports by email | No | CSV, Excel, PDF |
| Multi-tenancy | Single tenant | Isolated organisations, grants per vehicle |
| Per-customer report branding | No | Logo and colours per organisation |
| Telemetry store | Its own database | ClickHouse you run |
The first row is the important one. Routly has no device decoders at all and is not trying to acquire them. That is deliberate: it is an application layer, and it needs a gateway underneath.
There is a third name worth putting beside these. Fleetbase is also AGPL-3.0 and also self-hostable, but it is a modular logistics suite — orders, dispatch, routing — with telematics as one module. Routly is the narrower thing: fleet telemetry and the reports built on it, with multi-tenancy aimed at whoever is reselling. If your problem is dispatching deliveries rather than watching vehicles, look at Fleetbase first.
So run both
This is the arrangement we recommend and the one we support. Traccar gets the bytes off the device; Routly reads from it and is the part your customer looks at. You keep the protocol coverage you already rely on and you do not touch a single tracker.
How the wiring actually works
Traccar has a position forwarder built in. Point it at Routly’s webhook endpoint and add a shared secret as a header:
<entry key='forward.enable'>true</entry>
<entry key='forward.type'>json</entry>
<entry key='forward.url'>https://your-routly-host/api/webhook/traccar</entry>
<entry key='forward.header'>x-webhook-secret: YOUR_SECRET</entry>Set the same value as TRACCAR_WEBHOOK_SECRET on the Routly side and that is the integration. Traccar does not sign its forwarded payloads, so a shared secret in a header is the mechanism available; keep it long and keep the endpoint on TLS.
One detail worth knowing, because getting it wrong fails quietly: Traccar reports speed in knots and distance in metres. Routly has a dedicated Traccar provider that converts on ingest, so a stock Traccar works unmodified. If you instead point Traccar at the generic HTTP endpoint, you have to define computed attributes inside Traccar first — and the usual symptom of getting that wrong is speed silently arriving as null on every position.
There are three ingest paths in total: traccar, flespi, and a generic one that accepts any JSON a gateway can POST. Positions land in a ClickHouse you run; vehicles, trips and users in a Postgres you run. Nothing is sent to us.
What is different about the licence
Traccar is Apache-2.0, which places no obligation on you at all. Routly is AGPL-3.0, which is stricter in one specific way: modify it and offer it to others over a network, and you publish those modifications under the same licence. Running it privately and unmodified triggers nothing.
That distinction matters most if you resell. Offering a modified Routly to customers over a network is exactly the case AGPL Section 13 covers, and the integration work you consider your advantage would have to be published. There is a commercial licence that removes the obligation. Worth knowing before you start rather than after.
Frequently asked
Does Routly replace Traccar?
No. It has no device protocol decoders. It reads decoded positions from Traccar, Flespi, or any gateway that can POST JSON.
Can I migrate my Traccar history into Routly?
Positions can be replayed into the ingest endpoint, but the more useful answer is usually no: derived data — trips, fuel events, scores — is computed at ingest, so a backfill recomputes it anyway. Most people run both in parallel and let the new history accumulate while the old one stays queryable in Traccar.
My Traccar is slowing down — is that what this fixes?
Partly, but that is a different question with its own answer: running Traccar past a thousand devices covers the tuning that helps and the point at which splitting ingest from the application layer is the real fix. This page is about the features above it, not the load beneath it.
Do I need ClickHouse?
For a production deployment, yes; it is what makes a long position history cheap. On a measured production instance a position costs about 19 bytes on disk after compression, at a ratio of 2.9×.
Will my trackers need reconfiguring?
No. They keep reporting to Traccar exactly as they do now. The forwarder is the only thing that changes, and it is a configuration entry.
Is Routly open source in the same sense?
It is AGPL-3.0, which is an OSI-approved licence, but the two are not equivalent in practice: Apache-2.0 asks nothing of you, AGPL asks for your modifications back if you serve them to others over a network.
Check it against your own devices
The demo shows the interface with no account required. If you already have Traccar running, the fastest real test is to point its forwarder at a Routly instance and watch the same vehicles appear in both — which is also how a migration goes: both systems in parallel until the data matches, then you decide.
