Fleetless

Fleetless connects a ROS2 robot to the internet through a small bridge process, lets you decide exactly what part of that robot a client app is allowed to see or do, and gives that app a REST + realtime API and a TypeScript SDK to consume it. Fleetless has no end-user UI of its own — the console is where a developer configures a robot; the apps your users touch are yours to build.

Where to start

• Getting Started — install the bridge, connect a robot (or a fake one, no hardware required), expose a value, and read it back from an app. The whole path fits in an afternoon.
• Concepts — how a robot’s ROS graph becomes a slug-addressed API, how apps/end users/roles fit together, what happens when a robot goes offline, cameras, URDF/mesh rendering, and MCP.
• API Reference and SDK Reference — the wire and the TypeScript client, respectively.

The shape of the thing

• Bridge — a ROS2 package you install on the robot. It talks a versioned protocol to the cloud and does nothing else; it has no HTTP server, no shell access, no systemd integration — ROS-pure by design.
• Cloud — the REST + realtime API, auth, time-series storage and the developer console’s backend. One process your app talks to.
• Console — where a developer configures what a robot exposes (which topics, which services, under what names) and to which apps, with which role, a given end user gets access.
• Your app — anything that speaks HTTPS and, optionally, the @fleetless/sdk npm package. Web, mobile, server-side — the API doesn’t care.

A robot’s ROS names never leak to a client app: every exposed topic, service or action gets a stable slug, chosen by the developer in the console, decoupled from whatever the robot happens to call it internally. Renaming a ROS node does not break anyone’s app.