Your Dockerfile
Build with docker build or BuildKit, exactly as you do today. Admiral runs the image you already ship.
Move to Admiral
Keep your stack. Lose the infrastructure.
Admiral runs the container image you already build. Flash one robot, run it next to your fleet, and move the rest when you are ready. No rewrite, no big-bang cutover.
What changes in your repo
Dockerfile unchanged
.github/workflows/ unchanged
src/ unchanged
+ fleet.yaml new · 12 lines
- scripts/ota-agent/ deleted
- ansible/ deleted
- vpn/ deletedIllustrative. Your repo, minus the parts you no longer have to own.
What you keep
Everything that makes your robot yours.
Your registry
GHCR, ECR, Artifact Registry, Docker Hub, ACR, Harbor or Quay. Devices get short-lived pull tokens, never your secrets.
Your CI
Push a tag, point a configuration at it, roll it out. No new build system, no Yocto layer to maintain.
Your robot code
ROS 2, DDS discovery, CUDA, SocketCAN, serial, V4L2 cameras and GPIO all run unchanged, with the full /dev tree.
The move
Four steps, starting with one robot.
- (01)
Point Admiral at your image
Create a configuration with the image you already publish. Add registry credentials if it is private.
image: ghcr.io/acme/autonomy:v2.14.0 - (02)
Make an installer for your fleet
Create a fleet and a provisioning profile. Download one image for x86, ARM or RISC-V with enrolment built in.
acme-amr-installer.img - (03)
Flash one robot
dd, Etcher or your factory jig. It installs, claims itself into the fleet and starts your workload on first boot.
sudo dd if=acme-amr-installer.img of=/dev/sdX - (04)
Canary, then the rest
Run the pilot alongside your existing fleet. When it holds up, move the rest with a canary rollout that rolls itself back if health checks fail.
admrl rollout create -f fleet.yaml --canary 1 --watch
Robot for Hire moved Rocco, their Unitree G1 humanoid, onto Admiral and demonstrated it live at AWS the next day. Read the story
What changes
The few things that move, and why they are better in the platform.
Ubuntu + SSH + scripts
Immutable OS with A/B updates
You stop maintaining the base image. Admiral owns boot, kernel and OS updates.
Your Wi-Fi manager
Fleet networking settings
NetworkManager or wpa_supplicant wrappers move to config, so devices stay reachable even if the app crashes.
VPN or port forwarding
Outbound-only access
ssh root@<device-id>.admrl works through the Admiral Mesh via the admrl CLI. No public IP, no inbound ports, no shared keys.
Keys baked into images
Secret files
Certificates and credentials are delivered read-only to /admrl/secrets, out of your image and history.
Full detail in the platform boundary guide ↗
Coming from
Wherever you are starting.
Moving from
A homegrown stack
Ubuntu images, Ansible or shell scripts, a VPN and a custom update agent. Your app is probably already in a container, which is all Admiral needs. The scripts, agent and VPN become things you delete.
Moving from
Balena
Your services are already container images. Bring them as one workload: a single image can run a supervisor and several services, with full hardware access by default.
Moving from
Mender
Swap rootfs update artifacts for an OCI image. A/B partitions, signed updates and automatic rollback come built in, so there is no client to integrate or image layer to maintain.
Low risk by design
Try it on one robot. Keep it if it works.
- 5 devices free, forever. No credit card, no trial clock.
- Side by side. Pilot devices run next to your existing fleet.
- Standard images. Your workload still runs anywhere Docker does.
- Engineers, not tickets. We work the first devices through with you.
Questions teams ask
Do I have to rewrite anything?
Usually not. Application code, robotics middleware and hardware control stay in your image. The common changes are moving Wi-Fi management into fleet networking and calling platform reboots instead of rebooting from inside the app.
Can I run Admiral next to my current fleet?
Yes. Start with one device on the free tier, run it alongside your existing robots, and move the rest when you are ready. Nothing changes for devices you have not flashed.
What about custom kernels and drivers?
The kernel enforces module signatures, so out-of-tree drivers are built with the Admiral kernel and shipped in your Admiral OS image. Tell us your board and drivers and we will scope it with you.
Am I locked in?
Your workload is a standard OCI image built with standard tools. It runs with docker on any Linux machine, today and after you leave.
Do you help with the move?
Yes. Our engineers work through the first devices with you, from configuration to the first rollout. Design partners get hands-on onboarding as part of the program.
Move to Admiral
Flash one robot this week.
Start free with 5 devices, or tell us about your fleet and we'll plan the move with you.