GPS Tracking Server Requirements: Self-Hosted Sizing Guide
Requirements for the GPS tracking server are based on the number of messages, and not on the number of vehicles. A hundred cars reporting each 10 seconds will put 30 times the load as a hundred cars reporting each 5 minutes will put on the same hardware. You specify the size of messages per second, the number of years of data you want to store and then the specification follows.
That’s the one difference that leads to the majority of sizing errors. The question is “what server do I need for 500 vehicles?” and the answer is either too big or, worse yet, too small as they will be able to see the two factors that truly determine server size: how often devices report and how long you store the data?
This guide addresses: What is considered “load,” how to compute it, approximate specs for deployments by size, hosting options, database/network requirements that people overlook, and a worksheet to bring to a vendor discussion.
Quick Answer: What Server Do You Need?
Server requirements depend on five inputs:
- Device count — Number of devices that are connected.
- Reporting interval — the frequency of the message sent out by each device. The most important factor in terms of load.
- Data retention — time period of storage of position history. The primary reason for using storage.
- Concurrent users — Users that access the system simultaneously (including API consumers).
- Feature load —Geofences, Alerts, Scheduled Reports & Integrations all have processing.
For commercial deployment: a small fleet (under 100 devices) at moderate reporting interval should work fine on 2 vCPU / 4 GB RAM / SSD storage as a starting point. From there requirements increase as the message rate increases. Before provisioning, check your numbers with your vendor and ask for a suggestion.
What Determines GPS Tracking Server Requirements?
Message volume determines nearly everything. Calculate it before anything else:
Most things are based on the amount of messages. Work out it first:
Worked examples at three intervals, for 100 devices:
| Reporting interval | Messages per day | Messages per year |
| Every 5 minutes | 28,800 | ~10.5 million |
| Every 60 seconds | 144,000 | ~52.6 million |
| Every 10 seconds | 864,000 | ~315 million |
Same fleet size. Cost of queries, write throughput and growth of the database differ by 30-fold. That’s why the question that starts with “how many vehicles” is the wrong question to ask.
Traccar’s maintainer states the same directly in the project’s support forum, and explains that requirements are primarily based on mostly on message volume, not just the number of devices.
Two secondary factors matter:
Ignition-based versus continuous reporting. Most trackers report a lot if moving and very little if parked. The theoretical 24-hour figure is far less than the 8 hours a day that a fleet operates. Inquire from your device supplier about the actual duty cycle.
Attribute richness. A position record with fuel level, temperature and CAN bus data and driver ID is much bigger than a basic latitude/longitude/speed record. Deployments with sensors require more storage per message.
Indicative Server Specifications by Deployment Size
These are only general guidelines and not assurances. The actual requirements depend on the platform, database engine, reporting interval and feature usage; consult your vendor.
| Deployment | Devices | vCPU | RAM | Storage | Notes |
| Pilot / test | Under 25 | 1–2 | 2 GB | 20–30 GB SSD | Sufficient for evaluation |
| Small fleet | 25–100 | 2 | 4 GB | 50–100 GB SSD | Comfortable at moderate intervals |
| Mid-size | 100–500 | 2–4 | 8 GB | 100–250 GB SSD | Monitor before scaling |
| Large fleet / small reseller | 500–2,000 | 4–8 | 8–16 GB | 250 GB–1 TB SSD | Tune database indexes |
| Reseller platform | 2,000–10,000 | 8+ | 16–32 GB+ | 1 TB+ SSD/NVMe | Requires optimization and monitoring |
| Large-scale | 10,000+ | Specialist | Specialist | Specialist | Vendor sizing exercise required |
For comparison, community reports on the Traccar forum say that they have roughly 32–52 devices reporting every 20–40 seconds running at around 5% CPU on a 1 vCPU / 2 GB RAM VPS, and that the project maintainer recommends 1,000 devices on 8 GB RAM and SSD storage. It’s open source numbers and won’t match all the numbers on commercial platforms that have more features, but it shows the general trend: When the message rates start to move, modest hardware can be expected to perform more than most users realize.
CPU, RAM, Storage and Bandwidth
CPU
The tracker message is not CPU intensive to receive and to decode. The processing: covers geofence evaluation for all the positions, alert rule matching, scheduled report generation and API queries. The CPU is much busier when deployed with hundreds of geofences and complicated alert rules, than when deployed with simple location logging at the same message rate.
RAM
Typically, the limiting factor is the RAM. It contains the application, the database working set and connection pools. This is under provisioning that appears as slow map loading and report timeouts, not outright failures, and can be confused for many reasons. Feed lavishly; this is the lowest cost improvement.
Storage
Storage doesn’t equal storage devices:
Storage estimate = messages per day × average record size × retention days
The size of the record depends on the platform and number of attributes included in each message – do not assume the size, ask your vendor for a per-record size. Next, size the disk, and select SSD or NVMe instead of spinning disk for your full retention period with headroom. The telematics workload is write-heavy, query-heavy on time-range scans and disk latency is the users’ direct experience.
Don’t leave retention policies up to inheritance. Many operators maintain position history in detail for a certain time period and also have aggregate trip summaries stored forever without compromising reporting.
Bandwidth
Each individual tracker message is small (usually under a kilobyte). Bandwidth will not be an issue at fleet scale, except for large reseller platforms for bandwidth planning. Determine if any of your hosts throttles sustained traffic, and make sure you don’t have a restrictive monthly cap on the plan you select.
Database Considerations
Self-hosted GPS tracking deployments typically break down in the database.
Keep the database on the same server for typical deployments. For normal installations Traccar’s recommends against separating the database onto its own server unless some specific reason exists, as network round trips between application and database are generally more expensive than they are beneficial. Only divide at real scale; or divide, only for a reason.
Index the columns your queries actually use. Tables can easily reach hundreds of millions of rows. Most of the time, tables don’t have an index, and time-range queries cause “the reports got slow.The most frequently occurring reason for “the reports got slow” is that tables are unindexed.
Plan archival before you need it. Any of the above uses for moving old positions to cold and aggregated summaries are much easier to design at 10 million rows versus 500 million. .
Choose the engine your platform supports and your team knows. The vast majority of platforms can be installed with PostgreSQL and MySQL/MariaDB. The one, that your administrator can tune, is often the best one.
Networking, Ports and Hosting
Ports
Most platforms have a set of ports (one for each of their device protocols) that GPS trackers are able to connect directly to your server. It has two practical implications: first, the way that you share a web host is not possible; second, you need to open all protocol ports that you use at inbound traffic on your firewall. Only provision the exact ports; everything else is restricted.
Additionally, a static IP address and a stable hostname are required as trackers are programmed to listen to a set address. Changing it means reconfigure all devices in the field.
Which hosting option should you choose?
| Option | Best for | Trade-off |
| On-premise hardware | Air-gapped or strict data-residency requirements | You own power, cooling, hardware failure and physical security |
| VPS or cloud instance | Most self-hosted deployments | You administer the OS, patching and backups |
| Managed hosting | Teams without in-house IT | Preserves data control, outsources administration, adds cost |
Operators, by default, are cloud instances – predictable cost, easy vertical scaling and no hardware to replace. On-premise is appropriate when there’s a contractual or regulatory requirement that calls for it. Managed hosting is the middle ground option for businesses that wish to run their own GPS tracking system but do not want to hire people to maintain and run the servers — which is a service we only examine in that self-hosted GPS tracking guide.
Security and Backup Baseline
Self-hosting does not ensure security, it gives you control over your data. It’s up to what you do that the outcome will be. At minimum:
- Access control —role-based permissions, strong authentication, multi factor for administrators.
- Encryption —TLS for web app/API, encryption at rest for the DB.
- Patching — a program of scheduled operating system, database and platform updates.
- Firewall — Allow only tracker protocol ports, HTTPS and administrative access.
- Monitoring — disk usage, memory, message throughput and failed authentication attempts.
- Backups — automated, off server and with tested restore. If you have not backed-up and recovered, it is a hypothesis.
Explicitly define a recovery point objective and recovery time objective. If you lose a day of position history, it’s OK, if you lose customer and device configuration, it’s not — back them up separately and more frequently for most tracking operations.
When to Scale Up
Watch four signals rather than waiting for an outage:
- Normal operation CPU usage > 70%. Not peaks.
- The use of memory pressure or swap, that severely limits database performance. .
- Report and map queries slow down with the growth of the position table — this is usually an indexing/archiving issue, not necessarily a hardware issue.
- Grow to over 70% capacity, taking into account your growth rate, not your current usage.
When you’re considering adding hardware, consider the lower-cost measures such as index tuning, implementing an archival policy, decreasing the reporting period on stationary assets and eliminating unused geofences and alert rules. Too many “we need a bigger server” instances are database maintenance problems.
Frequently Asked Questions About GPS Tracking Server Requirements
What are the server requirements for GPS tracking software?
Requirements are based on the number of messages, NOT devices: device count x reporting rate x retention. A small commercial fleet of 100 devices or less with moderate intervals will typically operate on 2 vCPUs, 4gb of RAM and SSD storage. Check out your message number per day before sizing with your vendor—don’t measure against the number of vehicles.
How do I calculate storage for a GPS tracking server?
Multiply the messages per day with the average record size by the number of days to retain the records. The number of messages per day is equal to the number of devices multiplied by 86,400 seconds in a day, divided by the number of seconds per report. The record size will vary based on the platform and the number of attributes of the sensor within the message; your vendor should give you the size of the record per message and allow for expansion.
Can I run GPS tracking software on shared hosting?
No. GPS trackers can only connect to your own server through certain TCP and UDP ports and the shared hosting packages won’t let you open up any random ports. Trackers are setup to report to a fixed destination, which means that you will require a VPS, cloud instance, dedicated server or on premise hardware with a static IP or stable hostname.
How much RAM does a GPS tracking server need?
Typically, the initial limitation is RAM. Typical usage is 2–4 GB for small deployments, 8 GB for use with approximately 1,000 devices, and much larger for reseller-scale deployments. Slow map loads and report timeouts are indicators of under-provisioning, so provision generously; It is the least expensive component to upgrade.
Does the database need its own server?
Usually not. In typical deployments, it is not recommended to separate the application and the database as it introduces network round trips between them, and this is why Traccar’s maintainer advises to leave them on the same server. Split the database when it is necessary, scale, with a quantifiable rationale and a manager.
How many devices can one GPS tracking server handle?
None: it varies according to the reporting interval and retention and feature load. 1,000 devices reporting every 5 minutes, may be able to handle 200 devices reporting every ten seconds. Do the math and determine how many messages per second are possible; then, consult with your vendor to determine the throughput possible on your hardware.
What ports do GPS trackers use?
Generally, each device protocol will have its own TCP or UDP port, depending on the trackers you are running and the protocol that your platform supports. Open only the ports that your vendor gave you, and open only the ports you need (from a security standpoint, just HTTPS and administrative ports).
Do I need an IT team to run a self-hosted GPS tracking server?
Access to IT capability, not necessarily in-house staff. There has to be owners of provisioning, patching, backup and monitoring. Managed hosting is a typical compromise—it gives you control over your data, but not over your administration. For organizations that cannot accept this responsibility, cloud platforms are a better option to consider.
How often should GPS trackers report?
Match the interval to the operational need – not the quickest. The time to live dispatch can be 10-30 seconds, route reconstruction and utilisation reporting are typically good at 1-5 minutes. Frequent reporting leads to increased storage and mobile cost, as well as server load, which the business may not need.
Planning a Self-Hosted Deployment?
AIQ Connect is a self-hosted, white-label GPS tracking and fleet management platform that is installed on your infrastructure. Deployments are not based solely on the number of vehicles, but on number of devices, reporting interval, and retention. Take the worksheet provided above to a demo session and solve it.
Book a free AIQ Connect demo →
Related reading: What Is Self-Hosted GPS Tracking Software? · 8 Best Self-Hosted GPS Tracking Software Platforms · How to Start a GPS Tracking Business · How Does GPS Tracking Work?
