Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
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:
- 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:
- 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 mana...
67 comments
[ 2.5 ms ] story [ 131 ms ] threadCould 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?
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.
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.
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 do agree that the openBalena install docs are not great. To me they sound like a bunch of separate hacks all stuck together.
Check out our deploying docs here: https://deviceplane.com/docs/deploying/
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?
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!
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.
Glad to hear you're enjoying using Deviceplane!
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?
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.
I can't wait to get the time to sit down and play with it!
Let us know if there's any feature you were planning to build for your upcoming project that Deviceplane doesn't currently have.
Are there any plans in the future to support more linux distributions?
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!
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!
* http://jdebp.uk./Softwares/nosh/worked-example.html
* http://jdebp.uk./FGA/run-scripts-and-service-units-side-by-s...
* https://manpages.debian.org/unstable/sysvinit-utils/init-d-s...
* https://sources.debian.org/src/opendnssec/1:2.0.4-3/debian/o...
We'll dig into this fix, but until then you email us at founders@deviceplane.com.
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.
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.
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!
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.
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.
We're also interested in hearing your thoughts on pricing, shoot us founders@deviceplane.com, and let's talk about it!
Sent you an email!
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!
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!
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.
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/
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.
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.
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).
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.