
Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux - joshwget
Hey Hacker News! We&#x27;re Josh, Sean, and Cyrus from Deviceplane (<a href="https:&#x2F;&#x2F;deviceplane.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;deviceplane.com&#x2F;</a>).<p>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&#x2F;gateways, and servers running at the edge.<p>The use cases for Linux devices span many different verticals&#x2F;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&#x27;ve found that the pain points across these industries are actually quite similar!<p>Deviceplane solves the biggest infrastructure problems for these use cases:<p><pre><code>  - 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
</code></pre>
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.<p>For smaller devices, the Yocto project is popular. While it&#x27;s good for building custom Linux installations, it has downsides for delivering applications. It&#x27;s hard to understand, can take hours to compile, and solves only a portion of the problems present in device management.<p>For larger devices, many companies seem to build and maintain their own internal tooling. We&#x27;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.<p>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.<p>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:<p><pre><code>  - Applications are packaged as containers and defined in a format resembling Docker Compose
  - Updates can be rolled out and tested gradually by using &quot;canary&quot; deployments
  - An intuitive and scriptable CLI that will feel familiar to Docker and Kubernetes users
</code></pre>
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.<p>Deviceplane is completely open source. The code for everything from the agent to the backend and UI can be found on GitHub (<a href="https:&#x2F;&#x2F;github.com&#x2F;deviceplane&#x2F;deviceplane" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;deviceplane&#x2F;deviceplane</a>). 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:<p>docker run -d --restart=unless-stopped -p 8080:8080 deviceplane&#x2F;deviceplane<p>For more information on hosting Deviceplane yourself, check out our docs (<a href="https:&#x2F;&#x2F;deviceplane.com&#x2F;docs&#x2F;self-hosted&#x2F;" rel="nofollow">https:&#x2F;&#x2F;deviceplane.com&#x2F;docs&#x2F;self-hosted&#x2F;</a>).<p>If you&#x27;d rather jump right into managing devices, we have a hosted version available at <a href="https:&#x2F;&#x2F;cloud.deviceplane.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloud.deviceplane.com&#x2F;</a>.<p>Lastly, we&#x27;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 founders@deviceplane.com.
======
guptaneil
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](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.

~~~
joshwget
Thanks!

> 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.

~~~
cyrusroshan
To add on to what Josh said, re: OS updates, we have functionality for bulk
scripting ([https://deviceplane.com/docs/operating/command-
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
founders@deviceplane.com, and let's talk about it!

~~~
guptaneil
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!

------
kairuiz
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.

~~~
cyrusroshan
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/](https://deviceplane.com/docs/operating/command-scripting/)

Glad to hear you're enjoying using Deviceplane!

------
calvinfo
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?

~~~
thebeardisred
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.

------
ocdtrekkie
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?

~~~
joshwget
> 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!

~~~
kingosticks
I assumed the pets/cattle comment was a reference to
[https://github.com/cattlepi/cattlepi](https://github.com/cattlepi/cattlepi)

------
deforciant
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!

~~~
joshwget
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.

------
ivanstegic
What about Balena? How are you different or the same?

~~~
joshwget
Great question!

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.

~~~
kingosticks
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.

~~~
joshwget
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/](https://deviceplane.com/docs/deploying/)

------
afalck
This is great timing for us too. At [http://whoo.ai](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

------
pompouspurist
"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.

~~~
bibabaloo
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.

------
robotmay
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.

~~~
yjftsjthsd-h
> 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/](https://blog.bonner.is/docker-registry-for-ipfs/)

~~~
zerotolerance
IPFS and decentralization don't really address artifact size issues.

~~~
yjftsjthsd-h
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.

~~~
zerotolerance
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.

------
veeralpatel979
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?

~~~
joshwget
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!

~~~
veeralpatel979
Thanks!

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.

------
aryik
This looks really cool. Kudos for going fully open source and congrats on
launching!

------
detaro
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!)

~~~
joshwget
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](https://news.ycombinator.com/item?id=22173350).

What other tools did you have in mind? It'd be great to discuss this more!

~~~
bibabaloo
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.

------
mirzak
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](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](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](https://github.com/npm-algos/npm-
algos) redirects to
[https://github.com/deviceplane/deviceplane](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.

~~~
veeralpatel979
Strange. Deviceplane now only has 56 stars.

------
jackhalford
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?

~~~
joshwget
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...](https://github.com/deviceplane/deviceplane/blob/master/install.sh#L178).

Let me know if you end up getting this to work. Would love to upstream to our
install script!

~~~
shandor
> 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!

~~~
JdeBP

        % 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
        %
    

Delegate=yes is ignored because I did not run this on a Linux operating
system.

* [http://jdebp.uk./Softwares/nosh/worked-example.html](http://jdebp.uk./Softwares/nosh/worked-example.html)

* [http://jdebp.uk./FGA/run-scripts-and-service-units-side-by-s...](http://jdebp.uk./FGA/run-scripts-and-service-units-side-by-side.html)

------
tacLog
Hey I was trying to reach out to sales@deviceplane.com and keep getting: 550
5.1.1 Requested action not taken: mailbox unavailable Is there a better way to
reach out?

~~~
joshwget
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
founders@deviceplane.com.

~~~
tacLog
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.

------
simlevesque
Could you compare your product to AWS GreenGrass ? If I use GreenGrass, should
I use Deviceplane too ?

------
f2prateek
Congrats on the launch!

------
ejcx
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!

~~~
MaximumMadness
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!

~~~
cyrusroshan
Thanks, Evan, Max, you guys rock! Sometimes I forget how many people I know
that read HN.

------
izuchukwu
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.

~~~
cyrusroshan
Thanks Izu, I hope we can share some great updates in the next few months!

