Constraints & Interoperability

Fleet Manager follows the Margo Workload Management API specification to the letter. That discipline is what lets any Margo-compliant device interoperate with the platform without custom integration. This page collects the constraints that matter when you connect a device.

Who this is for: OT engineers and integrators.

What the platform enforces

• Authentication is RFC 9421 HTTP Message Signatures only — no mTLS.
• Onboarding is { apiVersion, kind, certificate } in, 201 { clientId } out (camelCase).
• Capabilities use kind DeviceCapabilitiesManifest and are write-only (no read-back through the API).
• Desired state is a flat manifest with a monotonically increasing manifestVersion and sha256: content digests.
• Deployment profiles are limited to helm.v3 and compose.
• Deployment status is reported at /deployments/:id/status with kind DeploymentStatusManifest and one of the six lowercase states (pending, installing, installed, failed, removing, removed).
• Application YAML uses apiVersion: application.margo.org/v1alpha1, with the id under metadata.annotations.id and the profile at spec.deploymentProfile (singular).
• Content types are application/vnd.margo.manifest.v1+json for manifests and application/vnd.margo.bundle.v1+tar+gzip for bundles.

No platform-specific extensions

To preserve interoperability, the platform deliberately does not add endpoints or fields beyond the Margo spec — for example, there are no capability-read, verification, status-history, or deployment-summary endpoints on the device interface. If a field or endpoint isn’t in the Margo spec, a device won’t encounter it here.

End to end

Putting it together, a device:

1. Onboards — signs its request, sends { apiVersion, kind, certificate }, receives a clientId.
2. Reports capabilities — submits its DeviceCapabilitiesManifest.
3. Fetches desired state — reads the flat manifest, verifies digests, and installs the helm.v3 or compose workloads.
4. Reports status — posts DeploymentStatusManifest updates through the lifecycle states.

On the operator side, that same flow appears as devices coming online, the application catalog populating from registries, and deployments progressing through their states.