# Why Roboflow Sells Hardware, and When to Use Your Own > Source: > Published: 2026-11-13 23:44:48+00:00 Deploy computer vision at the edge with Roboflow, using managed hardware or devices you already own. When you choose edge AI hardware, you also choose who maintains its operating system: JetPack and driver upgrades, security patches, network settings that survive a reboot, and site visits when a device can’t be fixed remotely. Use a Roboflow Edge appliance from $8,000, with five years of RoboflowOS over-the-air updates included. Roboflow is a software company, and companies use our tools to build computer vision applications that help them deliver state of the art products, improve human safety, and cure diseases. Many of these customers ask us for hardware recommendations that work well with our products such as Deployment Manager (opens in a new tab). Deployment Manager lets you run computer vision models on your own devices and manage those devices from the Roboflow platform. You link each device once, then securely push models and Workflows to it. Deployment Manager manages the software on the device. But it only covers part of the stack necessary to deploy a reliable vision AI system. You still need to choose the hardware and keep its operating system and drivers, plus JetPack on a Jetson, up to date and ensure the versions are supported on the device. A power outage could reboot a host you manage, and its camera network ports may come back without their static IP addresses. Every container would report healthy, but your line would get no images until you set the addresses again by hand. A bug in the Jetson Ethernet driver could drop cameras off the network, and a newer JetPack release may fix it but installing that release on the host takes a site visit or a replacement unit. A log file will fill the disk and lock you out of the host. Recovery means reflashing it with a JetPack version that the inference runtime supports. Each case needs a fix in the host operating system, and these hosts have no remote way to install one. We sell hardware because these and many other problems can only be solved by providing the entire stack: hardware and software, together, in our hardware products that ship with RoboflowOS (opens in a new tab), our immutable OS with over-the-air updates. There are five recurring activities maintaining a Jetson fleet requires. You or your integrator 1) maintain an OS image for each board type, 2) qualify each new JetPack and driver upgrade against the inference runtime and your cameras, 3) apply security patches and track device patch status for audits, 4) recover failed devices, sometimes requiring a site visit, and 5) record any fix a technician makes by hand at one site so the next site gets it too. Some of these jobs are done on short notice in an emergency. Some, like ensuring security patches are applied, are easy to procrastinate until it's too late, or are easily forgotten in a company reorg or with staff changes. All require taking someone’s time and attention to ensure they’re done correctly. Companies often implement on-call schedules and hire or upskill technical staff when they choose to in-house support these deployments. Roboflow built RoboflowOS to meet our own field deployment team’s demanding requirements for uptime and ease of maintenance. Ensuring hardware compatibility Without RoboflowOS, you must make all of your software and hardware versions work together, and the possible combinations form a complicated matrix. Once you develop an OS image that works, you can create an image and add device-management software, such asAllxon (opens in a new tab), for out of band device updates. You can also build your own operating system image and update system on an established update framework or one you write. You then choose the JetPack version and camera drivers and test each image before you deploy it. You’ll want to ensure special optimizations like TRT compilation work on all devices. JetPack is Ubuntu-based, so a third approach is a commercially maintained Ubuntu. Canonical publishes certified Ubuntu images (opens in a new tab) for listed Jetson Orin and Thor developer kits, if you’re comfortable with that route. Each approach leaves you to test the camera drivers and inference runtime together on each board type whenever its operating system or drivers change. On a RoboflowOS appliance, we run that test on every image before release, on the same hardware you receive, because we build the inference runtime too. You test changes with your cameras and Workflows under production conditions. Start with a hardened system image We choose the board, operating system, and drivers for each appliance. We run the inference runtime and edge services in containers, separate from the read-only operating system image, so updating or replacing an application leaves the operating system untouched. This is a major win for security teams. Units on the same image start with the same OS files. OS-level camera and network compatibility We ship camera driver and network fixes in the RoboflowOS image. On a host you manage, you, your integrator, or the host vendor make those changes. For example, for supported GigE camera interfaces, we spread network receive processing across CPU cores and let camera software request larger network buffers. This kind of OS-level optimization improves stability and throughput. Network settings survive a restart RoboflowOS keeps wired network settings in one persistent store on the device. The store holds static addresses, gateway, DNS, MTU and camera-port tuning, and at every boot RoboflowOS rebuilds the live network configuration from it. An appliance therefore keeps the static addresses that the host in the first case loses. You change these settings (opens in a new tab) from the Roboflow platform, a USB drive or the local setup screen, and a technician can configure the network at the line without a laptop. When you change them through the platform, the device checks that it can still reach our servers and, if it cannot, starts a rollback to the previous settings. RoboflowOS secure updates The OS update agent (opens in a new tab) updates RoboflowOS separately from the applications running on top of the OS. The OS update agent replaces the base image or updates individual extensions, and an extension-only update leaves the base image in place. We deliver driver fixes over the network through the OS update agent. We qualify major JetPack upgrades separately for each board, so an AGX64 can move to a new JetPack release before an NX16 does. Roboflow Provides Stable Layers; You Build On Top Roboflow maintains RoboflowOS. You choose the camera view and set the lighting so defects are visible, then mount and protect the equipment and connect it to plant controls. You also validate the inspection under production conditions with your parts, lighting and line rate. Layer Our appliance Hosts you manage Camera view, lighting, mounting, acceptance testing You You Workflows and models You choose and validate them, and the platform delivers them You choose, validate and deploy them, through Deployment Manager where you install it Inference runtime containers We publish them, and Deployment Manager applies the version you set The same where you install Deployment Manager, and otherwise you apply them Device agent We publish it, and it follows its configured update policy We maintain them through the RoboflowOS update path You Hardware We supply it You or your vendor Plant network, firewall, gateway host You You Running on a plant OT network Your vision system probably runs on your plant's OT network, separate from the internet and corporate IT. Each outbound connection needs a firewall rule that names its destination hosts and ports, and your security team can route allowed traffic through a proxy that inspects TLS. If your plant prohibits remote shell access, a host repair that needs a shell needs to wait for a technician visit, sometimes with an escort and safety training. You approve changes through change control and apply them in maintenance windows (opens in a new tab), so a host setup that works on a bench can take weeks to reach your line unless you already have a remote device management system for deploying ML models. Secure Gateway (opens in a new tab), an Enterprise add-on, runs on a host you operate, usually in the plant DMZ. It proxies each device's Roboflow API requests, model downloads and container pulls, and it caches model files and container images for reuse. Allow the gateway outbound HTTPS on port 443 to api.roboflow.com and repo.roboflow.com, and add serverless.roboflow.com if you use hosted inference. Name the domains in the firewall rule, not IP address ranges. Install the gateway with Docker, Podman on RHEL 9 (opens in a new tab) or MicroShift (opens in a new tab). The gateway narrows the firewall's allowed destinations to those domains, and your devices reach your account on Roboflow servers through it. Deployment Manager can also run service containers next to inference on the device. The OPC UA server (opens in a new tab) publishes inference results as tags on TCP port 4840 for PLCs and SCADA systems, and a PLC relay (opens in a new tab) reads and writes Allen-Bradley, Modbus TCP and Siemens S7 tags. The event store (opens in a new tab) saves inference events in SQLite on the device and keeps media in local files, with optional cloud backup. The AI1 Smart Camera puts a camera, a light and a computer in one housing. The NX16, AGX64, and Thor128 all work with supported cameras (opens in a new tab) of your choosing. All devices run RoboflowOS and Roboflow Deployment Manager. 1 x 5 GbE, 1 x 100 GbE QSFP28 that breaks out to 4 x 25 GbE $16,000 The AI1 fits a fixed inspection view that its built-in optics cover. Its 8 MP sensor captures 3840 x 2160 pixels. An on-demand calibration (opens in a new tab) sets the electronic focus, so keep the camera-to-part distance relatively stable after you calibrate. The AI1 is fantastic for proving out the feasibility of edge compute paired with computer vision, situations where counting or defect detections are between a few inches and dozens of feet away from the camera. The AI1 is extremely capable, but the AI1 does not suit every application: the housing has an IP54 rating and the AI1 uses a rolling shutter, so a fast-moving part can appear skewed. If you use your own cameras, lenses or lighting, test a Roboflow Edge computer (opens in a new tab) with every camera stream and required service active, for a few hours at the site's ambient temperature. Measure processed frames per second for each camera and camera-to-result latency, count dropped frames, and check for thermal throttling. Pick the smallest computer that sustains your required rate and latency. Pick the NX16 for a station with multiple cameras, because it has six PoE ports on a shared 150 W budget. Pick the AGX64 for higher-resolution cameras and bigger models. It has 64 GB of memory against the NX16's 16 GB, plus four PoE ports and two 10 GbE ports. The Thor128 has one 5 GbE port and one 100 GbE QSFP28 port, so its cameras connect through a PoE switch. To try RoboflowOS on a board you already have, use the RoboflowOS Evaluation Image, which we build for the Raspberry Pi 4, the Raspberry Pi 5 and the Jetson Orin Nano developer kit. On a Raspberry Pi, choose "Roboflow OS Lite" inAdd a Device (opens in a new tab) in Deployment Manager, then write the generated image to an SD card. For the Orin Nano, contact us. To change the Evaluation Image's operating system version, write a new image to the board. Over-the-air RoboflowOS updates come with an appliance. What’s included The list price of each appliance includes five years of RoboflowOS updates from the purchase date. Roboflow maintains the OS image, delivers security patches through the OS update agent and qualifies JetPack and driver upgrades against Roboflow Inference on each appliance board. When the five years end, you can add more years for the same unit. A unit you buy in early 2027 gets updates into early 2032. NVIDIA'slifecycle page (opens in a new tab) lists the Jetson Orin NX 8GB, Orin NX 16GB and AGX Orin 64GB as available through January 2032 and the Jetson T5000 through August 2035. The hardware has a one-year warranty. To compare costs, estimate the five recurring jobs from your records or pilot results, once for an appliance and once for hosts you manage. Multiply each annual estimate by the years in your comparison term, add each option's hardware and service quote for that term, then compare the totals. Cost line Your estimate for each option Select and maintain a compatible OS image for each board type Engineer hours per year times hourly rate Qualify each JetPack and driver upgrade against the inference runtime and against your cameras and Workflows Upgrades per year times hours each times hourly rate Apply security patches and track which devices have them Devices times updates per year times minutes per device, divided by 60, times hourly rate Recover a device that cannot take an update remotely, with a reflash, a site visit or a spare Events per year times recovery labor and travel per event, plus spares and shipping Track fixes a technician makes by hand at one site so the next site gets them Incidents per year times hours each times hourly rate Quoted hardware and service costs Your alternative quote next to the appliance quote, for the same scope and term Include software and support fees, commissioning, spares and downtime in both totals. If you already staff these jobs, an appliance is harder to justify. If you have to hire engineers or pay a contractor for them, put that cost in the total for hosts you manage. How to decide Keep your existing hosts you manage if you already install their OS images, apply patches and monitor them, or if you need a shell on every device or kernel-level control such as custom boot parameters or CPU isolation. Run Roboflow Inference (opens in a new tab) on them and manage them with Deployment Manager (opens in a new tab). If this is your first time remotely managing devices, review the chart for cost and decision-making guidance on whether to self-host or use RoboflowOS. Before you mount the first device, name who is responsible for each row of the layer table. When you request a quote, ask vendors to put these in writing: Itemize the hardware and services and name who maintains each component. State support terms separately from the one-year hardware warranty and the five years of RoboflowOS updates. Say whether the price includes mounts, cables, cameras and commissioning. Provide the qualification record for your board and operating system version. Name who authorizes operating system updates and which updates you can defer or pin. Explain how we verify each update installation and which recovery procedures we test on your board. Describe what the line operator sees when an update restarts host services or reboots the device. Write the steps a technician takes on site to replace a unit, with the spares supplier and delivery time. List which settings we restore to the replacement and which the technician enters again. Request a quote or talk to our team. To choose between your hosts and an appliance, ask us to review one line or site. Send us your Workflow, cameras and line rate, your network and connectivity constraints, and any host tools or agents you require. We return a written recommendation that names your hosts or a specific appliance, lists the upstream services the installation depends on, and identifies any requirement that calls for a host you manage.