Trucking optimization for everyone
From one-truck owner-operators to 10,000+ truck mega-fleets. Route planning, fuel cost minimization, Hours of Service compliance, and fleet scheduling. Same algorithms for everyone—runs free in your browser or scales to enterprise.
I am a...
Why OTTO
Large fleet optimization vendors build for fleet-level KPIs—"how do I move 10,000 loads with 2,000 trucks?" OTTO serves both fleet-level assignment AND driver-centric decision support. Superior optimization means fewer empty miles, lower fuel costs, HoS compliance without violations, and better margins.
No Vendor Lock-In
The Vendor Risk
- Vendor gets acquired, roadmap shifts to new owner's priorities
- Support team restructured, your contacts disappear
- Pricing "aligns with portfolio strategy"
- Product gets folded into a suite you don't need
- Years of integration work held hostage
The OTTO Answer
- Code is AGPLv3—fork it, own it forever (free for fleets)
- Self-host at current capability, no permission needed
- Hire anyone to maintain your fork
- Roadmap diverges? Extend it yourself
- Audit the algorithms, verify the logic
License Model
AGPLv3 + Trucking Exception
Core engines are AGPLv3. Trucking companies use free forever—owner-operators to mega-fleets. Fork it, audit it, own it.
- Ralph – LP/MIP solver
- Velo – Routing engine
- Carta – Tile generator
- Locus – Geocoding
- Nexus – Document ingestion pipeline
- FuelWise, Arbor, Surge, HoSE, Tempo, Sigma, Pulse, Fuse
Commercial License
SaaS vendors and non-trucking companies require a commercial license. Integration layer and managed platform also require subscription.
- SaaS vendors offering OTTO as a service
- Nexus Gateway – TMS/ELD/LoadBoard connectors
- Managed hosting – Fully operated platform
- Priority support – SLAs and dedicated help
Deployment Flexibility
Future-Proof: EV & Autonomous Ready
Critical for Electric Fleets
Diesel trucks are forgiving. Misjudge fuel level by 5%? Coast to the next truck stop. Electric trucks aren't. Misjudge battery state by 5%? You're stranded on a highway with a 40-ton anchor.
OTTO's confidence-weighted state estimation was designed with EVs in mind from day one. Ready for mixed diesel/EV/autonomous fleets.
AI-Ready
┌─────────────────┐
│ LLM Agent │
│ (intent → API) │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ HoSE │ │ Velo │ │FuelWise │
│(6h left)│ │ (route) │ │ (cost) │
└─────────┘ └─────────┘ └─────────┘
LLM is the UX layer. OTTO engines are the truth layer. The AI doesn't hallucinate routes—it translates natural language into API calls and explains results in human terms.
Dispatchers speak, OTTO optimizes, LLM explains. No training required.
Ready to talk?
Whether you're evaluating for a 50-truck regional fleet or a 10,000-truck enterprise, we can help you understand how OTTO fits your operation.
For Owner-Operators & Small Trucking Companies
Route Planning
Optimal routes with truck restrictions, not Google Maps guesswork
Fuel Optimization
Find the cheapest stops on your route—save $50-100 per trip
HoS Calculator
Know exactly when you need to stop—avoid $16k violation fines
Load Decisions
"I'm in Tulsa empty"—what's my best next move?
Same algorithms the mega-fleets use
No install, no signup required. Runs entirely in your browser. The same optimization technology that Girteka uses for 10,000 trucks—available to you for free.
Built on Trusted Reality
Most fleet systems treat GPS as ground truth. But GPS drifts, signals conflict, telematics drop out, and driver apps disagree with ELDs. When your route optimizer doesn't know where your trucks actually are, every downstream decision inherits that uncertainty.
OTTO maintains a unified reality model. Multiple signals—GPS, telematics, driver app events, geofence triggers—are fused into consistent vehicle states. When signals conflict, OTTO doesn't guess. It maintains confidence levels and propagates uncertainty through the planning stack.
"Where is truck 47?" isn't a simple question. The GPS says one thing, the driver app says another, and the geofence fired twice. OTTO gives you a single answer you can trust—and tells you how confident it is.
Smarter Operational Events
When you know where trucks actually are—not just where GPS says they might be—every facility interaction gets more reliable.
Geofencing Without False Triggers
GPS drifts. Trucks "arrive" while still on the highway. Drivers "leave" while parked at the dock. Traditional geofencing fires on raw coordinates and generates noise.
OTTO's geofences require confidence thresholds. Result: alerts you can trust, not alert fatigue.
Detention Time That Holds Up
Detention billing disputes cost the industry billions. "We show you arrived at 2:15." "Our system shows 2:47." Without accurate timestamps, you're arguing over whose GPS was less wrong.
OTTO records confidence-weighted arrival times with full signal provenance.
Wait Time Prediction
"How long will I wait at this shipper?" Most systems can't answer this. They don't track dwell times accurately, so they can't predict them.
OTTO builds facility dwell profiles from accurate arrival/departure data. Dispatchers can route around facilities with 3-hour average waits.
Live ETA That Doesn't Jump
Nothing frustrates a receiver more than an ETA that changes by 45 minutes every refresh. Raw GPS + naive speed calculations produce unstable predictions.
OTTO's ETAs incorporate position confidence and historical corridor speeds. The estimate might be less optimistic, but it won't swing wildly.
Try it free in your browser
No signup, no install, no credit card. Plan your next route right now. Fuel optimization, HoS calculator, and truck-aware routing—all free.
Fuel Cards & Payments
Your fuel price data plus our optimization algorithms equals customer stickiness. Every optimized route drives transactions through your network.
Truck Manufacturers
Bundle OTTO with your telematics platform. "Buy our trucks, get optimization included." Turn vehicle sales into recurring software revenue.
Digital Freight Platforms
Make your carriers more efficient and they'll stay loyal. "Haul for us, get free planning tools." Better carrier economics means tighter rates are possible.
TMS & ELD Providers
Add planning to your platform without building it. OTTO integrates via clean APIs. Resell to your customer base or bundle with your offering.
Brokers & Shippers
Aggregate, anonymized data across the network. Lane-level capacity trends, rate indices, and benchmarking. "How do my rates compare to market?" answered with data.
Interested in partnering?
Whether you're a fuel card network, truck OEM, TMS provider, or freight platform, we'd love to explore how OTTO can add value to your customers.
Linear & Integer Optimization
Every fleet decision is an optimization problem. Which fuel stops minimize cost? Which routes satisfy time windows? How do you assign 100 shipments to 30 trucks?
Ralph solves these with the Revised Simplex method—walking the vertices of a high-dimensional polytope to find the optimum. For integer decisions (which truck, which stop), Branch & Bound builds a search tree on top, pruning impossible branches and converging on the optimal integer solution.
FuelWise uses Ralph to solve minimum-cost refueling LPs. Sigma formulates fleet plan selection as SCP/SPP and solves via Ralph’s MIP engine. HoSE builds a time-indexed scheduling model verified through Ralph’s LP solver.
No external solver dependencies. The same engine runs server-side and in-browser via WebAssembly—under 100ms for 1,000 variables.
Metaheuristic Search
Some problems are too large for exact solvers. Scheduling 1,000 deliveries across 50 trucks with time windows, capacity limits, and driver constraints? The search space is astronomical.
Arbor’s Adaptive Large Neighborhood Search starts with a feasible solution and iteratively destroys parts of it (removing requests), then repairs (reinserting optimally). Operators that find improvements get higher selection weights—the algorithm learns which strategies work.
For structured search, Beam Search explores a tree of partial solutions, keeping only the most promising ‘beams’ at each level. Combined with lower-bound pruning, it finds near-optimal solutions in bounded time.
Surge uses Arbor’s ALNS to solve rich VRP/PDPTW problems with 25+ constraint types. Population-based search with infeasible-space exploration beats BKS average distance on Solomon benchmarks.
Graph Routing
Routing is graph search at scale. A country-scale OSM graph has millions of nodes and edges. Naive Dijkstra explores them all. Smarter algorithms explore far fewer.
Bidirectional A* searches from both ends simultaneously. The forward frontier expands from origin, the backward from destination, guided by a Haversine heuristic. When they meet, the shortest path is found having explored a fraction of the graph.
ALT (A* with Landmarks and Triangle inequality) precomputes distances to strategic landmark nodes. The triangle inequality d(s,t) ≥ |d(s,L) − d(t,L)| gives a much tighter lower bound than Haversine alone, pruning 5–10x more of the search space.
Velo builds a CSR graph from OSM PBF files, supports truck/car/bike/foot profiles, and serves routes under 100ms at country scale.
Tile Rendering Pipeline
Every map tile is a geometry pipeline. A single 512×512 tile at zoom 14 may intersect hundreds of roads, buildings, and land-use polygons. Each must be clipped to the tile boundary, simplified for the zoom level, and rasterized—in under 75ms.
Sutherland–Hodgman clips polygons against the tile rectangle edge by edge. Vertices outside are discarded, new intersection points are inserted. The result is a clean polygon that fits exactly within the tile.
Douglas–Peucker then simplifies the geometry. Points that deviate less than a pixel from the line between their neighbors are removed. At low zoom levels this eliminates 90%+ of vertices, keeping tiles fast without visible quality loss.
Carta outputs both PNG raster tiles and Mapbox Vector Tiles (MVT) from the same pipeline. R-tree spatial indexing ensures only relevant features are processed per tile.
Geocoding Search
Turn text into coordinates in microseconds. Type “Buda” and get “Budapest” before your finger leaves the key. Misspell it as “Budepest” and still get the right result.
Prefix trie traversal handles exact prefix matching. Each keystroke walks one level deeper in the tree, instantly narrowing candidates from millions to hundreds. Autocomplete results appear in under 20μs.
Trigram fuzzy search handles typos and misspellings. Every place name is decomposed into overlapping 3-character sequences. A query like “Budepest” shares enough trigrams with “Budapest” to rank it first, even with the transposition.
Reverse geocoding uses a spatial grid to find the nearest named place to any coordinate. The grid partitions the map into cells—only the local cell and its neighbors are searched.
Quick Start
# Clone and build git clone https://github.com/ottofleet/otto.git cd otto && make all # Run all tests (1000+) make test # Start API servers make run-fuelwise-api # :8080 make run-velo-api # :8082 make run-carta-api # :8081 make run-locus-api # :8083 make run-ralph-api # :8084 # Build for WebAssembly make wasm # --- Or use Docker Compose --- # Download map data (Hungary, 350 MB) ./scripts/data-download-osm.sh hungary # Start all GIS services PBF_FILE=/data/hungary-latest.osm.pbf docker-compose up carta velo locus # For production: pre-build indexes first docker build -f docker/Dockerfile.data-builder -t otto-data-builder . docker run -v $(pwd)/data:/data otto-data-builder /data/hungary-latest.osm.pbf
See API Documentation for REST endpoint details.
For Docker deployment, see docker/README.md.
Transport-Agnostic Architecture
Every OTTO API is a pure C function that takes input and produces output. HTTP, WebAssembly, Unix sockets, embedded calls — these are thin wrappers over the same core. The demo is the product.
// Core function: transport-agnostic, runs anywhere int carta_render_tile(int z, int x, int y, uint8_t **out, size_t *len); // HTTP wrapper (Mongoose): ~10 lines // WASM wrapper (Emscripten): ~10 lines // Embedded call: direct invocation
See Design Manifesto for the full design philosophy.
Render Backend Agnostic UI Logic
ClayShards is built on a hybrid declarative/imperative design — declarative layout composition (Clay) with imperative immediate-mode interaction (widgets). Layout answers "where and how big?" Components answer "what is it, how does it behave?" The result: the best of both worlds when reasoning about layout and state.
UI logic produces render commands — WebGL, TUI terminal, OpenGL ES — these are thin renderers over the same component code. If it works in TUI, it works everywhere.
// UI code: renderer-agnostic, produces Clay render commands if (cs_button(CS_ID("submit"), "Submit", NULL)) { handle_submit(); } cs_input(CS_ID("search"), text, &len, max, "Search...", NULL); // WebGL renderer: ~200 lines (GPU-accelerated) // TUI renderer: ~300 lines (terminal ANSI sequences) // Same UI code, same layout, different pixels
See ClayShards Manifesto for the full design philosophy.
Defense-in-Depth Security Model
OTTO implements role-based privilege separation with multiple deployment modes. The same transport-agnostic code runs in three security configurations — choose based on your deployment requirements.
// Same handler interface works in ALL deployment modes: int vl_api_handle(VLAPIContext *ctx, const VLAPIRequest *req, VLAPIResponse *resp); // In-process: Mongoose → sh_worker_pool → handler (systemd sandbox) // WASM: Browser → WASM module → handler (WASM sandbox) // Process pool: Parser processes ↔ IPC ↔ handler (process isolation)
sh_worker_pool. Security from systemd hardening: restricted syscalls, read-only paths, capability dropping. Best performance.system(), exec*(), popen(), dlopen().
No runtime plugin loading. No broad filesystem access. OSM PBF parsing is offline-only —
derived indexes (.vlg, .lcx, .idx) are mmap'd read-only.
See Security Model for the full architecture and Security Roadmap for implementation status.
Core Engines
Planned Engines
Architecture
┌───────────────────────────────────────────────────┐
│ │
│ UI: React + ClayShards + WASM + APIs │
│ │
└─────────────────────────┬─────────────────────────┘
▼
┌───────────────────────────────────────────────────┐
│ │
│ Fleet: Arbor + Surge │
│ HoSE + Tempo + Sigma + Pulse │ ◄── planned
│ State: Fuse (signal fusion + state estimation) │ ◄── planned
│ Network: Atlas + Quota │ ◄── planned
│ │
└─────────────────────────┬─────────────────────────┘
▼
┌───────────────────────────────────────────────────┐
│ │
│ Domain: FuelWise + Velo + Carta + Locus + Nexus │
│ │
└─────────────────────────┬─────────────────────────┘
▼
┌───────────────────────────────────────────────────┐
│ │
│ Core: Ralph + Shared │
│ │
└─────────────────────────┬─────────────────────────┘
▼
┌───────────────────────────────────────────────────┐
│ │
│ Vendor: miniz + mongoose + Clay │
│ │
└───────────────────────────────────────────────────┘
Dependencies:
FuelWise ──► Ralph (LP solver)
FuelWise ──► Velo (routing)
Nexus ──► Shared (arena, JSON, XML, CSV, SHA-256)
Velo, Carta, Locus ──► Shared (geo, protobuf)
Shared ──► miniz (compression)
ClayShards ──► Clay (layout)
APIs ──► mongoose (HTTP)
Why C?
Memory Safety via Discipline
- Arenas & pools — bulk alloc, bulk free, no use-after-free
- Bounded buffers — snprintf everywhere, explicit null termination
- Overflow protection — calloc for safe allocation, bounds checks
- WASM sandbox — linear memory is bounds-checked
- Sanitizers — ASan + UBSan in all development builds
- 1000+ tests — edge cases, error paths, stress conditions
| Factor | C | Rust | Go | Zig | C++ |
|---|---|---|---|---|---|
| WASM size | ~2MB | ~4MB | ~10MB+ | ~2MB | ~4MB |
| GC pauses | None | None | Yes | None | Optional |
| WASM maturity | Excellent | Good | Poor | Good | Good |
| Compile speed | Fast | Slow | Fast | Fast | Slow |
| Complexity | Low | High | Low | Medium | Very High |
Performance Benchmarks
| Operation | Target |
|---|---|
| LP solve (1000 variables) | <100ms |
| Route calculation (country-scale) | <100ms |
| PNG tile generation (512×512) | ~75ms |
| Forward geocoding | <20μs |
| Autocomplete query | <20μs |
| Reverse geocoding | <30μs |
| PBF parse (300MB Hungary) | ~10s |
Design Principles
Scales With You
Same codebase from laptop to enterprise. Only the deployment changes.
Proof of Architecture
To prove our zero-dependency, WASM-first architecture works anywhere, we built the entire ClayShards UI system rendering to a 1970s-style terminal.
Same components. Same algorithms. Same WASM binary. Just rendered to a character grid with phosphor glow, scanlines, and CRT curvature via WebGL post-processing.
Start contributing
AGPLv3 licensed, well-documented, extensive test suite. Pick up an issue or propose a feature. We review PRs within 48 hours.