New · v00052 Read the changelog ↗

Build vs buy

What "we will build it ourselves" actually costs.

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

Board bring-up and kernel
2 months
Immutable OS image and signing
1 month
A/B slots with health-gated rollback
2 months
Update agent and staged rollouts
1 month
Physical lockdown and identity
1 month
Remote access without inbound ports
2 months
Offline-safe metrics and logs
1 month
Fleet console and API
1 month
Wi-Fi, cellular and failover
1 month
CI, registry credentials and secrets
1 month
First version you can ship on
13 months
Then, every year
2.5 months
Then, every new board
2 months

Based on what this layer took us to build. Your numbers may be smaller; they will not be zero.

The gap

The robot is ready. The fleet is a year away.

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

Board Board bring-up and kernel 2 mo
Image Immutable OS image and signing 1 mo
Updates A/B slots with health-gated rollback 2 mo
Rollouts Update agent and staged rollouts 1 mo
Identity Physical lockdown and identity 1 mo
Access Remote access without inbound ports 2 mo
Telemetry Offline-safe metrics and logs 1 mo
Console Fleet console and API 1 mo
Network Wi-Fi, cellular and failover 1 mo
Pipeline CI, registry credentials and secrets 1 mo

↑ 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

Day 1 Flash & enrol Done
Months 1 to 13 Your team ships autonomy, perception, customer pilots and the second site Signed OS · A/B rollback · Hostile-site lockdown · Remote access already underneath

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.

2 mo

ImageImmutable OS image and signing.

Turn your application into a read-only, signed system image that boots the same way on every machine.

1 mo

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.

2 mo

RolloutsUpdate agent and staged rollouts.

Deliver updates to the right machines, canary first, inside a maintenance window, and pause when failures cross a budget.

1 mo

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.

1 mo

AccessRemote access without inbound ports.

A shell, logs and file transfer through customer firewalls and cellular NAT, with no VPN and no shared keys.

2 mo

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.

1 mo

ConsoleFleet console and API.

Fleets, configurations, rollout status, device health and audit, usable by the people who are not the engineer who wrote it.

1 mo

NetworkWi-Fi, cellular and failover.

Keep the machine reachable when the application crashes, the site Wi-Fi changes, or the modem drops.

1 mo

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.

1 mo

Year two

The platform keeps costing you after it ships.

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.

  1. Kernel and CVE patching.

    Weekly kernel · Daily CVEs

    1 month per year

    Triage, rebuild, bench-test, roll out a signed image, and answer the customer security review.

  2. Field incidents.

    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.

  3. Ops and customer requests.

    Every few weeks

    0.5 months per year

    Audit exports, diagnostics, and tooling so support stops waking the engineer who wrote it.

  4. Each new compute board.

    When hardware changes

    2 months per board

    Bootloader, kernel, drivers and a second image to keep in step with the first.

  5. Each OS or JetPack major.

    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

Build cost and field cost, with your inputs.

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.

Set site visits to 0 if you only want to compare the engineering build.

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

Admiral · Growth

US$54,000

over three years, for 20 robots

  • Per year US$18,000
  • Kernel, CVEs and all boards Included
  • A/B rollback on bad updates Included

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

You are deciding where your product ends.

  • You keep the robot. Autonomy, ROS 2, drivers, the operator console and your data pipeline stay yours, as a standard OCI image in your own registry.
  • Admiral takes the layer below the container. Kernel, A/B update slots, device identity, remote access and the fleet console, maintained for every board we support.
  • You can leave. The image you ship to Admiral runs on plain Docker the day you stop paying us. An in-house stack is usually tied to the one engineer who wrote it.

The month-18 trade-offs, side by side with building in-house and with the IoT tools: see the comparison

Before you decide

The questions robotics teams ask first.

Straight answers on where Admiral stops, what it takes from the machine, what happens in a hostile building, and what it costs to leave.

Does Admiral replace my robot software?

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.

How much of the robot does Admiral take?

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.

Are we locked in? Can we leave?

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.

Do we have to migrate the fleet we already have?

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.

We have the engineers to build this. Why would we buy it?

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.

Will it pass our customer's security review?

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.

What does it cost once we are past five robots?

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

Put the engineer-months back on the robot.

Start free with 5 devices, or bring your fleet plan and we will price the move with you.

Start free