OpenRemote

100% open source IoT device management, honestly reviewed. If you’re expecting a Home Assistant alternative, you’re in the wrong place — and that’s important to understand before you deploy.

---

TL;DR

• What it is: A 100% open source (AGPLv3) IoT platform for device management, automation, and dashboards — aimed squarely at OEMs, manufacturers, and system integrators rather than home users [4][5].
• Who it’s for: Companies building connected products (smart buildings, fleet management, energy systems) that need white-labeling, multi-tenancy, and auto-provisioning — without handing their device data to AWS IoT or Azure IoT Hub [4][website].
• Cost savings: The software is free. What you pay is infrastructure (a Docker host) plus optionally commercial support from OpenRemote Inc. Replacing Azure IoT Hub or AWS IoT Core can save hundreds per month at device scale — but pricing data for OpenRemote’s commercial tiers is not publicly listed.
• Key strength: Genuinely 100% open source, unlike ThingsBoard or Thinger.io which gate advanced features behind commercial tiers [5]. Multi-tenancy, rules engine, edge gateway, and white labeling are all in the open codebase.
• Key weakness: 1,670 GitHub stars vs ThingsBoard’s 17,000+ — smaller community, fewer integrations, and a steeper learning curve than hobbyist platforms. Android app setup has documented friction [3].

---

What is OpenRemote

OpenRemote is a Java-based IoT platform that lets you connect physical devices, define what they represent (assets), automate behavior across them, and expose data through dashboards and APIs. It’s deployed via Docker, stores everything in PostgreSQL, and exposes a REST API alongside an MQTT broker and WebSocket endpoints [README][4].

The project was founded in the Netherlands. Pierre Kil, listed as co-initiator on Hackaday, describes it as positioned for “manufacturers, OEMs, and system integrators” — not the hobbyist crowd [5]. That distinction shapes everything: the feature set, the documentation depth, and the learning curve.

OpenRemote’s architecture has four layers [4]:

• Frontend: Web admin UI (the Manager), web components for custom apps, native iOS and Android consoles
• Manager: The headless Java application that holds asset state, historical data, the rules engine, and messaging
• Agents: Connectors to third-party APIs and protocols — HTTP/REST, MQTT, WebSocket, and custom agents
• Security: Keycloak for identity and access management, HAProxy-based reverse proxy for TLS

The rules engine is unusually flexible: you can write automation using a drag-and-drop “when-then” flow editor, a visual flow builder, JavaScript, or Groovy scripts [README]. For a manufacturer who needs predictive maintenance logic, that depth matters. For a home user who wants “turn on the lights at sunset,” it’s overkill.

The platform runs in Docker on both amd64 and arm64 [README], which means it works on a standard VPS or a Raspberry Pi-class device in an edge deployment.

---

Why people choose it

The clearest case for OpenRemote comes from Pierre Kil’s own 2021 analysis of the open-source IoT landscape [5]. He makes an argument that’s still relevant: most “open source” IoT platforms are bait-and-switch — they open-source a stripped-down community edition while gating the features you actually need behind commercial licensing. His specific callouts:

• ThingsBoard has “recently introduced a horizontally scaling solution… pushing towards moving advanced features from opensource into a paying commercial model” [5]
• Thinger.io “is no longer completely open source” with its central server offered only as a commercial service [5]
• FIWARE isn’t a single product but a “larger series of projects” — powerful as a networked organization but complex to assemble [5]

OpenRemote’s counter-claim: the entire stack — multi-tenancy, white labeling, edge gateway, rules engine — is in the AGPLv3 codebase with no features held back [4][5]. The CNX Software review from 2021 confirms this framing: “while most cloud IoT platforms rely on open-source tools, the software hosted on the providers’ servers is usually closed-source… but OpenRemote is different with the full stack being released under an AGPLv3 open source license” [4].

The AGPLv3 detail matters for OEM use cases. If you’re embedding OpenRemote in a commercial product, you need to understand the copyleft implications — AGPLv3 requires you to release modifications, including server-side changes, back to the community. For pure internal use (running it for your own operations) this is a non-issue. For product companies shipping a modified version as a service, it requires legal review. OpenRemote Inc. presumably offers commercial licensing for exactly this scenario, though terms aren’t public.

The CNX Software article also notes that OpenRemote ran a public comparison against OpenBalena, FIWARE, Thinger, and ThingsBoard — positioning itself as the only solution combining full open-source with OEM-grade multi-tenancy and user-friendliness [4]. That comparison is from 2021 and the landscape has shifted, but the core argument holds.

---

Features

Device management and connectivity:

• Asset model: define custom asset types with attributes, metadata, and configuration [README]
• Auto-provisioning: devices register themselves on first power-up, digital twins are created automatically [website]
• Protocol agents: MQTT broker, HTTP/REST, WebSocket, plus custom agent framework [README][4]
• Edge gateway: run a lightweight node on-site that syncs to the central manager [README]
• Firmware OTA updates via the platform [website]

Automation:

• When-then rules: drag-and-drop, no code required [README]
• Flow rules: visual node graph for more complex logic [README]
• JavaScript and Groovy scripting for advanced rules [README][4]
• Geofencing triggers (enter/leave area fires a rule) [4]
• Alarm and notification generation from rule conditions [website]

Multi-tenancy and white labeling:

• Realms: fully isolated tenant environments within one deployment [README]
• Per-realm users, roles, and permissions [README]
• Custom deployment: style the Manager to your brand [README docs link]
• Distributor management: give distributors their own management realm [website]

Data and dashboards:

• Insights dashboard builder: drag-and-drop widget layout [README]
• Historical attribute data with configurable retention (OR_DATA_POINTS_MAX_AGE_DAYS) [README]
• Custom one-page apps for end users using web components [website]

Developer extensibility:

• External services API: embed standalone applications (FastAPI, Express, Spring Boot, React, etc.) into the Manager UI via iframe [1][2]
• Global services (available across all realms) and regular services (realm-scoped) [1][2]
• Full REST API, MQTT, WebSocket access from external applications [README][1]
• Docker packaging for custom services [1]

Integrations:

• Third-party integrations via the agent framework (ERP, CRM, identity services listed on the website)
• Open weather API tutorial in docs suggests community-contributed agents [README docs link]
• Compared to n8n or Activepieces, the pre-built connector catalog is not a strength here — OpenRemote’s protocol coverage is broad, but you’ll write custom agents for specific SaaS tools

---

Pricing: SaaS vs self-hosted math

This is where honesty requires a disclaimer: OpenRemote does not publish pricing for its commercial tiers. The website mentions “professional services” and “support,” and OpenRemote Inc. is a real company that sells support contracts and managed deployments — but the numbers aren’t listed.

What is clear:

Self-hosted (community, AGPLv3): Free. Run it on any Docker host. A VPS with 4GB RAM and 2 vCPUs is a reasonable starting point for a small deployment.

Comparison with commercial IoT clouds (approximate, varies by device count and data volume):

• AWS IoT Core: $0.08–$1.20 per million messages, plus device shadow storage costs — real numbers vary but hundreds per month at production scale is common
• Azure IoT Hub: starts ~$10/mo for basic tier (400,000 messages/day), scales to hundreds/month for Standard tier at volume
• Google Cloud IoT Core: was discontinued in 2023, which is itself an argument for self-hosted

OpenRemote commercial support: pricing data not available from any source reviewed. Contact sales.

The self-hosted math works if you have engineering capacity to manage the deployment. If you’re a 3-person hardware startup and your firmware engineer is also your DevOps, self-hosting OpenRemote at scale introduces real operational overhead that you’d otherwise be paying AWS to absorb.

---

Deployment reality check

The quickstart in the README is three commands: install Docker Desktop, download a docker-compose file, run docker compose up [README]. That gets you a working local instance at https://localhost with a self-signed certificate.

What you actually need for production:

• Linux VPS (4GB RAM minimum recommended for production; the default Docker Compose bundles the Manager, Keycloak, HAProxy, and PostgreSQL)
• Docker and docker-compose
• A domain name — the OR_HOSTNAME environment variable must be set for any non-localhost deployment [README]
• Valid TLS certificate (Let’s Encrypt via HAProxy or external reverse proxy)
• PostgreSQL data backup strategy — historical attribute data purges based on retention config [README]

What can go sideways:

The Android app setup has documented friction. A forum thread from December 2024 shows a user with a working web deployment who spent days unable to connect the official Android app [3]. The issue turned out to be URL format (the app expects the domain without /manager path), but the exchange spans multiple replies and required back-and-forth with a core team member to resolve [3]. The documentation “might not be clear enough on this” in the words of the OpenRemote team member who replied [3]. For a non-technical founder, this kind of friction is a real barrier.

The Keycloak dependency adds complexity compared to simpler platforms. Keycloak is powerful and handles SSO, OAuth2, and OIDC — but it’s another service to understand, configure, and keep running. If Keycloak has startup issues (common on low-RAM VMs), the entire platform is inaccessible.

Realistic time estimates:

• Developer with Docker experience: 1–2 hours to a working deployment with domain and TLS
• Non-technical founder with a guide: half a day minimum, more likely a full day including DNS propagation, TLS setup, and domain configuration for the Manager
• Getting the Android app working: add another hour of troubleshooting, based on [3]

The demo is available at https://demo.openremote.app/manager/?realm=smartcity with smartcity:smartcity credentials [README] — worth trying before committing to a deployment.

---

Pros and cons

Pros

• Genuinely 100% open source. AGPLv3, full stack, no feature gating [4][5]. Multi-tenancy, white labeling, and the rules engine are all in the community build — not held back for a commercial tier.
• Multi-tenancy built in. Realms are a first-class feature, not a bolt-on. Give each customer their own isolated environment from a single deployment [README][website].
• Protocol depth. MQTT broker, HTTP/REST, WebSocket, custom agents — more protocol coverage than most alternatives aimed at SMBs [README][4].
• Rules engine flexibility. When-then UI for non-technical users, Groovy/JavaScript for engineers — the same platform serves both [README][4].
• Edge gateway. On-premises nodes that sync to central — relevant for manufacturing environments with unreliable connectivity or data sovereignty requirements [README].
• OEM-grade white labeling. Full custom branding, custom asset types, custom apps via web components [README][website].
• ARM64 support. Works on Raspberry Pi class hardware for edge deployments [README].
• Active forum and versioned documentation. Version 1.22.0 is current (as of late 2024), docs are versioned, forum responses come from core team members [3][docs].

Cons

• 1,670 GitHub stars. That’s small for an infrastructure platform. ThingsBoard is at 17,000+. Smaller community means fewer community-contributed agents, fewer Stack Overflow answers, fewer tutorials [merged profile].
• Java/Keycloak stack is heavy. The default docker-compose bundles multiple services. On a 2GB VPS you’ll hit memory pressure. Keycloak alone eats 512MB+ at idle.
• Android app setup is painful. Documented in the forum: unclear documentation on URL format, domain configuration, and realm setup leads to hours of troubleshooting for new deployments [3].
• No public pricing for commercial tiers. If you’re evaluating total cost of ownership for a commercial product, you’ll need to contact sales to understand licensing for OEM redistribution.
• AGPLv3 requires legal review for OEM products. If you’re shipping a commercial product built on OpenRemote, copyleft implications apply to server-side modifications. Not a blocker, but a step that proprietary platforms skip.
• Not for hobbyists or home automation. The platform is complex relative to Home Assistant or Node-RED. No significant home automation community, no HACS equivalent, no consumer integrations with Philips Hue or Nest.
• Pre-built integration catalog is thin. The agent framework is extensible, but you’re writing connectors yourself for SaaS tools. There’s no equivalent to Activepieces’s 600+ pieces or n8n’s 400+ nodes.
• Limited independent reviews. The most substantive independent piece is from CNX Software in 2021 [4] — the platform has evolved but third-party coverage is sparse, which makes evaluating real-world production use difficult.

---

Who should use this / who shouldn’t

Use OpenRemote if:

• You’re building a connected hardware product and need device management, auto-provisioning, and multi-tenancy without a vendor lock-in risk.
• You’re a system integrator managing multiple client sites and need each client in an isolated tenant with their own users, rules, and dashboards.
• You need AGPLv3 licensing for internal deployments where you want full source access without commercial agreements.
• Your use case involves MQTT-connected devices, custom protocols, or OPC-UA/industrial connectivity via custom agents.
• You have engineering capacity to manage a Docker deployment and aren’t afraid of Keycloak configuration.

Skip it (use Home Assistant instead) if:

• You want to automate your home. Home Assistant has a vastly larger integration library, a mature community, and is purpose-built for this.

Skip it (use ThingsBoard instead) if:

• You need the largest open-source IoT community and don’t mind that advanced features have been progressively moved to commercial tiers. ThingsBoard’s community edition still covers basic device management and dashboards.

Skip it (use Node-RED instead) if:

• You need flow-based automation with hundreds of pre-built nodes and your primary need is connecting services and devices through a visual editor rather than running a full IoT management platform.

Skip it entirely if:

• You’re non-technical and have no DevOps support — the Android app forum thread alone [3] illustrates the kind of friction that will stall a solo non-technical founder.
• Your devices already live in AWS or Azure and the migration cost exceeds the hosting cost savings.

---

Alternatives worth considering

• ThingsBoard — the category leader by GitHub stars (17,000+). Similar architecture (Java, PostgreSQL), larger community, more visualization widgets. Has been progressively moving advanced features to commercial tiers, but the community edition is still functional for most use cases [5].
• Home Assistant — the right answer for home automation. Not a serious competitor for manufacturing/commercial IoT, but if you’re comparing for home use, it wins on ease and integrations by a wide margin.
• FIWARE — especially strong in Europe, backed by major organizations (Atos, Telefonica, NEC). More of a standards framework than a single product, which adds integration complexity [5].
• Thinger.io — simpler and more approachable, but the central server is commercial-only. Less suitable if open-source purity matters [5].
• Node-RED — flow-based, IBM-backed, huge community, deploys on a Pi. Not a full device management platform but excellent for protocol bridging and lightweight automation.
• Mainflux / SuperMQ — MQTT-first microservices IoT platform. More developer-oriented, smaller community than OpenRemote.

For a manufacturer evaluating OpenRemote, the real shortlist is OpenRemote vs ThingsBoard. OpenRemote wins on license purity (AGPLv3 all-in vs ThingsBoard’s creeping commercialization) and multi-tenancy as a first-class feature. ThingsBoard wins on community size, documentation depth, and ecosystem maturity.

---

Bottom line

OpenRemote is the honest answer to a specific question: what do I use if I need a 100% open-source IoT platform for a commercial product and I cannot afford vendor lock-in or bait-and-switch licensing? For that question, it’s one of the few genuine answers. The full stack — multi-tenancy, white labeling, edge gateway, MQTT, rules engine — is in the AGPLv3 codebase with nothing held back. The trade-off is a smaller community, a heavier stack, and documentation that still has rough edges [3].

For non-technical founders looking to escape SaaS IoT bills, it’s probably not the right tool. The setup complexity, Keycloak dependency, and Android app friction will eat the time savings. But for an engineering team at a hardware company asking “how do we build device management without building it from scratch and without signing a vendor agreement” — OpenRemote deserves serious evaluation.

If you want to try it before committing, the demo is live at https://demo.openremote.app/manager/?realm=smartcity with credentials smartcity:smartcity [README]. That’s a better use of thirty minutes than reading five more reviews.

---

Sources

1. External Services | OpenRemote Documentation (Next) — docs.openremote.io. https://docs.openremote.io/docs/next/developer-guide/external-services/
2. External Services | OpenRemote Documentation (v1.9.0) — docs.openremote.io. https://docs.openremote.io/docs/1.9.0/developer-guide/external-services/
3. Manager access via android app not working on basic local installation — forum.openremote.io. https://forum.openremote.io/t/manager-access-via-android-app-not-working-on-basic-local-instalation/3528
4. OpenRemote fully open-source IoT platform targets OEMs and DIY projects — cnx-software.com (Sep 3, 2021). https://www.cnx-software.com/2021/09/03/openremote-fully-open-source-iot-platform-targets-oems-and-diy-projects/
5. Pierre Kil — When is free really free? Make sense of Open Source IoT platforms, avoid pitfalls — hackaday.io (Jun 14, 2021). https://hackaday.io/pierrekil

Primary sources:

• GitHub repository: https://github.com/openremote/openremote (1,670 stars, AGPLv3)
• Official website: https://openremote.io
• Online demo: https://demo.openremote.app/manager/?realm=smartcity
• Documentation: https://docs.openremote.io