Leaving Admiral

Leaving Admiral is one command.

A platform you cannot leave is a platform you should not adopt. admrl device exit stages any disk image you choose at the tail of the disk, reboots into memory and writes it over the whole disk, for one robot or a whole fleet. It is in early access, and a USB reflash works on every device today.

How the exit works What you can read

admrl device exit amr-07 --image …ubuntu-24.04.img.xz

10:41:02 amr-07 staging 12.4 GB at tail of /dev/nvme0n1

10:46:40 amr-07 sha256 verified

10:46:41 amr-07 rebooting into recovery (RAM)

10:47:05 amr-07 writing image from sector 0

10:51:58 amr-07 image written, rebooting

10:52:00 amr-07 decommissioned · identity revoked · escrow deleted

Early access. Illustrative timings on a 12 GB image over a site link.

Early access

Four steps, for one robot or a whole fleet.

admrl device exit is in early access. Talk to us and our engineers will run it with you, from one spare robot to the whole fleet.

Step 1
Pick the image you want on the disk.

Any raw disk image: stock Ubuntu, JetPack, your own Yocto build, or a backup you took before you moved. Host it anywhere the device can reach.
admrl device exit amr-07 --image https://releases.acme.io/amr-ubuntu-24.04.img.xz --sha256 3f9c…
Step 2
The device stages it at the tail of the disk.

The device carves a staging area from the end of its data disk, streams your image into it and checks the hash you gave it. Your workload keeps running on the active slot while it downloads.
staging /dev/nvme0n1p9 12.4 GB verified
Step 3
Reboot into memory, write your image from sector 0.

The device reboots into a RAM-only recovery initramfs and writes your image over the whole disk from the first sector. The staging area is the last thing it overwrites before it reboots into your image.
exit: writing 12.4 GB → /dev/nvme0n1 … done, rebooting
Step 4
Admiral forgets the device.

Its identity is revoked, its escrowed disk recovery key is deleted and it leaves your fleet with no Admiral partition or agent left on the disk. Secure Boot keys live in the firmware, so the next section covers what boots afterwards.
amr-07 decommissioned identity revoked escrow deleted

By hand

Leaving without the command.

Every device can also be moved by hand with tools you already have, the same way you would move any board to a new image.

Your workload already runs elsewhere.

It is a standard OCI image built from your Dockerfile and stored in your own registry, so it runs with docker or podman on any Linux machine.

Copy your data off first.

Pull what you need out through a workload shell, or reveal the device disk recovery key in the console and read the encrypted data partition yourself.

Reflash the device.

Boot an installer from USB, or write a removable drive on another machine, as you would on any new board. On Jetson, NVIDIA's recovery-mode flash puts back stock JetPack and its boot firmware.

Remove it from your fleet.

Removing the device in the console revokes its identity and access, so it can no longer reach Admiral.

Secure Boot

What boots after you leave.

Secure Boot keys live in the board's firmware, so a reflash leaves them in place. What boots afterwards depends on how the board was enrolled.

Secure Boot off, or in setup mode.

Your image boots as it would on a fresh board. Most ARM SBCs and development boards sit here.

UEFI Secure Boot, the default profile.

db trusts the Admiral CA that signs AdmiralOS and the Microsoft UEFI CAs side by side, so a stock Ubuntu, Debian, Fedora or Windows loader boots after you leave without touching firmware settings. We ship dbx and SBAT updates with the OS so revoked loaders stay out.

UEFI Secure Boot, Admiral-only db.

Some sites ask for a db with no third-party CA. An exit image then needs a loader signed by a certificate in db, so we co-sign your loader, or you clear the keys from firmware setup and enrol your own, which most x86 boards allow.

Who holds the platform key.

Boards enrolled today hold an Admiral platform key. Provisioning with a platform key your organisation generates and holds is in development.

Jetson and other fused boot chains.

Burning a PKC fuse is permanent, so we only ever burn a key you generated and hold, and an exit image signed with your key boots.

Open source

The parts you can read today.

We are opening the stack from the edges in. The transport library is next, then the agent that runs on the machine, so your security team can read what is on the robot rather than take our word for it.

admrl MCP server

The MCP server your coding agents use to read fleet state and logs. Public on GitHub.

GitHub ↗

Platform API and CLI

The documented API every console feature is built on, and the admrl command line that drives it.

Docs ↗

EdgeWire

The QUIC-over-ICE transport library under remote access and device sessions. Being prepared for public release.

Questions

What engineers ask about leaving.

What about the data on the disk?

A reflash writes every sector, so nothing on the disk survives it. Copy what you need first through a workload shell, or reveal the disk recovery key in the console and read the encrypted data partition yourself.

Can we do this for a whole fleet?

Yes. Exit runs as a rollout like any other, canary first and inside maintenance windows, with the same failure budget that protects a normal release. During early access our engineers run fleet exits with you.

What if a device is offline or unreachable?

Reflash it from USB like any other board. Changing the disk of a device you physically hold never needs our cloud.

Does our container need to change?

No. The workload you shipped to Admiral is a standard OCI image in your own registry. It runs with docker or podman on your new image the same day, which is the point of the boundary.

Why publish this at all?

Because the teams we want to work with will not adopt a layer they cannot leave, and opening up the stack only counts if leaving is real too.