{"slug": "why-roboflow-sells-hardware-and-when-to-use-your-own", "title": "Why Roboflow Sells Hardware, and When to Use Your Own", "summary": "Roboflow now sells its own edge computer vision hardware, the Roboflow Edge appliance, starting at $8,000 with five years of RoboflowOS over-the-air updates included, because host operating system maintenance cannot be handled remotely on customer-owned Jetson devices. Roboflow says its Deployment Manager software covers only part of the stack, leaving buyers to maintain OS images per board type, qualify each new JetPack and driver upgrade against the inference runtime and cameras, apply security patches, recover failed devices and record manual fixes. Roboflow built RoboflowOS, an immutable OS with over-the-air updates, to meet its own field deployment team's uptime and maintenance requirements.", "body_md": "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.\n\nRoboflow 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).\n\nDeployment 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.\n\nDeployment 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.\n\nA 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.\n\nEach case needs a fix in the host operating system, and these hosts have no remote way to install one.\n\nWe 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.\n\nThere 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.\n\nSome 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.\n\nAll 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.\n\nRoboflow built RoboflowOS to meet our own field deployment team’s demanding requirements for uptime and ease of maintenance.\n\nEnsuring hardware compatibility\n\nWithout 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.\n\nYou 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.\n\nJetPack 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.\n\nEach 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.\n\nStart with a hardened system image\n\nWe 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.\n\nOS-level camera and network compatibility\n\nWe 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.\n\nNetwork settings survive a restart\n\nRoboflowOS 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.\n\nYou 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.\n\nRoboflowOS secure updates\n\nThe 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.\n\nWe qualify major JetPack upgrades separately for each board, so an AGX64 can move to a new JetPack release before an NX16 does.\n\nRoboflow Provides Stable Layers; You Build On Top\n\nRoboflow 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.\n\nLayer\n\nOur appliance\n\nHosts you manage\n\nCamera view, lighting, mounting, acceptance testing\n\nYou\n\nYou\n\nWorkflows and models\n\nYou choose and validate them, and the platform delivers them\n\nYou choose, validate and deploy them, through Deployment Manager where you install it\n\nInference runtime containers\n\nWe publish them, and Deployment Manager applies the version you set\n\nThe same where you install Deployment Manager, and otherwise you apply them\n\nDevice agent\n\nWe publish it, and it follows its configured update policy\n\nWe maintain them through the RoboflowOS update path\n\nYou\n\nHardware\n\nWe supply it\n\nYou or your vendor\n\nPlant network, firewall, gateway host\n\nYou\n\nYou\n\nRunning on a plant OT network\n\nYour 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.\n\nSecure 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.\n\nDeployment 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.\n\nThe 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.\n\n1 x 5 GbE, 1 x 100 GbE QSFP28 that breaks out to 4 x 25 GbE\n\n$16,000\n\nThe 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.\n\nIf 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.\n\nPick 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.\n\nTo 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.\n\nWhat’s included\n\nThe 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.\n\nWhen 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.\n\nNVIDIA'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.\n\nThe hardware has a one-year warranty.\n\nTo 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.\n\nCost line\n\nYour estimate for each option\n\nSelect and maintain a compatible OS image for each board type\n\nEngineer hours per year times hourly rate\n\nQualify each JetPack and driver upgrade against the inference runtime and against your cameras and Workflows\n\nUpgrades per year times hours each times hourly rate\n\nApply security patches and track which devices have them\n\nDevices times updates per year times minutes per device, divided by 60, times hourly rate\n\nRecover a device that cannot take an update remotely, with a reflash, a site visit or a spare\n\nEvents per year times recovery labor and travel per event, plus spares and shipping\n\nTrack fixes a technician makes by hand at one site so the next site gets them\n\nIncidents per year times hours each times hourly rate\n\nQuoted hardware and service costs\n\nYour alternative quote next to the appliance quote, for the same scope and term\n\nInclude 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.\n\nHow to decide\n\nKeep 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.\n\nBefore 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:\n\nItemize 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.\n\nSay whether the price includes mounts, cables, cameras and commissioning.\n\nProvide the qualification record for your board and operating system version.\n\nName who authorizes operating system updates and which updates you can defer or pin.\n\nExplain 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.\n\nWrite 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.\n\nRequest 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.", "url": "https://wpnews.pro/news/why-roboflow-sells-hardware-and-when-to-use-your-own", "canonical_source": "https://roboflow.com/blog/roboflow-hardware-and-when-to-use-your-own", "published_at": "2026-11-13 23:44:48+00:00", "updated_at": "2026-11-13 23:50:10.325134+00:00", "lang": "en", "topics": ["computer-vision", "ai-infrastructure", "ai-products"], "entities": ["Roboflow", "RoboflowOS", "Deployment Manager", "JetPack", "Nvidia Jetson", "Allxon", "Canonical", "Ubuntu"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-roboflow-sells-hardware-and-when-to-use-your-own", "markdown": "https://wpnews.pro/news/why-roboflow-sells-hardware-and-when-to-use-your-own.md", "text": "https://wpnews.pro/news/why-roboflow-sells-hardware-and-when-to-use-your-own.txt", "jsonld": "https://wpnews.pro/news/why-roboflow-sells-hardware-and-when-to-use-your-own.jsonld"}}