Routly.

Self-hosting · 8 min read

Self-hosted fleet management, honestly costed

What it takes to run fleet management on your own servers: the components, the operational load, the cost against per-vehicle SaaS, and when not to.

Self-hosted fleet management, honestly costed — Routly

Self-hosting swaps a per-vehicle subscription for an infrastructure bill and a small amount of operational work. Whether that is a good trade depends on numbers you can work out in an afternoon.

What self-hosting actually means here

It means the software runs on machines you control and the telemetry lands in databases you can connect to with any SQL client. Not a private cloud tenancy someone else administers, and not an export you request — the tables, on your disk, queryable at three in the morning without asking.

The distinction matters because “on-premise” is sold loosely. Ask three questions of anything claiming it: can you take a pg_dump yourself, can you point a BI tool at the telemetry store, and does the software keep working if the vendor’s licence server is unreachable. If the answer to any of those is no, you are renting with extra steps.

What you actually run

Four processes, from one compose file:

ComponentJobNotes
PostgreSQLSystem of recordVehicles, trips, users, geofences, reports
ClickHouseTelemetry storePositions, columnar, per-column codecs
RedisCache and locksOptional; there is an in-memory fallback
APIOne Node serviceIngest, queries, scheduled reports

Nothing exotic. Whoever already runs your databases can run this — that is the whole selection criterion, and it is why there is no bespoke runtime, no message bus to operate and no Kubernetes requirement.

How much disk a fleet actually needs

This is the number people most often guess wrong, usually upward by an order of magnitude.

On a production instance we measured on 16 August 2026: 49,478 positions occupying 908 KiB on disk, from 2.61 MiB uncompressed. That is a compression ratio of 2.94× and about 19 bytes per position.

Work forward from that. A vehicle reporting every 30 seconds while it is moving, eight hours a day, produces roughly 960 positions a day:

FleetPositions/dayRaw per yearOn disk per year
100 vehicles~96,000~35 M~0.7 GB
500 vehicles~480,000~175 M~3.3 GB
2,000 vehicles~1.9 M~700 M~13 GB

Thirteen gigabytes a year for two thousand vehicles. Storage is not the constraint, and anyone quoting you per-vehicle pricing on storage grounds is not describing physics.

The compression comes from the codecs the schema declares rather than from luck: DoubleDelta on timestamps, which are a monotonic sequence; Gorilla on coordinates and sensor readings, which drift slowly; Delta on course, which changes in small steps. Ten columns are individually coded.

The cost shape is different, not automatically lower

A hosted platform charges per vehicle per month, forever. The bill is proportional to the fleet and it never stops. Self-hosted, you pay for servers and for the hours someone spends keeping them up — a figure that barely moves between one hundred vehicles and one thousand.

Put your own numbers in:

Hosted:      vehicles × price_per_vehicle × 12
Self-hosted: server + backups + (hours_per_month × 12 × hourly_cost)

The second line has no vehicles term in it. That is the entire argument, and it is also why the answer flips at a certain fleet size rather than being universally true.

A concrete shape, with a host at €40/month, backups at €10, and two hours of attention a month at €60/hour: roughly €2,040 a year, whether you run 100 vehicles or 2,000. Against a subscription at €5 per vehicle per month, the crossover is around 34 vehicles; at €2, around 85. Above it the gap compounds, and nothing you have already paid reduces the next invoice.

Two costs people forget on the self-hosted side: somebody has to be on call when ingest stops at three in the afternoon, and somebody has to test the restore. Neither is expensive; both are real.

What you take on

  • A host, and backups of it. One machine to start. Postgres needs a backup schedule and a restore you have actually tested. The telemetry store usually does not need one: trips, events and their figures are derived at ingest and live in Postgres, so a lost position history costs you replay detail rather than business records.
  • TLS and a domain. A certificate that renews, and a reverse proxy in front. Renewal failing silently is the most common self-hosted outage there is — alert on certificate age, not on expiry.
  • Updates. Pull the images, run the migrations. On the same cadence you already use for everything else you run.
  • Watching that data is arriving. The failure mode of an ingest pipeline is silence, and silence looks identical to a quiet fleet. Alert on “no positions in the last N minutes” rather than on errors — the outage that costs you a day is the one that threw no exception.
  • Being the controller of driver data. Positions and behaviour scores are personal data about your drivers in the EU. Self-hosting makes that unambiguously your responsibility rather than a shared one — usually what you wanted, but it is a responsibility, and it means informing drivers and having a retention policy you can defend.

What you stop taking on

  • A meter that runs while you sleep and grows with every vehicle you add.
  • An export format someone else chose, standing between you and your own history.
  • A roadmap where the report you need is a feature request in a queue you cannot see.
  • A rate limit deciding what you may build on top of your own telemetry.
  • A vendor whose acquisition, price change or shutdown is a business risk you carry but cannot influence.

When not to self-host

Three cases, said plainly because you will find them out anyway:

  • A small fleet with no ops capacity. Under roughly a hundred vehicles, with nobody who owns servers, a subscription is very likely cheaper than the attention self-hosting costs. The arithmetic above is not the whole story if the two hours a month do not exist.
  • You need it running this week. A migration done properly — assessment, deploy, both systems side by side while the data is compared — takes a few weeks, most of it waiting and checking rather than working.
  • Your policy forbids AGPL code. Some procurement rules rule it out outright. There is a commercial licence for exactly that, but it is a purchase, not a free path.

You do not have to change the hardware

The most common blocker is imagined rather than real: people assume self-hosting means re-flashing trackers. It does not. Routly reads from Flespi, from Traccar, or from any gateway that can POST JSON. The devices already in the vehicles keep reporting exactly as they do now, which is what lets both systems run in parallel while you compare the numbers.

That parallel period is the whole de-risking mechanism. You are never choosing between the old system and an unproven one; you are watching both produce the same trips for a fortnight and then turning one off.

Frequently asked

Where do I put the actual numbers?

This article is about what self-hosting involves; if what you need is the arithmetic for a business case — market pricing, the costs the per-vehicle figure omits, and the crossover by fleet size — that is the three-year cost worksheet.

How long does a migration take?

Assessment one to two days, deployment one to three weeks, then one to two weeks running both systems side by side. Most of the elapsed time is comparison, not work. The switching section breaks it down.

What happens to my historical data?

It stays wherever it is. Positions can be replayed into the ingest endpoint, but derived data is recomputed on ingest anyway, so most fleets let the new history accumulate and keep the old system readable for as long as they need it.

Do I need a DevOps engineer?

No, but you need someone who is comfortable with docker compose, a backup schedule and a TLS certificate. If that person does not exist in your organisation, that is the real cost, and it is the case where a subscription wins.

Can one server handle my fleet?

For most fleets, yes. The disk figures above are the easy part; the load that matters is ingest writes and dashboard queries, both of which are cheap because positions are batch-inserted and the fleet list is cached for ten seconds.

Is self-hosted more secure?

Not automatically. It removes a third party from the data path, which removes a class of risk, and it makes patching, TLS and access control your job, which adds one. It is more governable, which is a different and usually more useful property.

How to check this rather than believe it

The public demo is the real interface, no account required — the same build you would deploy, filled with a generated fleet. The row-by-row comparison against Wialon covers the hosted case, and what you operate lists every component you would be responsible for.

Talk to us

Tell us what you are running now

Tell us what you run today and how many vehicles are on it — whether that is one fleet or thirty customers’ worth. We answer within one working day.

Or look around first — the demo needs nothing from you. Open it.

Across every fleet you run, if you run more than one. The total decides what the infrastructure costs you to run, which is the first thing we will tell you.

We answer within one working day.