Build and run in-house
US$255,000
over three years
- Year 1 build (13 eng-mo) US$162,500
- Maintenance / yr (2.5 eng-mo) US$31,250
- Site visits / yr US$10,000
Build vs buy
Any strong robotics team can build the Linux, update and remote-access layer under its robots. The question is whether a senior engineer should spend the next year on it, and then keep it running for as long as the fleet exists. Here is the bill, in engineer-months, from our own build of it.
In-house platform, first board
Based on what this layer took us to build. Your numbers may be smaller; they will not be zero.
The gap
Most teams finish the prototype and then discover the ten things below have to exist before a customer's building can take twenty machines. A machine in a lobby, a warehouse or a paddock is also in the hands of anyone who walks up to it with a USB stick, so the disk, boot chain and credentials have to survive physical access.
From working prototype to twenty robots at customer sites
1 engineer-year = 13 engineer-months
Build the platform in-house
First customer fleet after 13 engineer-months
↑ The robot works on the bench the whole time, waiting for the layer underneath it to be safe to ship.
Run on Admiral
First robot on Admiral in day 1 · All 13 months stay on the robot
BoardBoard bring-up and kernel.
Replace the vendor BSP that has not been patched in years without losing the GPU, VPU, ISP, CSI camera or CAN drivers that never made it into mainline.
ImageImmutable OS image and signing.
Turn your application into a read-only, signed system image that boots the same way on every machine.
UpdatesA/B slots with health-gated rollback.
Two system partitions, a bootloader that counts failed boots, and a health check that decides whether the new slot stays.
RolloutsUpdate agent and staged rollouts.
Deliver updates to the right machines, canary first, inside a maintenance window, and pause when failures cross a budget.
IdentityPhysical lockdown and identity.
Secure Boot, TPM-sealed disk encryption, USB policy, per-device keys, and a way to revoke a machine that walks out the door.
AccessRemote access without inbound ports.
A shell, logs and file transfer through customer firewalls and cellular NAT, with no VPN and no shared keys.
TelemetryOffline-safe metrics and logs.
Buffer on the device while the link is down, drain in order when it returns, and alert when a machine goes quiet.
ConsoleFleet console and API.
Fleets, configurations, rollout status, device health and audit, usable by the people who are not the engineer who wrote it.
NetworkWi-Fi, cellular and failover.
Keep the machine reachable when the application crashes, the site Wi-Fi changes, or the modem drops.
PipelineCI, registry credentials and secrets.
Build, push, point a fleet at a tag, and deliver certificates to the device without baking them into the image.
Year two
Stable Linux releases weekly and CVEs land daily. Nobody assigns a full-time person to that, so it comes out of the robot roadmap a day or two at a time, or the fleet quietly falls behind.
Weekly kernel · Daily CVEs
1 month per year
Triage, rebuild, bench-test, roll out a signed image, and answer the customer security review.
1–2 days per incident
1 month per year
Power lost mid-update, a carrier change that broke the modem, an expired cert on site.
Every few weeks
0.5 months per year
Audit exports, diagnostics, and tooling so support stops waking the engineer who wrote it.
When hardware changes
2 months per board
Bootloader, kernel, drivers and a second image to keep in step with the first.
Every 18–24 months
1 month per kernel major
Out-of-tree camera, CAN and GPU drivers rarely survive a major upgrade untouched.
On a quiet year that is about 2.5 engineer-months (a few days a month), before any new board or JetPack upgrade. You can change that number in the calculator below, or set it to zero.
Your numbers
Put in what an engineer costs you, how many robots you will field, and what a site visit costs when an update goes wrong. The Admiral side uses list pricing.
Build and run in-house
US$255,000
over three years
Admiral · Growth
US$54,000
over three years, for 20 robots
US$201,000 stays on the robot over three years, plus the year you do not spend building the platform first.
Admiral side uses list package pricing for 20 devices (AUD shown at 1.52). Estimates from the inputs above, not a quote. Full pricing.
The decision
The month-18 trade-offs, side by side with building in-house and with the IoT tools: see the comparison →
Before you decide
Straight answers on where Admiral stops, what it takes from the machine, what happens in a hostile building, and what it costs to leave.
No. Your autonomy stack, ROS 2 nodes, drivers, operator console and data pipeline stay yours and run unchanged inside your container image. Admiral owns the layer below that image: the kernel, the A/B update slots, device identity, remote access and the fleet console.
Very little. AdmiralOS is a minimal immutable image with no general-purpose distribution and no container daemon under your workload, so on a Jetson Orin it leaves most of the RAM and all of the GPU to your stack. Kernel modules are compiled in and the full device tree is passed through, so cameras, CAN, serial and CUDA behave as they did on bare Ubuntu.
Your workload is a standard OCI image built from your Dockerfile and stored in your own registry. It runs on plain Docker on any Linux machine today, and it still runs the day you stop paying us. Leaving is one command: admrl device exit, in early access, 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. A USB reflash works on every device today. What boots afterwards under Secure Boot is on the leaving-admiral page.
No. Put one spare robot on Admiral and run it beside the fleet you have. Nothing changes for the machines you have not flashed. Move the rest when the spare has earned it, or never.
You can build it, the same way you could run OpenFaaS on raw EC2 instead of using Cloudflare Workers. Almost every team starts on the silicon vendor's image, discovers it has not been patched in six months or six years, tries to move to mainline, and discovers the NPU, ISP, cameras or power management depend on out-of-tree vendor patches. Doing that bring-up, A/B rollback, hostile-site lockdown and weekly CVE patching takes about a senior engineer for a year on the first board and keeps taxing the roadmap at scale. The engineer-month bill is on the build-versus-buy page.
A machine in a customer's building sits where strangers can touch it, plug a USB stick into it or pull its drive, and people do try. Keeping a field Linux box locked down against physical access while kernels release weekly and CVEs land daily is a full-time job; Admiral is built for that and for the enterprise security review that checks it. Every device connection uses hybrid X25519 + ML-KEM-768 post-quantum key exchange over TLS 1.3 by default. The root filesystem is read-only and verified on every boot by a dm-verity Merkle tree, disk encryption is sealed to the TPM against Secure Boot state, each device has its own hardware identity with short-lived rotated credentials, and every system binary is compiled from source with no distribution packages. The full posture, including the security-questionnaire support, is on the security page.
Launch is US$500 a month for up to 10 devices, Growth is US$1,500 for up to 100, and Scale is US$2,500 for up to 250, each with kernel and CVE patching, A/B updates, remote access and every supported board included. Past 250 you keep the Scale base and pay a falling per-device rate down to US$1. Logs, bandwidth, registry fallback, AirDetect and AdmiralAI are usage-based on top. The first five devices on any account stay free for building.
Build vs buy
Start free with 5 devices, or bring your fleet plan and we will price the move with you.