Apache 2.0 · pre-release · CNCF Sandbox candidate
The fleet orchestration layer has no neutral standard yet.
Swarmada is a vendor-neutral, Kubernetes-native control plane for coordinating fleets of heterogeneous robots — the way Kubernetes coordinates containers. Declare the fleet's desired state as custom resources; Swarmada reconciles robots from any manufacturer toward it, under one standardized API.
# three commands, one control plane
kind create cluster --name swarmada-dev
make install # generate and apply the CRDs
make run # run the control plane against your kubecontextWhere Swarmada sits in the stack
The robotics software stack already has neutral, open reference points at most layers. One tier does not.
A facility running automation today typically operates robots from three to five manufacturers at once, each with its own dashboard, fleet API, and update toolchain — with no single source of truth for fleet state. Open RMF is the closest existing project to this layer, but it is now controlled by a single vendor. Swarmada is built as an independent, Apache-2.0 project aimed at CNCF Sandbox, not a vendor's roadmap.
How it works
Operators declare intent as Kubernetes custom resources; controllers reconcile the fleet toward it. A per-manufacturer Fleet Adapter translates one standardized gRPC contract into each vendor's native API, so adding a robot family is additive rather than a change to the core.
| Kubernetes | Swarmada |
|---|---|
| Node | Robot / RobotClass |
| Pod / Deployment | FleetAction / FleetTask |
| Namespace | FleetZone |
| Rolling update | FirmwareRollout / ModelRollout |
kubectl | swarmctl |
A FleetZone is the unit of physical space and policy, a
Robot is the unit of capacity, and a FleetTask is a
composite objective that decomposes into FleetActions — the
atomic unit of dispatch. The task itself never crosses the Fleet Adapter
boundary; its actions do.
Declare the fleet, not the choreography
A zone, a robot, and a task — the same three primitives that run in the project's simulation scenarios.
apiVersion: swarmada.io/v1
kind: FleetZone
metadata:
name: warehouse-a
namespace: warehouse-a
spec:
displayName: "Receiving and staging area — east wing"
waypoints:
- name: charging-bay
x: 1.1
"y": 1.1
---
apiVersion: swarmada.io/v1
kind: Robot
metadata:
name: sim-robot-001
namespace: warehouse-a
spec:
manufacturer: Simulated
model: SimBot-v1
adapter:
name: sim-fleet-adapter
version: "0.1.0"
zone: warehouse-a
capabilities:
- name: navigation
type: hardware-native
pauseable: false
---
apiVersion: swarmada.io/v1
kind: FleetAction
metadata:
name: deliver-pallet-001
namespace: warehouse-a
spec:
type: Navigate
zone: warehouse-a
priority: High
requiredCapabilities:
- navigation
kubectl apply -f creates the zone and the robots; the robots'
declared capabilities determine which one the FleetAction is
assigned to. This excerpt is trimmed from
config/samples/demo_a.yaml,
which runs end-to-end — including task composition and fault recovery — in
config/samples.
Status
Pre-release. Public claims track the code, not the roadmap.
API
All thirteen CRDs are defined and generate under swarmada.io/v1.
Controllers
Reconciliation is implemented, wired into the manager, and tested for all thirteen CRDs, including capability derivation, assignment/preemption, dependency-graph composition with saga compensation, and fail-closed signature verification.
Adapters
An executable C0–C16 conformance harness is in-tree. Three reference adapters — ROS 2, VDA5050, and MAVLink — are maintained in their own repositories and clone in via make adapters.
All validation to date is in simulation; no physical hardware validation has been done. The architecture is documented as designed; this list is the authoritative statement of what runs today. See the full Status section in the repo README.
Get involved
Swarmada is developed in the open under Apache 2.0. Contributions, Fleet Adapter implementations, and design-partner conversations are welcome.