How it works

From your Dockerfile to a running fleet.

You ship one container image. Admiral builds the signed operating system for your hardware, enrols each device on first boot, rolls updates out safely, and keeps every machine reachable in the field.

Start free with 5 devices Explore the docs ↗

Build

Package your stack as one Dockerfile.

Start from your existing Dockerfile and container registry. Admiral compiles it into a signed, read-only operating system image for your target board across x86_64 and ARM64, including NVIDIA Jetson, Rockchip RK3588 and Allwinner SoCs.

Dockerfile

FROM ubuntu:26.04
RUN apt-get update && apt-get install -y \
    ros-jazzy-base perception-stack
COPY config/ /etc/admiral/
CMD ["/opt/perception/run"]

Enrol

Flash the board once; it claims itself on first boot.

Write the installer image with dd, Etcher or your factory jig. On first boot the device generates a hardware-backed identity, connects outbound over the Admiral Mesh, and joins its fleet without anyone on site.

Terminal

$ sudo dd if=acme-amr-installer.img of=/dev/disk2

Writing the installer image…

100%

✓ Image written

✓ Claims itself into the fleet on first boot

Deploy

Roll releases out across A/B slots with a failure budget.

Stage an update to one canary machine, widen in a bounded window during the site's maintenance hours, and let any machine that fails its health check revert to the working partition on its own.

Updates send only what changed

Fleet manager Deploying

Rollout v2.14.0 · canary 1

Production

amr-syd-01 Converged (canary)

amr-syd-02 Converged

amr-mel-04 Verifying health

amr-bne-02 Queued for window

Operate

Inspect health, logs and workload shells from your desk.

Metrics, workload logs and live screen captures stream over the device's outbound connection. Open a shell inside the running workload with admrl exec or the web console without opening inbound firewall ports.

Device monitor Online

amr-prod-aus-0187 v2.14.0

CPU

12.4%

Temperature

42°C

Slot A (active)

Verified

Slot B (fallback)

v2.13.2

What this changes

What you stop maintaining in-house.

What you tested is what runs.

The root filesystem is read-only and verified on boot, so every machine in a fleet runs the exact build from CI without drifting over time.

Bad updates recover without a site visit.

Dual A/B partitions and health-gated rollouts ensure a broken release either reverts on the device or pauses the rollout before the fleet is touched.

Driven from CI, the CLI or the console.

Every configuration, rollout and diagnostic action is exposed through the admrl CLI, REST API, webhooks and MCP server.