Infrastructure Sizing

This guide gives infrastructure teams a practical baseline for planning self-hosted, private cloud, or on-premise Fleetbase deployments. Treat these numbers as planning guidance, not a fixed benchmark. Final sizing depends on active vehicles and devices, active drivers, order volume, telemetry frequency, concurrent users, custom extensions, uploaded media, integration traffic, and retention policy.

Fleetbase does not require GPU resources for the core platform. GPU capacity is only relevant if you run separate AI, computer vision, route optimization, or analytics workloads outside the standard Fleetbase application stack.

Reference Stack

Fleetbase production deployments are built from these core services:

The default Docker Compose stack is suitable for development, testing, evaluation, and small self-hosted deployments. For enterprise production, use Kubernetes or an equivalent orchestrator so the API, queue workers, WebSocket tier, and backing services can be scaled and upgraded independently.

Environment Tiers

For production, avoid running database, Redis, application containers, file storage, and backups all on the same VM unless the deployment is a limited pilot with accepted downtime risk.

Sizing Drivers

Fleetbase deployments should be sized from workload shape, not a single headline metric. Vehicle count matters, but it is only one input. A fleet with modest telemetry and low order throughput can need less infrastructure than a smaller operation with dense telemetry, heavy imports, many dispatchers, or long retention requirements.

Use these workload profiles as a starting point, then adjust each tier using the formulas below.

Recommended Kubernetes Architecture

Use Kubernetes for production environments that require high availability, rolling upgrades, operational isolation, and clear scaling paths.

flowchart TD
  users["Console users and API clients"] --> dns["DNS and TLS"]
  dns --> ingress["Ingress / load balancer"]
  ingress --> console["Fleetbase Console"]
  ingress --> api["Fleetbase API replicas"]
  ingress --> socket["SocketCluster replicas"]
  api --> mysql["MySQL 8 HA"]
  api --> redis["Redis HA"]
  api --> object["Object storage"]
  api --> queue["Queue workers"]
  scheduler["Scheduler"] --> redis
  scheduler --> mysql
  queue --> mysql
  queue --> redis
  queue --> object
  api --> external["Maps, routing, mail, SMS, Sentry"]

Recommended production characteristics:

• Use at least three Kubernetes worker nodes or a managed Kubernetes control plane with three or more workers.
• Run two or more API replicas and scale horizontally based on CPU, memory, request latency, and queue pressure.
• Run queue workers separately from API replicas so imports, webhooks, reports, notifications, and long-running jobs do not consume request capacity.
• Run one scheduler replica with leader-election or operational controls that prevent duplicate scheduled tasks.
• Run SocketCluster behind a WebSocket-aware ingress. If multiple replicas are used, validate sticky routing and event fanout behavior for your load balancer.
• Keep MySQL, Redis, and object storage outside ephemeral application pods.
• Use private subnets for database, Redis, and internal services; expose only HTTPS and approved WebSocket endpoints publicly.

Bill of Quantities

Minimum Production

Use this for pilots, small fleets, and self-managed production where short maintenance windows are acceptable.

Large Production Reference

Use this as a starting point for high-volume operations with many active vehicles/devices, drivers, orders, integrations, real-time users, and longer retention requirements. Increase or decrease each component based on the actual sizing drivers above.

Sizing Formulas

Use these formulas to refine the bill of quantities once the customer provides usage data.

Telemetry and device events

events_per_day = active_vehicles * (86400 / telemetry_interval_seconds)
raw_storage_per_day = events_per_day * average_event_size_bytes
database_storage = raw_storage_per_day * retention_days * index_and_overhead_factor

For planning, use an index and overhead factor of 2.5 to 4.0 for JSON payloads, spatial indexes, secondary indexes, row metadata, and soft-delete overhead.

Illustrative telemetry examples:

Storage sensitivity: every extra 500 bytes per stored event adds about 183 GB/year per 1 million events/day before index overhead. Apply the index and overhead factor above to estimate database allocation.

If full-fidelity telemetry must be retained for 12 months, consider partitioning, archival tables, or moving raw telemetry history to purpose-built analytics storage while keeping recent operational state in MySQL.

Orders and workflow data

order_storage = orders_per_day * average_order_record_size * retention_days * overhead_factor

Order data usually grows more slowly than telemetry, but custom fields, activity logs, route data, proof records, and integration payloads can increase per-order storage significantly.

Files, documents, and media

file_storage = uploads_per_day * average_file_size * retention_days
backup_storage = file_storage * versioning_or_backup_multiplier

Proof of delivery photos, driver documents, import files, exports, invoice PDFs, and attachments should live in object storage, not local container storage. Use lifecycle rules for archive and deletion.

Logs and backups

log_storage = daily_log_volume * log_retention_days
backup_storage = database_size * backup_retention_factor + object_storage_backup_delta

Production deployments should retain application logs centrally, store database backups separately from the database cluster, and periodically test restore procedures.

Network Requirements

Production DNS should provide separate hostnames for the console and API, or one hostname with explicit routing paths. Certificates may come from a public CA, corporate CA, or private PKI depending on network exposure and client policy.

Storage, Retention, and Backups

Suggested production targets:

Security and Operations

Production environments should include:

• TLS everywhere for browser, API, and WebSocket traffic.
• Private networking for MySQL, Redis, object storage endpoints, and internal service traffic.
• Kubernetes secrets, sealed secrets, cloud secret manager, Vault, or equivalent for credentials.
• Per-environment credentials and key rotation for database users, object storage, mail, SMS, maps, and registry access.
• RBAC for Kubernetes, cloud accounts, Fleetbase users, and extension administration.
• SSO or corporate identity integration where required by the customer security model.
• Encryption at rest for database volumes, object storage, backups, and log archives.
• Vulnerability scanning for container images, host packages, dependencies, and customer-specific extensions.
• Antivirus or malware scanning for uploaded files if required by policy.
• WAF, rate limiting, IP allowlists, or VPN/private access for admin-only deployments.

Monitor and alert on:

• API request latency, error rate, memory, CPU, and replica health.
• Queue depth, job failure rate, and oldest pending job age.
• Scheduler health and missed scheduled tasks.
• SocketCluster connection count, publish failures, and rejected origins.
• MySQL CPU, memory, storage, replication lag, slow queries, lock waits, and connection usage.
• Redis memory, evictions, connection usage, and command latency.
• Object storage errors, backup completion, backup age, and restore test status.
• Certificate expiration, DNS health, ingress errors, and external integration failures.

Commercial and Licensing References

Infrastructure sizing is separate from commercial licensing. For current commercial terms, use the website pages as the source of truth:

Use the AGPL-3.0 license for open-source self-hosting unless the deployment requires proprietary modifications, SaaS distribution without releasing modifications, OEM/white-label rights, or commercial license terms negotiated with Fleetbase.

Sizing Inputs Needed

Before finalizing infrastructure, collect:

• Number of active vehicles and total registered vehicles.
• Number of active drivers and driver shift patterns.
• Telemetry interval, average payload size, and expected connected-device providers.
• Required telemetry, order, log, file, and backup retention periods.
• Daily and peak orders, API transactions, imports, exports, and webhook traffic.
• Expected concurrent console users, dispatchers, drivers, and customer portal users.
• Average and peak uploaded media volume.
• Required RTO, RPO, maintenance windows, and disaster recovery region.
• Hosting preference: bare metal, VMware, private cloud, AWS, Azure, GCP, or another Kubernetes distribution.
• Identity provider, SSO requirements, privileged access model, and audit requirements.
• External connectivity limits for maps, routing, SMS, email, push notifications, registry access, and monitoring.