balena is a great way to build and ship containerized apps to devices running balenaOS. But not every fleet can adopt a container OS. ThinRemote is a drop-in agent that runs on the OS and hardware you already have and gives you secure access, observability and automation without reflashing a single device.
ThinRemote addsThis isn't a feature war. balena and ThinRemote solve different problems, and the real question is whether you're shipping a containerized app to hardware you control, or operating a mixed fleet of machines that already run their own software.
A container-first fleet platform. You run balenaOS on the device, package your application as Docker containers, and push releases that the Supervisor pulls and runs on balenaEngine. Excellent for reproducible builds and robust over-the-air updates, but it's opinionated: the device adopts a container OS and your app has to be containerized.
A remote-management layer. One outbound agent runs on the OS and hardware you already have and gives you live telemetry, alarms, shell, file transfer, remote desktop, service tunnels, fleet automation and an MCP server for AI agents, out of the box. You operate the machines you run, whatever they run, with nothing to reflash.
balena is built around balenaOS, a Yocto-based embedded Linux purpose-made for running containers. It's a solid base, but it's a base you have to adopt: you reflash the device to balenaOS and re-architect the workload into containers. Great on greenfield hardware you control; a hard sell on a machine that already ships its own OS and application.
ThinRemote is a tiny agent, under 10 MB, that installs on the distribution the device already runs and changes nothing else about it. It's a single static binary that makes one outbound connection and runs on almost anything, from a modern server to a years-old industrial box (kernel 2.6 and up, 16 architectures), alongside whatever workload is already there. Nothing to reflash, nothing to containerize.
balena's core loop is application delivery. You describe a container app, build a release, and the Supervisor rolls it out across the fleet with an update strategy and rollback. If your problem is "ship this app image to every device reproducibly", that's genuinely what balena is best at, and we won't pretend otherwise.
ThinRemote isn't a container-delivery pipeline, and it doesn't try to be. Its loop is operations: reach a device, see how it's doing, run a command, pull a file, open a service, and roll a change across the fleet. Its automation works at the OS and device-API level with playbooks, so it can drive the machines balena isn't managing, or sit alongside balena on the ones it is.
balenaCloud surfaces a helpful set of high-level device metrics, CPU, memory, storage, CPU temperature and undervoltage or throttling warnings, on the dashboard and over its API. For deeper monitoring or alerting, the usual path is to forward metrics to an external stack such as Datadog and build the thresholds there.
Every ThinRemote agent reports a structured monitoring resource, CPU and load, memory and swap, per-filesystem usage, network throughput, temperature and uptime, on per-device and per-fleet dashboards, and wired straight into threshold alarms with email and webhook notifications. And you define the criteria: expose any value from a small script on the device, the cash level in a vending machine, a PLC fault code, kWh delivered, and it becomes a first-class metric you can chart, roll up and alarm on like any built-in one.
balena's remote access, via Cloudlink, covers SSH into the host OS or a container, a browser web terminal, and a per-device public URL that proxies HTTPS to port 80 on the device. It's useful for debugging and demos, and balena's own docs note the remote terminal isn't meant to sit in the critical path or hold long-lived connections.
ThinRemote gives you a full operations console over the same outbound agent: an in-browser terminal, a file explorer, remote desktop, live dashboards and alarms, plus HTTP, TCP and TLS tunnels to any local service, not just port 80. The same actions are scriptable from the CLI with JSON output and drivable by AI agents through the built-in MCP server, all under the same roles and tokens.
On balena, once a container is running, reaching into it to trigger something specific is usually your code's job: you expose an endpoint or a service inside the container and wire it up yourself. That's the container model working as intended.
With ThinRemote, any script on the device becomes a named resource, a typed operation you call by name that returns JSON. Run diagnostics, open a cash drawer, read a meter, restart a service, with no SSH session and no bespoke glue. Define it once and it's callable across the whole fleet, from a CI/CD step, a cron job, a webhook, an incident runbook, or an AI agent over MCP. Your automation acts on real devices instead of shelling into them one by one.
Here the two are closer than most comparisons: like ThinRemote, balena devices connect outbound only over TLS through Cloudlink, and device-to-device traffic is disallowed. That's a good model, and we're glad to see it. So this isn't about one being open and one being closed.
The ThinRemote agent makes a single outbound connection over TLS 1.3. It opens no inbound port and exposes no listening service, so there's nothing on the device to attack and no path from one box to the next. Access is brokered through the cloud with role-based access control, scoped tokens and an audit trail, and it applies to the OS you already run rather than requiring a specific device OS. Thinger.io, the company behind ThinRemote, is ISO 27001 certified.
balena exposes a full API and CLI, so you can certainly build your own AI tooling on top of it. There's no built-in MCP server, though, so an assistant can't operate the fleet until you've wired those integrations yourself.
ThinRemote ships an MCP server built into the CLI. Point Claude, Cursor or any MCP client at it and it can list devices, read live metrics, run commands, tail logs, open tunnels and roll out playbooks, all in plain language and all under the same roles and tokens as your team. Ask "which gateways are low on disk?" or "roll the patch to store 14 first", and it acts on the real fleet.
Side by side, on the dimensions an OT, IoT or edge team weighs when choosing what to run on a fleet.
product execA fair reading: balena is deliberately opinionated because that's what makes container delivery reliable. ThinRemote trades that opinion for reach, running on the OS you already have and focusing on operating the fleet rather than shipping its application.
Different jobs, remember. If your problem is delivering a containerized application to a fleet, reach for balena.
You want a reproducible container image built once and shipped to every device, with the runtime, dependencies and services versioned as a release. That's balena's home turf.
Atomic over-the-air updates of the whole app, update strategies and rollback across the fleet are first-class in balena, and hard to beat if that's your core need.
When you own the device from day one and can standardize on balenaOS and containers, adopting the platform end to end pays off.
Plenty of teams run both: balena to build and ship the containerized app, ThinRemote to access, observe and automate the wider fleet, including devices that will never run balenaOS.
Pick by the question you're actually trying to answer.
"I need to access, observe and operate a fleet I already run."
"I need to build and ship a containerized app to my devices."
The questions OT, IoT and edge teams ask when weighing ThinRemote against balena.
For shipping a containerized application to devices you control, yes, that's exactly what balena is built for: reproducible container releases, over-the-air updates and rollback. ThinRemote isn't a container-delivery pipeline. It focuses on operating the fleet, secure access, observability, alarms and automation, on the OS you already run. Many teams use balena to deliver the app and ThinRemote to operate the fleet around it.
No. ThinRemote is an OS-agnostic agent, a single static binary under 10 MB, that installs on the Linux distribution the device already runs, from Ubuntu and Debian to Raspberry Pi OS, OpenWRT or a custom Yocto build. There's no image to reflash and no need to containerize your application. It supports 16 CPU architectures and kernels from 2.6 upward.
Yes. They sit at different layers, so they don't conflict. balena can keep delivering and updating your containerized app, while ThinRemote's agent gives you the access, observability and automation layer across the fleet, including the many devices that will never run balenaOS. A common pattern is balena for the greenfield container fleet and ThinRemote as the single operations layer over everything.
Both are outbound-only: balena devices connect out over TLS through Cloudlink and disallow device-to-device traffic, and ThinRemote's agent dials out over TLS 1.3 with no inbound port and no listening service. ThinRemote brokers access through the cloud with role-based access control, scoped tokens and an audit trail. Thinger.io, the company behind ThinRemote, is ISO 27001 certified.
balenaCloud surfaces high-level device metrics, CPU, memory, storage, CPU temperature and throttling or undervoltage warnings, on the dashboard and over its API, and teams often forward those to a stack like Datadog for deeper monitoring and alerting. ThinRemote ships richer per-device telemetry, lets you define your own metrics from a device script, and has native threshold alarms with email and webhook notifications built in.
Both offer options. balena has an open-source foundation, openBalena, that you can run yourself, and balenaCloud as the managed SaaS. ThinRemote can run as a single-tenant private instance in the region of your choice or on-premise, and its agent and protocol are open source.
Install the agent on the OS you already have and get access, telemetry, alarms, device APIs and automation from one outbound connection, no reflash required.