Fleetbase: a self-hosted logistics operating system for teams that want to own the stack

What Fleetbase replaces, and for whom

Fleetbase describes itself as a modular logistics and supply chain operating system. The problem it targets is fragmentation: dispatch lives in one tool, warehouse inventory in another, invoicing in a third, and the customer tracking page is a spreadsheet someone updates by hand. The README positions the platform as covering dispatch, fleet management, live tracking, commerce, warehousing and finance in one system, with a REST API and webhooks for the gaps.

The audience is narrower than that sentence suggests. The README's industry table lists trucking and haulage, courier and parcel, food and grocery delivery, e-commerce, healthcare, waste and recycling, container operations, and government and defense. Those operations share a trait: they move physical things on routes, and they care who touched what and when. A software team building a logistics product on the API is the second audience the README names explicitly.

The self-hosting angle matters for the last row in that table. Government and defense buyers are listed as wanting role-based access, audit trails and data sovereignty. That is a hosting requirement, not a feature, and it is the reason the project ships a Docker Compose file rather than only a cloud signup.

How the module system actually splits the work

Fleetbase is not one application. The README describes modules that install into the console as extensions, each working on its own and integrating with the rest. The named modules are Fleet-Ops for dispatch and fleet management, Storefront for headless commerce, Pallet for warehouse inventory and pick lists, Ledger for invoicing and payments, Customer Portal as a self-service workspace, AI for natural-language order creation, IAM for users and roles, and Developers for API keys and webhooks. Two mobile apps, Navigator App and Storefront App, are separate repositories.

That structure has a practical consequence. You can run Fleet-Ops without Pallet, and an on-demand delivery business probably will. The cost is that integration between modules is a real dependency rather than an assumption. The README says each module works on its own, but the value proposition in the same paragraph is that they integrate, so the boundary between the two claims is where your own testing starts.

The extension system is the escape hatch for everything the modules do not cover. The README states the platform has an extension system and a marketplace for installing extensions. It does not, in the pages available to a reader, document the extension API surface, so treat custom extension work as a research task rather than a known quantity.

Installing Fleetbase with Docker Compose

The repository root contains docker-compose.yml, a docker-compose.override.yml.example, and a docker/ directory with database initialization scripts. The Compose file defines the backing services the platform needs. Read it before running anything, because it tells you what you are committing to operate: a MySQL 8 database, Redis for cache and queues, a SocketCluster service for realtime events, a scheduler container, and the API image.

The database block is worth reading closely. It publishes port 3306 to the host and sets MYSQL_ALLOW_EMPTY_PASSWORD to yes, which is fine for a local trial and not something to expose on a public interface. The same block disables binary logging with --skip-log-bin. The comment above it explains why: the telematics ingest had grown the binlog past 300 GB locally, and nothing in the stack replicates from it.

services:
  database:
    image: mysql:8.0-oracle
    command: ["mysqld", "--skip-log-bin"]
    ports:
      - "3306:3306"
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
      MYSQL_DATABASE: "fleetbase"

The socket service runs socketcluster/socketcluster:v17.4.0 pinned to linux/amd64 and maps container port 8000 to host 38000. The comments in that block give the production and development forms of the origins setting, which is the piece you change before exposing the service. The scheduler container runs the fleetbase/fleetbase-api:latest image with go-crond pointed at root:./crontab, and connects to MySQL and Redis through DATABASE_URL, REDIS_URL, QUEUE_CONNECTION and CACHE_DRIVER.

docker compose up -d

After the stack reports healthy, the console is the first real thing to look at. The README links a hosted console at console.fleetbase.io and a documentation site at fleetbase.io/docs, and the repository carries a Caddyfile.console alongside the main Caddyfile, which is where the web entry point is configured. The repository does not include a step-by-step first-order walkthrough, so the honest sequence is: bring the stack up, confirm the database and cache healthchecks pass, then work from the Fleet-Ops documentation to create a driver, a vehicle and an order.

The operating costs the Compose file admits to

Most project READMEs hide the unpleasant parts. This one puts one of them in a YAML comment. Binary logging is on by default in MySQL 8 with a 30-day expiry, and the comment states the telematics ingest made it grow past 300 GB locally before it was switched off. That is a concrete signal about write volume: if you run telematics ingest at any scale, your database is doing sustained writes, and turning off the binlog removes point-in-time recovery as an option. You are choosing disk savings over a restore path, and that decision belongs in your backup design, not in a default you never read.

The second cost is the version pinning. The socket service is pinned to v17.4.0 and to linux/amd64, so on ARM hosts it runs under emulation. The scheduler and API services use fleetbase/fleetbase-api:latest, which means a redeploy can pull a different build than the one you tested. Pinning those to a release tag is a change you make yourself; the Compose file as shipped does not do it.

The third is the module count. Every module you install is another surface to configure, another set of permissions in IAM, and another thing that can break an upgrade. The README's framing of modules as independent is accurate about installation and silent about operational load.

Where Fleetbase is the wrong choice

If your problem is one function, Fleetbase is heavier than you need. A team that only wants to optimize delivery routes is better served by a routing library or a dedicated routing service than by a platform that also wants to own your orders, inventory, invoicing and user directory. The module system lets you install less, but the database, cache, socket and scheduler containers come with the core.

The second wrong fit is any organization without infrastructure capacity. The AGPL-3.0 licence and the self-hosting story are the point of the project, but they transfer operational responsibility to you. Someone has to run MySQL, watch disk usage given the ingest volumes the Compose comment describes, and apply upgrades across modules. Fleetbase Cloud exists as an alternative, and choosing it means giving up the data sovereignty argument that makes the self-hosted version attractive to the government and healthcare rows in the README's table.

The third is a team that needs a stable, frozen API. The release history shows frequent point releases, including three within a week in September 2026. That cadence is normal for a platform that is actively developed, and it is also a signal that interfaces may move. If your integration cannot absorb that, pin to a tag and budget for the upgrade work.

Fleetbase compared with a general-purpose ERP or a routing API

The closest framing in the documentation is not another logistics platform but the category Fleetbase is trying to displace: the legacy transport management system, which the README's trucking row names directly as the thing being replaced with real-time tracking, route optimization and digital proof of delivery.

The difference in approach is configuration against code. A legacy TMS ships fixed workflows and charges for changes. Fleetbase's claim is that every workflow, field and status is configurable, and that the same platform adapts across the industries in its table. That is a bet on flexibility being worth more than a curated default, and it is only a good bet if your operation genuinely differs from the norm. If your dispatch process matches an off-the-shelf product exactly, you have bought configuration work you will never use.

Against a routing API such as a standalone optimization service, the difference is scope. A routing API answers one question well and integrates into whatever you already run. Fleetbase answers the routing question and then also holds the order, the driver record, the inventory and the invoice. That is the whole argument for a platform, and it is also the whole argument against one when your existing systems already work.

Licence and upgrade path under AGPL-3.0

Fleetbase is licensed AGPL-3.0. The practical effect for most teams evaluating it is that if you modify the software and let users interact with it over a network, the licence expects you to offer those users the corresponding source. Running it unmodified as internal tooling is a different situation from building a product on top of it. This is not legal advice, and the boundary between the two depends on facts only your counsel can assess.

The upgrade cost is tied to the module structure. Because modules install separately, an upgrade is not one version bump but a set of them, and the compatibility you need to verify is between the core and each installed module rather than against a single changelog. The repository carries a RELEASE.md and a workflows/ directory, so the release process is documented in-tree, but the README does not describe a rollback procedure. Before you upgrade a production instance, confirm you can restore the database, and remember that the shipped Compose file disables the binlog that would otherwise give you point-in-time recovery.

Editorial conclusion

Adopt Fleetbase if you need dispatch, tracking and warehousing in one self-hosted system and you have someone comfortable with Docker Compose, MySQL and Redis. Do not adopt it if you only need a single narrow function, such as route optimization alone, or if you cannot run and patch your own infrastructure. Before committing, verify the AGPL-3.0 obligations against how you plan to expose the software to users, and check the console and API images referenced in docker-compose.yml actually match the version you intend to run.

Frequently asked questions

Official sources

1. fleetbase/fleetbase on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases