fleetbase - Moses Yebei

The Problem

Fleetbase addresses the complexity of building logistics and supply chain operations software from scratch. Organizations needing fleet tracking, order management, and delivery optimization typically face fragmented tools or expensive custom development. Fleetbase attempts to provide a modular operating system with a web console, API backend, and extension architecture.

What This Does

The repository contains two main projects: console/ (589 files) is an Ember.js-based admin dashboard for managing fleet operations, orders, and organizations. The api/ directory (96 files) is a Laravel PHP backend providing REST endpoints. The system supports real-time tracking, order workflows, and integration with external services.

The architecture is deliberately modular—the console/lib/fleetbase-extensions-generator/ suggests a plugin system for extending functionality. Infrastructure files (infra/, docker/, builds/) show Kubernetes and Docker support for deployment.

How It Is Wired

The import graph shows 432 internal modules with only 24 import edges—a surprisingly sparse dependency structure. The most-connected module is console/app/utils/remove-boot-loader (10 modules import it, 0 it imports), making it a leaf utility with wide reach. The console/config/environment module imports 4 modules and is imported by 0, marking it as a source node. No circular dependencies exist.

Entry points are api/resources/js/app.js and console/app/app.js. The console's admin controllers (console/app/controllers/console/admin/organizations/index.js) handle organization management. The API's RouteServiceProvider.php routes requests to controllers.

The console relies on adapters (console/app/adapters/application.js, brand.js) for data access. These form a thin layer between UI components and the API. The console/app/components/admin/widget/ directory contains dashboard widgets (kpi-tile.js, list-panel.js, chart-panel.js) that consume these adapters.

The wiring for external effects (database writes, API calls) is not fully mapped in this analysis—the import graph shows internal structure but not runtime behavior. The API's Laravel controllers and models handle persistence, but the specific call paths are unverified.

How To Use It

Setup: The repo has package.json files in both console/ and api/, plus api/composer.json for PHP dependencies. Dockerfiles exist for container builds. The README doesn't document setup commands clearly.

Configuration: Environment templates exist at api/.env.example and console/environments/.env.development (note: the latter is committed—see health issues). The API uses Laravel's standard .env configuration.

Running it: No explicit run instructions are documented in the README excerpt. The console/Dockerfile suggests a containerized deployment. Without documented commands, you'd need to inspect the Dockerfiles and scripts/ directory for the actual build process.

Real-World Use

A delivery company would deploy the API backend with PostgreSQL, configure the console to point at it, and manage drivers, orders, and zones through the dashboard. The console's dashboard widgets provide real-time KPIs; the order board offers Kanban-style workflow management. The extension generator enables custom modules for specific logistics workflows.

Code Health & Issues

Static analysis found 23 issues (6 high, 17 medium) across 4 categories:

High - Deep nesting (x15): api/app/Providers/RouteServiceProvider.php, console/app/controllers/console.js, console/lib/fleetbase-extensions-generator/index.js have indentation depth of 8, making control flow hard to follow.
High - Duplicated code: 307 repeated 6-line blocks across 83 files, including api/resources/lang/*/validation.php translation files.
Medium - Oversized file: scripts/package-linker.mjs at 1059 lines.
Medium - High branching density (x6): console/app/components/admin/widget/list-panel.js has 32 branch points over 72 lines.

The code health audit adds 11 findings (2 high, 7 medium, 2 low):

High - Committed .env files: console/environments/.env.development and .env.production are tracked. Rotate any credentials they contain.
High - Unpinned GitHub Actions: Workflows use @v2, @v4 tags instead of commit SHAs—a supply-chain risk.
Medium - No least-privilege token permissions in create-release.yml.
Medium - No Dependabot/Renovate configured despite 5 manifest files.
Medium - Mutable base images (node:22.22.0-alpine3.22, nginx:alpine).
Medium - No dependency vulnerability scan in CI.
Medium - No pre-commit secret gate.
Medium - persist-credentials: false not set on checkout in cd.yml.
Medium - No non-root user in the Dockerfile.

Tests exist (197 files) and CI is configured, but the committed secrets and unpinned actions are the most urgent fixes.

The Bottom Line

Fleetbase is a substantial, well-structured logistics platform with real functionality and a sensible modular architecture. The sparse import graph suggests clean boundaries between components. The main concerns are operational: committed .env files, unpinned CI dependencies, and no automated dependency updates. Teams wanting a self-hosted logistics platform with a modern admin console and API should evaluate it, but address the security findings before production use.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

762 files

JavaScript429
PHP70
YAML48
Markdown16
JSON10
Shell5

ReactExpressLaravelTailwindDockerKubernetes

Module dependencies

The 10 most depended-upon modules of 432, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_app_utils_remove_boot_loader["remove-boot-loader"] n1_sole_config_utils_to_boolean["to-boolean"] n2_le_config_utils_fix_api_host["fix-api-host"] n3_api_resources_js_bootstrap["bootstrap"] n4_ole_app_adapters_application["application"] n5_ents_admin_widget_list_panel["list-panel"] n6_ontrollers_auth_verification["verification"] n7_ole_app_deprecation_workflow["deprecation-workflow"] n8__utils_get_permission_action["get-permission-action"] n9_sole_app_validations_onboard["onboard"] n2_le_config_utils_fix_api_host --> n1_sole_config_utils_to_boolean

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them console/environments/.env.development, console/environments/.env.production, infra/helm/secrets.env

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium7

low2

Pin third-party GitHub Actions to a commit SHAhigh12 occurrences

.github/workflows

docker/setup-buildx-action@v2, aws-actions/configure-aws-credentials@v4, aws-actions/amazon-ecr-login@v1, docker/bake-action@v2

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Remove the committed .env and rotate what it holdshigh2 occurrences

console/environments/.env.development

console/environments/.env.development, console/environments/.env.production

A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.

Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/create-release.yml

1 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

5 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

console/Dockerfile

node:22.22.0-alpine3.22, nginx:alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

Set persist-credentials: false on checkoutmedium

.github/workflows/cd.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Add a non-root USER to the imagemedium

console/Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/cd.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.