Hey Hacker News! We're Josh, Sean, and Cyrus from Deviceplane (https://deviceplane.com/).
Deviceplane is an open source device management tool for embedded systems, IoT, and edge computing. More specifically, we manage any device running Linux. These can be found in many different categories of hardware such as single-board computers (Raspberry Pis, Jetson Nanos), IoT devices/gateways, and servers running at the edge.
The use cases for Linux devices span many different verticals/industries: robotics, consumer appliances, drones, autonomous vehicles, medical devices, and much more. Your first thought might be that a tool for managing robots and a tool for managing medical devices are quite different, but after talking to a variety of companies, we've found that the pain points across these industries are actually quite similar!
Deviceplane solves the biggest infrastructure problems for these use cases:
Deviceplane is designed to support a variety of hardware, from small embedded devices to large x86 servers. Today’s tooling ecosystem suffers from being segmented by hardware size.
- Orchestrating and deployment of remote updates - Network connectivity and SSH access - Host and application monitoring - Device organization: naming, labeling, searching, and filtering of devices - Access and security controls
For smaller devices, the Yocto project is popular. While it's good for building custom Linux installations, it has downsides for delivering applications. It's hard to understand, can take hours to compile, and solves only a portion of the problems present in device management.
For larger devices, many companies seem to build and maintain their own internal tooling. We've seen everything from systems built around configuration management to scripts polling for new Debian packages in S3. These systems are usually brittle, fall short of a complete feature set, and drain precious engineering resources with their maintenance.
We think Deviceplane is a great replacement for all of these. Not only is it suitable for all of these hardware sizes, it also presents a way to standardize the tooling across them.
One of our goals with Deviceplane is to make device management more accessible to developers. To do this, we build on technologies and concepts popularized in cloud deployments:
Deviceplane integrates with your device by running a lightweight static binary via your system supervisor. We can be used with nearly any Linux distro, which means you can continue using Ubuntu, Raspbian, a Yocto build, or whatever else fits your needs.
- Applications are packaged as containers and defined in a format resembling Docker Compose - Updates can be rolled out and tested gradually by using "canary" deployments - An intuitive and scriptable CLI that will feel familiar to Docker and Kubernetes users
Deviceplane is completely open source. The code for everything from the agent to the backend and UI can be found on GitHub (https://github.com/deviceplane/deviceplane). We put a lot of effort into making our open source version as easy as possible to run. You can even run the backend of Deviceplane with a single Docker command:
docker run -d --restart=unless-stopped -p 8080:8080 deviceplane/deviceplane
For more information on hosting Deviceplane yourself, check out our docs (https://deviceplane.com/docs/self-hosted/).
If you'd rather jump right into managing devices, we have a hosted version available at https://cloud.deviceplane.com/.
Lastly, we'd love to hear more about your experiences managing devices! What have your biggest pain points been, and what infrastructure do you wish existed to solve those? Either comment here, or shoot us an email anytime at firstname.lastname@example.org.
Congrats on the launch! This is perfectly timed since I’m currently evaluating device management solutions for Hiome’s IoT device fleet (https://hiome.com)
Currently, we use Mender (mender.io) but are considering switching.
Pros for Mender:
* great pricing for consumer products at around $0.50/device/mo
* lets us keep using Raspbian on our Raspberry Pi fleet
The cons however are that we are stuck with Raspberry Pi 3B+. We want to switch a more production-friendly board (either the compute module or something else entirely), but that means switching to yocto, which as you mentioned, is its own world of problems. Mender’s UI is also very buggy.
BalenaOS is acceptable and does support the boards we’re currently considering, but we’re limited to the devices they choose to support in the future.
I love that Deviceplane claims to work with any linux distribution. However, as far as I can tell, you only support application updates, not OS-level updates. Will it ever be possible to update the OS in your model? A major reason I want to use a device management system is to make sure we can fix potential OS-level security issues.
Another concern is pricing. $5/device/mo is probably fine for enterprise, but that can be 100% of revenue for many consumer devices. Since you’re open source, we could always self-host, but I’m curious if you have any plans to for more B2C-friendly pricing.
> However, as far as I can tell, you only support application updates, not OS-level updates.
For now this is true. People using Deviceplane today upgrade their underlying OS via the mechanism provided by their distro. On Debian-based systems this means running something like `apt-get dist-upgrade`. Deviceplane provides the tools to rollout this upgrade across your devices, but we're not hands-on past that.
We do have plans to support OS-level updates, but for now we're specializing in just updating applications and letting the underlying distro handle updating itself.
> Another concern is pricing. $5/device/mo is probably fine for enterprise, but that can be 100% of revenue for many consumer devices. Since you’re open source, we could always self-host, but I’m curious if you have any plans to for more B2C-friendly pricing.
Our pricing isn't actually $5/device/mo! This would be quite expensive. Our team plans starts at $250 per month, but pricing doesn't scale linearly past that. We're still exploring different pricing schemes for Deviceplane, but we do know that having the same per-device rate for B2B and B2C will likely not work.
To add on to what Josh said, re: OS updates, we have functionality for bulk scripting (https://deviceplane.com/docs/operating/command-scripting/) to help you roll out host-level updates to your devices.
We're also interested in hearing your thoughts on pricing, shoot us email@example.com, and let's talk about it!
Thanks Josh and Cyrus! The bulk scripting looks super handy and definitely addresses half my concern with OS updates. The other half is being able to roll-back if something goes wrong during the update.
Sent you an email!
Hello Neil, Thank you for using Mender! Since I’m directly involved with the development of the GUI I’m sorry to hear that you found an issue with it. However I'm all ears and would like to get this fixed asap, so please let me know using hub.mender.io, the firstname.lastname@example.org address you already know or find my address in my profile.
Hi Manuel, thanks for the comment. I reached out a few times to support and never heard back. It does look like most of my issues were quietly resolved later, but we ended up abandoning the dashboard and using the API directly for a lot of tasks. If I'm being honest, I don't have a lot of confidence in Mender's reliability due to those experiences. However, it's mender-convert's limited device list that is really driving the search for an alternative.
Hi, I am also working with the Mender project and we have been in touch earlier.
The device support for mender-convert will be drastically widened (actually, there will not be any limit as such) in the Mender 2.3 release, beta ETA in a week or two and final in March. But you can already test it with the development branch today: https://docs.mender.io/development/devices/debian-family
There will also be stock converted images for the most common development boards.
Let us know what you think!
Hiome looks cool, but that's quite the expensive occupancy sensor!
Thanks, our beta customers love them so far! Regarding price, each occupancy sensor is $79. These are high accuracy thermal sensors with local machine learning that can count occupancy. For comparison, a standard PIR motion sensor that can only tell you if there was motion in the last 30 seconds costs around $50 from Philips Hue or Eve. We think the price is very fair! :)
I guess I would never buy a PIR sensor for $50. You can get them for $6, so that's what I anchor off of. Not that I'd expect your product to be close to $6, but $50 PIR sensors are way overpriced, so I wouldn't ever think to compare to those.
Despite heavily automating my own home and being the person who sets everything up for my extended family, it seems I'm probably not your target market. Sounds like you have some cool tech though!
We've been running DevicePlane in prod for a few months now (after switching over from remote.it) Originally it was just device plane being having a much faster SSH and for convenience, but the new features they've begun to add started streamlining a lot of our dev work and actually helped us with more best practices. We've now containerized our applications and can schedule releases, stream metrics and crash data to datadog, all of which makes us feel more confident in our IoT.
The only feature I miss is being able to execute bulk scripts across devices, and would love to have an internal dashboard rather than using datadog since the cost of data collection is beginning to scale out of hand.
Hey Kai, I remember you mentioning that bulk scripting the first time we talked. I actually wrote up the docs on how to do that just recently (the last section is probably what you're looking for): https://deviceplane.com/docs/operating/command-scripting/
Glad to hear you're enjoying using Deviceplane!
I don't know a ton about the embedded/IOT world, but it's an area that has been coming up more on my radar recently. This project seems like a super interesting solution to the problems of deployment, updates, and monitoring.
Could you talk a bit more about the focus on linux? How much of the ecosystem is running a full OS vs a small embedded program?
To some extent, it's a matter of ease.
For embedded systems, you'd have to include the command and control elements in, which then gets into concerns about the amount of memory (both RAM and flash consumed).
For example, the ESP* devices historically have had challenges because you don't have enough flash storage to hold a proper SSL anchor chain. Suffice it to say there is a LOT of nuance when working in the embedded world which vanishes if you (even if just for the purposes of minimal viable product) focus on a full OS.
The short answer, agreeing with @crtlaltdel, is that Linux is getting really popular for embedded/IoT use cases. A lot of "embedded" devices are starting to look more and more like real servers. The latest model of Raspberry Pis go up to 4gb of RAM!
Linux has been standard in the cloud for a long time and as a result the tooling is pretty mature now. Projects like Kubernetes are great for managing servers in the cloud and have become quite standard. We noticed the same level of tooling for running Linux on devices just wasn't there yet, and so we decided to try and fix that!
That being said, there are certainly use cases where Linux isn't the best choice. If you have realtime requirements or you need low power usage then using an RTOS is a better option.
linux has become quite common in iot, which has really expanded what a lot of people consider an “embedded system”. we built a platform on a custom BSP for OpenWRT for industrial applications where an rtos or plc wasn’t needed.
This sounds really neat, and exciting that it has a self-hosting option as well! Raspberry Pis seem to generally be pets instead of cattle, and combined with the ease at which they seem to torch their file systems, a good management solution for them sounds really appealing.
Do you foresee a business model applying to self-hosters? If your business is going to focus on the service, do you have a plan to avoid AWS/Azure/GCP eating your lunch running your self-hosted code?
> Raspberry Pis seem to generally be pets instead of cattle
This is a great comment, and maybe a point we should have directly made in the launch post. Devices are certainly more like pets. If you push an update that breaks a device, you'll have an angry customer calling you rather than just being able to spin up a new EC2 instance!
We certainly predict self-hosting being a core part of our business model. This isn't as a response to AWS/Azure/GCP though.
We get this question a lot, but we don't actually fear AWS/Azure/GCP much. Plenty of SaaS companies have products similar to something offered by major clouds (Datadog, Cloudflare, etc...). We think the big clouds are good at their core competencies (EC2, RDS, etc...) but struggle to address the right problems with a great UX in their fringe products.
AWS/Azure/GCP just don't come up much in our customer conversations. We think our real competitor is internal tooling!
I assumed the pets/cattle comment was a reference to https://github.com/cattlepi/cattlepi
That's great! I was thinking of writing something like this for a few months as Balena seems really over complicated. Glad to see Go :) will definitely try it out for my projects!
Thanks! Looking forward to hearing your feedback.
Let us know if there's any feature you were planning to build for your upcoming project that Deviceplane doesn't currently have.
What about Balena? How are you different or the same?
We're in the same space as Balena and tackling some of the same problems, but with a different approach. Here are some of the big ways we defer from Balena (though these points really just scratch the surface).
Balena ties you into their ecosystem a bit too much. They require you to use BalenaOS which means they only support a fixed number of devices. In contrast, Deviceplane can be used with any Linux distro, meaning that as long as your device runs some form of Linux than it can be used with Deviceplane.
What's more, we've found that in most cases people really need the choice of what underlying Linux distro to use. For example, if you're using Jetson Nano devices and don't use the distro provided by Nvidia then you'll be fighting quite an uphill battle. Their distro includes a custom version of Docker (nvidia-docker) that adds support for using CUDA inside of containers.
Deviceplane also doesn't tie you to any specific container builder. We make it easy to integrate with popular CI systems so you can inherit all of their best features: build secrets, fully scriptable pipelines, etc...
Balena also lacks some of the core infrastructure that Deviceplane provides, such as our monitoring and bulk provisioning support.
Lastly, we're 100% open source and easy to host unlike Open Balena. Open Balena doesn't include user management or a UI. If you read through its installation guide you'll quickly get a sense that its architecture is needlessly complex and difficult to self-host. In contrast, Deviceplane was engineered to be self-hosted from day one and can be run in a single Docker command.
I looked at Balena for my project but being tied so tightly to their eco-system and not being able to use it with regular Raspbian really put me off. However, one feature that looked useful was the ability to have one service per container and have them tied all together with docker compose. Do you support that architecture or does Deviceplace manage a single docker container which must contain all the services bundled together?
I do agree that the openBalena install docs are not great. To me they sound like a bunch of separate hacks all stuck together.
We support multiple services, and we even support deploying multiple Docker Compose files per project!
Check out our deploying docs here: https://deviceplane.com/docs/deploying/
Great description! I evaluated balena for one of my Nvidia Jetson demos and I wanted it to work so bad, but it didn't support the jetson xavier.
This is great timing for us too. At http://whoo.ai we make mobile video intercoms for apartment buildings. We install an Android device at the entrance to the building that lets visitors initiate a video call with the resident. We need a tool to manage those android devices (update and restart our app remotely... bonus if we can also restart the device). The devices are running as kiosks and need to be updated without any local interaction. We evaluated IBM’s Maas360 but it couldn’t do it without local interaction and IBM wanted a fortune to add the feature! I just signed up for a demo... looking forward to speaking with you. Arturo
"For smaller devices, the Yocto project is popular. While it's good for building custom Linux installations, it has downsides for delivering applications. It's hard to understand, can take hours to compile, and solves only a portion of the problems present in device management."
This hits home. I work at a company that builds sensor systems. We started using Yocto before my time in the company but we lived the above sentence for the last couple years before migrating to Ubuntu. We also happen to be scoping out a configuration management tool for this year. I will definitely be checking out Deviceplane in the coming days.
Can you elaborate on this? How do you make use of Ubuntu in this way and why was it hard to use Yocto? For the usual embedded Linux workflows I'm used to, it seems like building on top of Ubuntu would necessitate re-implementing Yocto features.
My biggest pain point with Balena in my previous job was that it used Docker; it's unfortunate that most of the solutions in this space (including Deviceplane) seem to do so. It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update.
I'd be really interested in seeing a system based around Git and something like buildpacks instead. IoT definitely feels like the right space for pushing small diffs for deployments.
I'm involved with Mender which focuses on OTA updates and does not limit the type of update you can deploy, some popular choices: * full system image (with robust a/b layout for rollback support, can also do delta updates to reduce bandwidth with 70-90%) * docker containers * single files or directories * deb packages
You can see the ones OOTB here: https://hub.mender.io/c/update-modules
Also, you can write your own update type if you have a more custom use case: https://docs.mender.io/2.2/devices/update-modules
Does that make sense? Git and buildpack support is not yet OOTB but should be fairly simple to add with a new update module. Note however, that those type of updates may not be easy to roll back (or make atomic - meaning you can get partially installed updates and bricked devices/applications if you lose power).
Docker images are designed for minimal artifact transport while avoiding the need for assembly from source at the edge. If anyone is pushing around 1GB images for iterative deployments they might be able to do better with a few tweaks to their image structure and delivery pipeline.
> It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update.
That seems like a really big image? Alpine-based images in my experience tend to be under 100MB.
But I would be fascinated to use p2p for distributing image layers; it feels like that shouldn't be too hard?
EDIT: it's been done, apparently:) https://blog.bonner.is/docker-registry-for-ipfs/
IPFS and decentralization don't really address artifact size issues.
It certainly improves the practical outcome; replicating layers between nodes in a rack/datacenter is way faster than pulling it down 20x from one external upstream.
Sure, but latency is not the same as size. You're talking about latency optimization via local caching. IPFS is a bit of a heavy solution compared to a simple cache. IPFS solves a totally different problem.
We see Alpine used in production less than most people think. People usually feel more comfortable writing a Dockerfile based on Debian or Ubuntu because those are what they're familiar with. In most cases it's worth the one-time cost of pulling the bigger base image, but it all depends on the use case.
Another common reason for large images is the Nvidia ecosystem. Most of the images that Nvidia publish can get close to 1GB. However, these should only need to be pulled to devices once until you need to upgrade the base image.
Can you talk more about what kind of use case you had where the average update took 1GB?
I can certainly see how pulling a base image could require that kind of download size, but subsequent updates should only need to pull the layers that have changed.
There are two existing update frameworks that work on this model, one based on ostree and another from Intel called swupd.
Congrats on launching, and thank you for open sourcing! I've added your codebase to my list of open source React/Go applications to check out.
1. Do you worry that open sourcing will make it difficult for you to monetize?
2. Can you describe your tech stack more?
3. How long has your team been working on this?
1. We don't! We suspect that many companies running devices in production would rather pay for a hosted version of Deviceplane than have to maintain their own self-hosted install. We also offer support subscriptions of self-hosted installs.
2. If I had to summarize in one word, Golang. Our backend, agent, and CLI are all written in Go.
Frontend is React + a custom component library we maintain.
On the infrastructure side it's quite simple: RDS, containers running on ECS, and an ALB load balancer. We built Deviceplane to be simple to host and since we just run the open source version it means our own infrastructure is simple.
3. We've been working on this since around August!
I ran the `docker run ...` command you copy/pasted above and got the UI running quickly.
But, I couldn't install the agent on my Mac; perhaps macOS is not supported. This may be intentional, after all you're not building a desktop MDM tool, but I'd suggest providing a command to run an agent inside a Docker container (or something else).
This way people like me can start experimenting with DevicePlane without spinning up a Linux VM or EC2 instance.
This looks really cool. Kudos for going fully open source and congrats on launching!
Somewhat interesting and will keep an eye on it, but the "current ecosystem" paragraph seems to both miss some options and confuse some things. E.g. yocto isn't an update solution, but is presented as contrast to some options for bigger systems, and no of the more advanced competitors for updates, both software and services, aren't mentioned at all - but those are what you need to convince me you're better as. (And yes, the space certainly can use some more options trying new things!)
True, Yocto is not technically an update solution! We explained it as such to try and keep our post a little shorter, but perhaps we oversimplified a bit too much there. What we probably meant to say is "the Yocto ecosystem".
We mention Yocto and internal tooling rather than other competitors because they're what we hear most often. We would have loved to include more discussion about why were better than other solutions, but it would have made our post a little unwieldy.
I have a comparison between us and Balena here: https://news.ycombinator.com/item?id=22173350.
What other tools did you have in mind? It'd be great to discuss this more!
It'd be great to hear a comparison of when you'd want to use Deviceplane vs something like mender.io or updatehub.io. I'm a great fan of the A/B dual image update strategy because it's simple, atomic and resilient to errors or loss of power during an update. Does Deviceplane still provide some of those assurances or would I want to use Deviceplane in conjunction with something like Mender?
I deploy updates on IoT devices that are unattended and can only afford minimal downtime. If an interrupted update (due to loss of network connectivity or power) caused a device to be unreachable/unupdateable it would be bad. I'd also be concerned with using DevicePlane as it's presented because I'd have no way of updating the device's kernel version that I first deploy with.
I tried to enroll a server into deviceplane but there is a hard requirement on systemd.
Are there any plans in the future to support more linux distributions?
Our agent will support nearly any Linux distro, even though our installation script only supports systemd at the moment.
We've really wanted to add OpenRC support to our installation script for a while but haven't gotten to it yet.
If you know your init system well, you could always write your own service file. Here's the unit file for systemd as a reference: https://github.com/deviceplane/deviceplane/blob/master/insta....
Let me know if you end up getting this to work. Would love to upstream to our install script!
A OpenRC script should be fairly simple, as should a script for the modern van Smoorenburg rc in Debian. They are both largely just scripts of variable=value assignments.
> nearly any Linux distro
The service file for systemd looks pretty simple, so that's probably not a problem to port to some other init system.
But what's in the "nearly" above, do you have some other concrete requirements for the distro? Any technical reason very small busybox-based systems would be unable to support your agent?
Deviceplane sounds like a very good idea for a niche that really needs something like it!
Delegate=yes is ignored because I did not run this on a Linux operating system.
% printf '1,$s/^KillMode/#&/\nw\n' | ex ./deviceplane.service % % /package/admin/nosh/command/system-control convert-systemd-units --no-systemd-quirks ./deviceplane.service convert-systemd-units: WARNING: ./deviceplane.service: Unused setting: [service] delegate = yes convert-systemd-units: WARNING: ./deviceplane.service: Unused setting: [service] tasksmax = infinity convert-systemd-units: WARNING: ./deviceplane.service: Unused setting: [service] timeoutstartsec = 0 convert-systemd-units: WARNING: ./deviceplane.service: Unused setting: [unit] documentation = https://deviceplane.com/docs/ % % /package/admin/nosh/command/system-control print-service-scripts ./deviceplane start:#!/bin/nosh start:#Start file generated from ./deviceplane.service start:true stop:#!/bin/nosh stop:#Stop file generated from ./deviceplane.service stop:true run:#!/bin/nosh run:#Run file generated from ./deviceplane.service run:#Deviceplane agent run:hardlimit -o infinity -c infinity -p infinity run:softlimit -o hard -c hard -p hard run:/usr/local/bin/deviceplane-agent --controller=https://example.com:443/api --project=example --registration-token=example restart:#!/bin/sh restart:#Restart file generated from ./deviceplane.service restart:sleep 5s restart:exec true # ignore script arguments %
Congratulation on the launch!
I would like to know if I can get yours and the communities comment on something.
I have interest in the ecosystem of open-source OTA and device management solutions and I try to keep up to date with things. When I saw your post on HN, I visited your github page (https://github.com/deviceplane/deviceplane) to learn more.
I was a bit surprised by the numbers on the github landing page which showed 800+ stars and 60+ forks. I typically look at these numbers to get a indication of project activity/popularity, obviously not the only metric to look at but normally a pretty good first data point.
This got me interested to learn more, as my initial though was that this project must have been around for a while with an active community. But things did not add up, the project only had 3 contributors (probably people from the company behind the project).
Looking closer at the forks (https://github.com/deviceplane/deviceplane/network/members), majority of them reference a different repository name (npm-algos) which does not seem to at all related to deviceplane. Then it became apparent to me that this must have been a rename of an organization and repository, as https://github.com/npm-algos/npm-algos redirects to https://github.com/deviceplane/deviceplane.
Now I became even more suspicions on what is going on here. So I did a bit more digging using the github API and looking up when the repository got their stars which showed that majority of the 800+ stars came before 2019-01 which was the "initial commit" of the deviceplane repository and the stars where dating back to 2015, so they must have been for the "npm-algos" repository.
Then to the conclusion, it seems that an older unrelated repository was repurposed (renamed) to manipulate metrics on github to provide a misleading view of activity/popularity. I find it hard to believe that something like this happened "accidentally", git repositories are fairly cheap :) and renaming an organization/repository on github is a somewhat involved process.
This is a practice I have never seen before, and not sure I like it. The goal seems to be to mislead users.
Would love to hear thoughts from the deviceplane folks, but also from the HN community.
Strange. Deviceplane now only has 56 stars.
Hey I was trying to reach out to email@example.com and keep getting: 550 5.1.1 Requested action not taken: mailbox unavailable Is there a better way to reach out?
Sorry about that! Must have gotten lost in the .io -> .com transition.
We'll dig into this fix, but until then you email us at firstname.lastname@example.org.
No worries, sent to that address. Some public questions though.
We are looking at launching a product on the nvidia jetson and you mentioned that running a third party OS is an uphill battle? Can you go into the pros and cons of BalenaOS vs the default for many of these single board computers?
One of the big issues we have had is that on BalenaOS you are forced to use NetworkManger which caused us weeks of work to code around it's many short comings.
Could you compare your product to AWS GreenGrass ? If I use GreenGrass, should I use Deviceplane too ?
Congrats on the launch!
I've worked with both Josh and Cyrus at DevicePlane and can say I'm really looking forward to what these folks deliver. Really great engineering talent all around working on a solution to a non-obvious but hard problem that exists.
I can't wait to get the time to sit down and play with it!
I'd echo this. I've worked with Cyrus previously and he's one of the most effective engineers I've ever partnered with. Great team behind this!
Thanks, Evan, Max, you guys rock! Sometimes I forget how many people I know that read HN.
Congrats on the launch, y’all. I’ve worked closely with Cyrus in the past and just met the team a few months ago. I’m very much looking forward to where this is going.
Thanks Izu, I hope we can share some great updates in the next few months!